Re: [PATCH 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Hello, On Fri, 25 Jul 2014 09:29:09 -0500, Rob Herring wrote: > > Any idea on how can we get some temporary solution for 3.17 as we didn't > > conclude anything yet on bindings ? > > A temporary solution would have to be NOT in DT because once you add > something into DT you are stuck with it for some time. You could > simply support independent clocks by looking at the platform type, but > that is still risky since you may want to define the OPP in DT > differently for the 2 cases. > > The other problem with temporary solutions is once they are accepted, > people loose motivation to create the permanent solution. "Can you > take this now and I'll fix the issues later" is a red flag to > maintainers. On the Marvell Armada XP side of things, the OPPs are registered dynamically because they change from one board to the other. The only thing that is in the DT for cpufreq-generic is the clock-latency parameter. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 25 July 2014 19:59, Rob Herring wrote: > A temporary solution would have to be NOT in DT because once you add > something into DT you are stuck with it for some time. You could I agree.. > simply support independent clocks by looking at the platform type, but > that is still risky since you may want to define the OPP in DT > differently for the 2 cases. Or because we are going to create platform devices for now, lets have some platform data for cpufreq-cpu0 ? > The other problem with temporary solutions is once they are accepted, > people loose motivation to create the permanent solution. "Can you > take this now and I'll fix the issues later" is a red flag to > maintainers. I completely agree, but there are few points here which might make the red flag yellow if not green :) - I co-maintain this framework and so I do care about it :) - Even with the temporary stuff the solution wouldn't be complete for platforms with multiple clusters having separate clock lines. -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On Thu, Jul 24, 2014 at 5:48 AM, Viresh Kumar wrote: > On 18 July 2014 09:47, Viresh Kumar wrote: >>> Before I apply anything in this area, I need a clear statement from the ARM >>> people as a group on what the approach is going to be. > > @Rafael: The only patch which has blocked this set is: > > cpufreq: cpu0: Extend support beyond CPU0 > > This is about finding which CPUs share clock line.. > > Other patches are sort of independent of this one and cpufreq-cpu0 would > continue to work for existing platforms if we apply these patches. > > I was wondering if you would like to apply other patches leaving this one? > I will then rebase stuff again and send non-controversial patches for 3.17. > So, that we get something in 3.17 and the last change can be merged during > rc's as well once we finalize on bindings.. > >> Mike/Rob/Stephen: I believe Atleast three of you should express your views >> now :) > > Any idea on how can we get some temporary solution for 3.17 as we didn't > conclude anything yet on bindings ? A temporary solution would have to be NOT in DT because once you add something into DT you are stuck with it for some time. You could simply support independent clocks by looking at the platform type, but that is still risky since you may want to define the OPP in DT differently for the 2 cases. The other problem with temporary solutions is once they are accepted, people loose motivation to create the permanent solution. "Can you take this now and I'll fix the issues later" is a red flag to maintainers. Rob -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On Thu, Jul 24, 2014 at 5:48 AM, Viresh Kumar viresh.ku...@linaro.org wrote: On 18 July 2014 09:47, Viresh Kumar viresh.ku...@linaro.org wrote: Before I apply anything in this area, I need a clear statement from the ARM people as a group on what the approach is going to be. @Rafael: The only patch which has blocked this set is: cpufreq: cpu0: Extend support beyond CPU0 This is about finding which CPUs share clock line.. Other patches are sort of independent of this one and cpufreq-cpu0 would continue to work for existing platforms if we apply these patches. I was wondering if you would like to apply other patches leaving this one? I will then rebase stuff again and send non-controversial patches for 3.17. So, that we get something in 3.17 and the last change can be merged during rc's as well once we finalize on bindings.. Mike/Rob/Stephen: I believe Atleast three of you should express your views now :) Any idea on how can we get some temporary solution for 3.17 as we didn't conclude anything yet on bindings ? A temporary solution would have to be NOT in DT because once you add something into DT you are stuck with it for some time. You could simply support independent clocks by looking at the platform type, but that is still risky since you may want to define the OPP in DT differently for the 2 cases. The other problem with temporary solutions is once they are accepted, people loose motivation to create the permanent solution. Can you take this now and I'll fix the issues later is a red flag to maintainers. Rob -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 25 July 2014 19:59, Rob Herring robherri...@gmail.com wrote: A temporary solution would have to be NOT in DT because once you add something into DT you are stuck with it for some time. You could I agree.. simply support independent clocks by looking at the platform type, but that is still risky since you may want to define the OPP in DT differently for the 2 cases. Or because we are going to create platform devices for now, lets have some platform data for cpufreq-cpu0 ? The other problem with temporary solutions is once they are accepted, people loose motivation to create the permanent solution. Can you take this now and I'll fix the issues later is a red flag to maintainers. I completely agree, but there are few points here which might make the red flag yellow if not green :) - I co-maintain this framework and so I do care about it :) - Even with the temporary stuff the solution wouldn't be complete for platforms with multiple clusters having separate clock lines. -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Hello, On Fri, 25 Jul 2014 09:29:09 -0500, Rob Herring wrote: Any idea on how can we get some temporary solution for 3.17 as we didn't conclude anything yet on bindings ? A temporary solution would have to be NOT in DT because once you add something into DT you are stuck with it for some time. You could simply support independent clocks by looking at the platform type, but that is still risky since you may want to define the OPP in DT differently for the 2 cases. The other problem with temporary solutions is once they are accepted, people loose motivation to create the permanent solution. Can you take this now and I'll fix the issues later is a red flag to maintainers. On the Marvell Armada XP side of things, the OPPs are registered dynamically because they change from one board to the other. The only thing that is in the DT for cpufreq-generic is the clock-latency parameter. Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 18 July 2014 09:47, Viresh Kumar wrote: >> Before I apply anything in this area, I need a clear statement from the ARM >> people as a group on what the approach is going to be. @Rafael: The only patch which has blocked this set is: cpufreq: cpu0: Extend support beyond CPU0 This is about finding which CPUs share clock line.. Other patches are sort of independent of this one and cpufreq-cpu0 would continue to work for existing platforms if we apply these patches. I was wondering if you would like to apply other patches leaving this one? I will then rebase stuff again and send non-controversial patches for 3.17. So, that we get something in 3.17 and the last change can be merged during rc's as well once we finalize on bindings.. > Mike/Rob/Stephen: I believe Atleast three of you should express your views > now :) Any idea on how can we get some temporary solution for 3.17 as we didn't conclude anything yet on bindings ? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 18 July 2014 09:47, Viresh Kumar viresh.ku...@linaro.org wrote: Before I apply anything in this area, I need a clear statement from the ARM people as a group on what the approach is going to be. @Rafael: The only patch which has blocked this set is: cpufreq: cpu0: Extend support beyond CPU0 This is about finding which CPUs share clock line.. Other patches are sort of independent of this one and cpufreq-cpu0 would continue to work for existing platforms if we apply these patches. I was wondering if you would like to apply other patches leaving this one? I will then rebase stuff again and send non-controversial patches for 3.17. So, that we get something in 3.17 and the last change can be merged during rc's as well once we finalize on bindings.. Mike/Rob/Stephen: I believe Atleast three of you should express your views now :) Any idea on how can we get some temporary solution for 3.17 as we didn't conclude anything yet on bindings ? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 18 July 2014 06:32, Rafael J. Wysocki wrote: >> > only support the following cases: >> > >> > * One clock for all CPUs >> > * One clock for each CPU >> >> Yeah, so I also proposed this yesterday that we stick to only these >> two implementations for now. And was looking at how would the >> cpufreq-generic driver come to know about this. >> >> So, one way out now is to see if "clocks" property is defined in >> multiple cpu nodes, if yes don't compare them and consider separate >> clocks for each cpu. We don't have to try matching that to any other >> node, as that's a very bad idea. Mike was already very upset with that :) >> >> @Stephen/Rafael: Does that sound any better? Ofcourse the final thing >> is to get bindings to figure out relations between CPUs.. > > Before I apply anything in this area, I need a clear statement from the ARM > people as a group on what the approach is going to be. Thanks for your response Rafael. Mike/Rob/Stephen: I believe Atleast three of you should express your views now :) So, this is what I propose: - I will start another thread with a new DT binding, something like: "clocks-ganged" = <> and then we can decide on naming/etc .. - I will drop the patch which matches clock nodes from DT and introduce another one that will just check if "clocks" is mentioned in more than one CPU. If yes, then we behave as if all CPUs have separate clock lines. That will work for Krait/mvebu and all existing users. Does that sound good? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On Thursday, July 17, 2014 01:11:45 PM Viresh Kumar wrote: > On 17 July 2014 13:05, Thomas Petazzoni > wrote: > > Could you summarize what is the issue with the binding? > > > > At least for the case where we have one clock per CPU, the DT binding > > is really dead simple: each CPU node can carry a "clocks" property, and > > a "clock-latency" property. I really don't see why a long discussion is > > needed to agree on such a binding. > > > > Now, if the DT binding problem is related to those cases where you have > > siblings, i.e one clock controlling *some* of the CPUs, but not all > > CPUs or just one CPU, then maybe we could leave this aside for now, > > Yeah, we are stuck on that for now. > > > only support the following cases: > > > > * One clock for all CPUs > > * One clock for each CPU > > Yeah, so I also proposed this yesterday that we stick to only these > two implementations for now. And was looking at how would the > cpufreq-generic driver come to know about this. > > So, one way out now is to see if "clocks" property is defined in > multiple cpu nodes, if yes don't compare them and consider separate > clocks for each cpu. We don't have to try matching that to any other > node, as that's a very bad idea. Mike was already very upset with that :) > > @Stephen/Rafael: Does that sound any better? Ofcourse the final thing > is to get bindings to figure out relations between CPUs.. Before I apply anything in this area, I need a clear statement from the ARM people as a group on what the approach is going to be. Rafael -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 17 July 2014 13:05, Thomas Petazzoni wrote: > Could you summarize what is the issue with the binding? > > At least for the case where we have one clock per CPU, the DT binding > is really dead simple: each CPU node can carry a "clocks" property, and > a "clock-latency" property. I really don't see why a long discussion is > needed to agree on such a binding. > > Now, if the DT binding problem is related to those cases where you have > siblings, i.e one clock controlling *some* of the CPUs, but not all > CPUs or just one CPU, then maybe we could leave this aside for now, Yeah, we are stuck on that for now. > only support the following cases: > > * One clock for all CPUs > * One clock for each CPU Yeah, so I also proposed this yesterday that we stick to only these two implementations for now. And was looking at how would the cpufreq-generic driver come to know about this. So, one way out now is to see if "clocks" property is defined in multiple cpu nodes, if yes don't compare them and consider separate clocks for each cpu. We don't have to try matching that to any other node, as that's a very bad idea. Mike was already very upset with that :) @Stephen/Rafael: Does that sound any better? Ofcourse the final thing is to get bindings to figure out relations between CPUs.. -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Dear Viresh Kumar, On Thu, 17 Jul 2014 05:58:22 +0530, Viresh Kumar wrote: > On 17 July 2014 02:48, Rafael J. Wysocki wrote: > > I don't like that idea, but I wonder what other people think. > > Hmm, the other thread around looking at the bindings is really slow. Could you summarize what is the issue with the binding? At least for the case where we have one clock per CPU, the DT binding is really dead simple: each CPU node can carry a "clocks" property, and a "clock-latency" property. I really don't see why a long discussion is needed to agree on such a binding. Now, if the DT binding problem is related to those cases where you have siblings, i.e one clock controlling *some* of the CPUs, but not all CPUs or just one CPU, then maybe we could leave this aside for now, only support the following cases: * One clock for all CPUs * One clock for each CPU Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Dear Viresh Kumar, On Thu, 17 Jul 2014 05:58:22 +0530, Viresh Kumar wrote: On 17 July 2014 02:48, Rafael J. Wysocki r...@rjwysocki.net wrote: I don't like that idea, but I wonder what other people think. Hmm, the other thread around looking at the bindings is really slow. Could you summarize what is the issue with the binding? At least for the case where we have one clock per CPU, the DT binding is really dead simple: each CPU node can carry a clocks property, and a clock-latency property. I really don't see why a long discussion is needed to agree on such a binding. Now, if the DT binding problem is related to those cases where you have siblings, i.e one clock controlling *some* of the CPUs, but not all CPUs or just one CPU, then maybe we could leave this aside for now, only support the following cases: * One clock for all CPUs * One clock for each CPU Thanks, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 17 July 2014 13:05, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: Could you summarize what is the issue with the binding? At least for the case where we have one clock per CPU, the DT binding is really dead simple: each CPU node can carry a clocks property, and a clock-latency property. I really don't see why a long discussion is needed to agree on such a binding. Now, if the DT binding problem is related to those cases where you have siblings, i.e one clock controlling *some* of the CPUs, but not all CPUs or just one CPU, then maybe we could leave this aside for now, Yeah, we are stuck on that for now. only support the following cases: * One clock for all CPUs * One clock for each CPU Yeah, so I also proposed this yesterday that we stick to only these two implementations for now. And was looking at how would the cpufreq-generic driver come to know about this. So, one way out now is to see if clocks property is defined in multiple cpu nodes, if yes don't compare them and consider separate clocks for each cpu. We don't have to try matching that to any other node, as that's a very bad idea. Mike was already very upset with that :) @Stephen/Rafael: Does that sound any better? Ofcourse the final thing is to get bindings to figure out relations between CPUs.. -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On Thursday, July 17, 2014 01:11:45 PM Viresh Kumar wrote: On 17 July 2014 13:05, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: Could you summarize what is the issue with the binding? At least for the case where we have one clock per CPU, the DT binding is really dead simple: each CPU node can carry a clocks property, and a clock-latency property. I really don't see why a long discussion is needed to agree on such a binding. Now, if the DT binding problem is related to those cases where you have siblings, i.e one clock controlling *some* of the CPUs, but not all CPUs or just one CPU, then maybe we could leave this aside for now, Yeah, we are stuck on that for now. only support the following cases: * One clock for all CPUs * One clock for each CPU Yeah, so I also proposed this yesterday that we stick to only these two implementations for now. And was looking at how would the cpufreq-generic driver come to know about this. So, one way out now is to see if clocks property is defined in multiple cpu nodes, if yes don't compare them and consider separate clocks for each cpu. We don't have to try matching that to any other node, as that's a very bad idea. Mike was already very upset with that :) @Stephen/Rafael: Does that sound any better? Ofcourse the final thing is to get bindings to figure out relations between CPUs.. Before I apply anything in this area, I need a clear statement from the ARM people as a group on what the approach is going to be. Rafael -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 18 July 2014 06:32, Rafael J. Wysocki r...@rjwysocki.net wrote: only support the following cases: * One clock for all CPUs * One clock for each CPU Yeah, so I also proposed this yesterday that we stick to only these two implementations for now. And was looking at how would the cpufreq-generic driver come to know about this. So, one way out now is to see if clocks property is defined in multiple cpu nodes, if yes don't compare them and consider separate clocks for each cpu. We don't have to try matching that to any other node, as that's a very bad idea. Mike was already very upset with that :) @Stephen/Rafael: Does that sound any better? Ofcourse the final thing is to get bindings to figure out relations between CPUs.. Before I apply anything in this area, I need a clear statement from the ARM people as a group on what the approach is going to be. Thanks for your response Rafael. Mike/Rob/Stephen: I believe Atleast three of you should express your views now :) So, this is what I propose: - I will start another thread with a new DT binding, something like: clocks-ganged = cpu0 and then we can decide on naming/etc .. - I will drop the patch which matches clock nodes from DT and introduce another one that will just check if clocks is mentioned in more than one CPU. If yes, then we behave as if all CPUs have separate clock lines. That will work for Krait/mvebu and all existing users. Does that sound good? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 17 July 2014 02:48, Rafael J. Wysocki wrote: > I don't like that idea, but I wonder what other people think. Hmm, the other thread around looking at the bindings is really slow. One common thing around the platforms which want to use cpufreq-cpu0 is they have different clocks for ALL CPUs. I was wondering if instead of a clock-matching routine, we can provide some temporary relief to them via some other means. I meant we can allow cpufreq-cpu0/generic to either set policy->cpus to ALL CPUs or just 1. So that existing and these new platforms can atleast get going.. But don't know how should we do that. Not a binding ofcourse, a Kconfig option could work but multiplatform stuff would break. What else? Maybe platform data as we are handling cpufreq-cpu0 with a platform device? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On Wednesday, July 16, 2014 09:31:54 PM Viresh Kumar wrote: > Cc'ing Thomas, > > On 8 July 2014 10:20, Viresh Kumar wrote: > > On 4 July 2014 09:51, Viresh Kumar wrote: > >> Yeah, having something like what you suggested from DT is the perfect > >> solution to get over this. The only reason why I am not touching that here > >> is to not delay other patches just because of that. > >> > >> There are separate threads going on for that and probably somebody > >> else was trying to push for that. > >> > >> That's it, nothing more. I would definitely like to use those bindings > >> instead > >> of the crazy routines we are trying here, once that is finalized :) > > > > Do we have some kind of agreement for this temporary solution? Anyways > > I will kick the other thread again to resolve the bindings soon. > > Hi Mike/Rafael, > > Thomas has a dependency on the patch adding "find_siblings()": > http://www.spinics.net/lists/arm-kernel/msg348080.html > > Would it be fine to get this temporary solution (Only within cpufreq-cpu0 > file, so that it doesn't become an API) for now and updating it later once > bindings are closed? I don't like that idea, but I wonder what other people think. Rafael -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Cc'ing Thomas, On 8 July 2014 10:20, Viresh Kumar wrote: > On 4 July 2014 09:51, Viresh Kumar wrote: >> Yeah, having something like what you suggested from DT is the perfect >> solution to get over this. The only reason why I am not touching that here >> is to not delay other patches just because of that. >> >> There are separate threads going on for that and probably somebody >> else was trying to push for that. >> >> That's it, nothing more. I would definitely like to use those bindings >> instead >> of the crazy routines we are trying here, once that is finalized :) > > Do we have some kind of agreement for this temporary solution? Anyways > I will kick the other thread again to resolve the bindings soon. Hi Mike/Rafael, Thomas has a dependency on the patch adding "find_siblings()": http://www.spinics.net/lists/arm-kernel/msg348080.html Would it be fine to get this temporary solution (Only within cpufreq-cpu0 file, so that it doesn't become an API) for now and updating it later once bindings are closed? I have tried pinging on the other thread as well, but no one replied. And it looks those bindings are going to take some time to settle. -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Cc'ing Thomas, On 8 July 2014 10:20, Viresh Kumar viresh.ku...@linaro.org wrote: On 4 July 2014 09:51, Viresh Kumar viresh.ku...@linaro.org wrote: Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that. There are separate threads going on for that and probably somebody else was trying to push for that. That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :) Do we have some kind of agreement for this temporary solution? Anyways I will kick the other thread again to resolve the bindings soon. Hi Mike/Rafael, Thomas has a dependency on the patch adding find_siblings(): http://www.spinics.net/lists/arm-kernel/msg348080.html Would it be fine to get this temporary solution (Only within cpufreq-cpu0 file, so that it doesn't become an API) for now and updating it later once bindings are closed? I have tried pinging on the other thread as well, but no one replied. And it looks those bindings are going to take some time to settle. -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On Wednesday, July 16, 2014 09:31:54 PM Viresh Kumar wrote: Cc'ing Thomas, On 8 July 2014 10:20, Viresh Kumar viresh.ku...@linaro.org wrote: On 4 July 2014 09:51, Viresh Kumar viresh.ku...@linaro.org wrote: Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that. There are separate threads going on for that and probably somebody else was trying to push for that. That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :) Do we have some kind of agreement for this temporary solution? Anyways I will kick the other thread again to resolve the bindings soon. Hi Mike/Rafael, Thomas has a dependency on the patch adding find_siblings(): http://www.spinics.net/lists/arm-kernel/msg348080.html Would it be fine to get this temporary solution (Only within cpufreq-cpu0 file, so that it doesn't become an API) for now and updating it later once bindings are closed? I don't like that idea, but I wonder what other people think. Rafael -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 17 July 2014 02:48, Rafael J. Wysocki r...@rjwysocki.net wrote: I don't like that idea, but I wonder what other people think. Hmm, the other thread around looking at the bindings is really slow. One common thing around the platforms which want to use cpufreq-cpu0 is they have different clocks for ALL CPUs. I was wondering if instead of a clock-matching routine, we can provide some temporary relief to them via some other means. I meant we can allow cpufreq-cpu0/generic to either set policy-cpus to ALL CPUs or just 1. So that existing and these new platforms can atleast get going.. But don't know how should we do that. Not a binding ofcourse, a Kconfig option could work but multiplatform stuff would break. What else? Maybe platform data as we are handling cpufreq-cpu0 with a platform device? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 07/07/14 21:50, Viresh Kumar wrote: > On 4 July 2014 09:51, Viresh Kumar wrote: >> Yeah, having something like what you suggested from DT is the perfect >> solution to get over this. The only reason why I am not touching that here >> is to not delay other patches just because of that. >> >> There are separate threads going on for that and probably somebody >> else was trying to push for that. >> >> That's it, nothing more. I would definitely like to use those bindings >> instead >> of the crazy routines we are trying here, once that is finalized :) > Do we have some kind of agreement for this temporary solution? Anyways > I will kick the other thread again to resolve the bindings soon. > > @Stephen: Do you still want find_rate_changer() stuff in this series only > and or this can go into 3.17 without anymore changes and lets finalize > the bindings Mike suggested and then update this code? > > Finding the rate change is not necessary for me. I don't imagine my code will be getting into 3.17 anyway though so I'm no in a rush to merge anything immediately. I still prefer the common clock framework API. If we go ahead with the find_rate_changer() stuff we've pretty well insulated this driver from any DTisms, which is nice. The only thing left would be transition-latency and voltage-tolerance, but those are already optional so you really don't need to even run on a DT enabled platform to use this code. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 07/07/14 21:50, Viresh Kumar wrote: On 4 July 2014 09:51, Viresh Kumar viresh.ku...@linaro.org wrote: Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that. There are separate threads going on for that and probably somebody else was trying to push for that. That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :) Do we have some kind of agreement for this temporary solution? Anyways I will kick the other thread again to resolve the bindings soon. @Stephen: Do you still want find_rate_changer() stuff in this series only and or this can go into 3.17 without anymore changes and lets finalize the bindings Mike suggested and then update this code? Finding the rate change is not necessary for me. I don't imagine my code will be getting into 3.17 anyway though so I'm no in a rush to merge anything immediately. I still prefer the common clock framework API. If we go ahead with the find_rate_changer() stuff we've pretty well insulated this driver from any DTisms, which is nice. The only thing left would be transition-latency and voltage-tolerance, but those are already optional so you really don't need to even run on a DT enabled platform to use this code. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 4 July 2014 09:51, Viresh Kumar wrote: > Yeah, having something like what you suggested from DT is the perfect > solution to get over this. The only reason why I am not touching that here > is to not delay other patches just because of that. > > There are separate threads going on for that and probably somebody > else was trying to push for that. > > That's it, nothing more. I would definitely like to use those bindings instead > of the crazy routines we are trying here, once that is finalized :) Do we have some kind of agreement for this temporary solution? Anyways I will kick the other thread again to resolve the bindings soon. @Stephen: Do you still want find_rate_changer() stuff in this series only and or this can go into 3.17 without anymore changes and lets finalize the bindings Mike suggested and then update this code? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 4 July 2014 09:51, Viresh Kumar viresh.ku...@linaro.org wrote: Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that. There are separate threads going on for that and probably somebody else was trying to push for that. That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :) Do we have some kind of agreement for this temporary solution? Anyways I will kick the other thread again to resolve the bindings soon. @Stephen: Do you still want find_rate_changer() stuff in this series only and or this can go into 3.17 without anymore changes and lets finalize the bindings Mike suggested and then update this code? -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 4 July 2014 03:46, Mike Turquette wrote: > Sorry for being dense, but I still do not get why trying to dynamically > discover a shared rate-changeable clock is a better approach than simply > describing the hardware in DT? > > Is adding a property to the CPU binding that describes how the CPUs in a > cluster expect to use a clock somehow a non-starter? It is certainly a > win for readability when staring at DT and trying to understand how DVFS > on that CPU is meant to work (as opposed to hiding that knowledge behind > a tree walk). Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that. There are separate threads going on for that and probably somebody else was trying to push for that. That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :) -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Quoting Viresh Kumar (2014-07-02 19:44:04)
> On 3 July 2014 06:54, Stephen Boyd wrote:
> > I gave it a spin. It works so you can have my
> >
> > Tested-by: Stephen Boyd
>
> Thanks, all suggested improvements are made and pushed again with
> your Tested-by..
>
> > I'm still concerned about the patch where we figure out if the clocks
> > are shared. I worry about a configuration where there are different
> > clocks for on/off (i.e. gates) that are per-cpu but they all source from
> > the same divider or something that is per-cluster. In DT this may be
> > described as different clock provider outputs for the gates and in the
> > cpu node we would have different clock specifiers but in reality all the
> > CPUs in that cluster are affected by the same frequency scaling.
>
> Yeah, this is probably what matches with Rob's doubt. These can
> actually be different. Good point.
>
> > In this case we'll need to get help from the clock framework to
> > determine that those gates clocks don't have any .set_rate() callback so
> > they can't actually change rate independently, and then walk up the tree
> > to their parents to see if they have a common ancestor that does change
> > rates. That's where it becomes useful to have a clock framework API for
> > this, like clk_shares_rate(struct clk *clk, struct clk *peer) or
> > something that can hide all this from cpufreq. Here's what I think it
> > would look like (totally untested/uncompiled):
> >
> > static struct clk *find_rate_changer(struct clk *clk)
> > {
> >
> > if (!clk)
> > return NULL;
> >
> > do {
> > /* Rate could change by changing parents */
> > if (clk->num_parents > 1)
> > return clk;
> >
> > /* Rate could change by calling clk_set_rate() */
> > if (clk->ops->set_rate)
> > return clk;
> >
> > /*
> > * This is odd, clk_set_rate() doesn't propagate
> > * and this clock can't change rate or parents
> > * so we must be at the root and the clock we
> > * started at can't change rates. Just return the
> > * root so that we can see if the other clock shares
> > * the same root although CPUfreq should never care.
> > */
> > if (!(clk->flags & CLK_SET_RATE_PARENT))
> > return clk;
> > } while ((clk = clk->parent))
> >
> > return NULL;
> > }
> >
> > bool clk_shares_rate(struct clk *clk, struct clk *peer)
> > {
> > struct clk *p1, *p2;
> >
> > p1 = find_rate_changer(clk);
> > p2 = find_rate_changer(peer)
> >
> > return p1 == p2;
> > }
>
> I find it much better then doing what I did initially, simply matching
> clk_get()
> outputs. Lets see what Mike has to say..
Sorry for being dense, but I still do not get why trying to dynamically
discover a shared rate-changeable clock is a better approach than simply
describing the hardware in DT?
Is adding a property to the CPU binding that describes how the CPUs in a
cluster expect to use a clock somehow a non-starter? It is certainly a
win for readability when staring at DT and trying to understand how DVFS
on that CPU is meant to work (as opposed to hiding that knowledge behind
a tree walk).
Regards,
Mike
>
> @Mike: Is this less ugly ? :)
--
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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
Quoting Viresh Kumar (2014-07-02 19:44:04)
On 3 July 2014 06:54, Stephen Boyd sb...@codeaurora.org wrote:
I gave it a spin. It works so you can have my
Tested-by: Stephen Boyd sb...@codeaurora.org
Thanks, all suggested improvements are made and pushed again with
your Tested-by..
I'm still concerned about the patch where we figure out if the clocks
are shared. I worry about a configuration where there are different
clocks for on/off (i.e. gates) that are per-cpu but they all source from
the same divider or something that is per-cluster. In DT this may be
described as different clock provider outputs for the gates and in the
cpu node we would have different clock specifiers but in reality all the
CPUs in that cluster are affected by the same frequency scaling.
Yeah, this is probably what matches with Rob's doubt. These can
actually be different. Good point.
In this case we'll need to get help from the clock framework to
determine that those gates clocks don't have any .set_rate() callback so
they can't actually change rate independently, and then walk up the tree
to their parents to see if they have a common ancestor that does change
rates. That's where it becomes useful to have a clock framework API for
this, like clk_shares_rate(struct clk *clk, struct clk *peer) or
something that can hide all this from cpufreq. Here's what I think it
would look like (totally untested/uncompiled):
static struct clk *find_rate_changer(struct clk *clk)
{
if (!clk)
return NULL;
do {
/* Rate could change by changing parents */
if (clk-num_parents 1)
return clk;
/* Rate could change by calling clk_set_rate() */
if (clk-ops-set_rate)
return clk;
/*
* This is odd, clk_set_rate() doesn't propagate
* and this clock can't change rate or parents
* so we must be at the root and the clock we
* started at can't change rates. Just return the
* root so that we can see if the other clock shares
* the same root although CPUfreq should never care.
*/
if (!(clk-flags CLK_SET_RATE_PARENT))
return clk;
} while ((clk = clk-parent))
return NULL;
}
bool clk_shares_rate(struct clk *clk, struct clk *peer)
{
struct clk *p1, *p2;
p1 = find_rate_changer(clk);
p2 = find_rate_changer(peer)
return p1 == p2;
}
I find it much better then doing what I did initially, simply matching
clk_get()
outputs. Lets see what Mike has to say..
Sorry for being dense, but I still do not get why trying to dynamically
discover a shared rate-changeable clock is a better approach than simply
describing the hardware in DT?
Is adding a property to the CPU binding that describes how the CPUs in a
cluster expect to use a clock somehow a non-starter? It is certainly a
win for readability when staring at DT and trying to understand how DVFS
on that CPU is meant to work (as opposed to hiding that knowledge behind
a tree walk).
Regards,
Mike
@Mike: Is this less ugly ? :)
--
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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 4 July 2014 03:46, Mike Turquette mturque...@linaro.org wrote: Sorry for being dense, but I still do not get why trying to dynamically discover a shared rate-changeable clock is a better approach than simply describing the hardware in DT? Is adding a property to the CPU binding that describes how the CPUs in a cluster expect to use a clock somehow a non-starter? It is certainly a win for readability when staring at DT and trying to understand how DVFS on that CPU is meant to work (as opposed to hiding that knowledge behind a tree walk). Yeah, having something like what you suggested from DT is the perfect solution to get over this. The only reason why I am not touching that here is to not delay other patches just because of that. There are separate threads going on for that and probably somebody else was trying to push for that. That's it, nothing more. I would definitely like to use those bindings instead of the crazy routines we are trying here, once that is finalized :) -- viresh -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 3 July 2014 06:54, Stephen Boyd wrote:
> I gave it a spin. It works so you can have my
>
> Tested-by: Stephen Boyd
Thanks, all suggested improvements are made and pushed again with
your Tested-by..
> I'm still concerned about the patch where we figure out if the clocks
> are shared. I worry about a configuration where there are different
> clocks for on/off (i.e. gates) that are per-cpu but they all source from
> the same divider or something that is per-cluster. In DT this may be
> described as different clock provider outputs for the gates and in the
> cpu node we would have different clock specifiers but in reality all the
> CPUs in that cluster are affected by the same frequency scaling.
Yeah, this is probably what matches with Rob's doubt. These can
actually be different. Good point.
> In this case we'll need to get help from the clock framework to
> determine that those gates clocks don't have any .set_rate() callback so
> they can't actually change rate independently, and then walk up the tree
> to their parents to see if they have a common ancestor that does change
> rates. That's where it becomes useful to have a clock framework API for
> this, like clk_shares_rate(struct clk *clk, struct clk *peer) or
> something that can hide all this from cpufreq. Here's what I think it
> would look like (totally untested/uncompiled):
>
> static struct clk *find_rate_changer(struct clk *clk)
> {
>
> if (!clk)
> return NULL;
>
> do {
> /* Rate could change by changing parents */
> if (clk->num_parents > 1)
> return clk;
>
> /* Rate could change by calling clk_set_rate() */
> if (clk->ops->set_rate)
> return clk;
>
> /*
> * This is odd, clk_set_rate() doesn't propagate
> * and this clock can't change rate or parents
> * so we must be at the root and the clock we
> * started at can't change rates. Just return the
> * root so that we can see if the other clock shares
> * the same root although CPUfreq should never care.
> */
> if (!(clk->flags & CLK_SET_RATE_PARENT))
> return clk;
> } while ((clk = clk->parent))
>
> return NULL;
> }
>
> bool clk_shares_rate(struct clk *clk, struct clk *peer)
> {
> struct clk *p1, *p2;
>
> p1 = find_rate_changer(clk);
> p2 = find_rate_changer(peer)
>
> return p1 == p2;
> }
I find it much better then doing what I did initially, simply matching clk_get()
outputs. Lets see what Mike has to say..
@Mike: Is this less ugly ? :)
--
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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 07/01/14 21:12, Viresh Kumar wrote:
> On 1 July 2014 22:02, Viresh Kumar wrote:
>> V1: https://lkml.org/lkml/2014/6/25/152
>>
>> Stephen Boyd sent few patches some time back around a new cpufreq driver for
>> Qualcomm's Krait SoC: https://lkml.org/lkml/2014/6/24/918.
>>
>> Krait couldn't use existing cpufreq-cpu0 driver as it doesn't have support
>> for
>> SoC's with multiple clusters or SoC's which don't share clock line across all
>> CPUs.
>>
>> This patchset is all about extending support beyond CPU0. It can be used for
>> platforms like Krait or ARM big LITTLE architecture now.
>>
>> First two patches add helper routine for of and clk layer, which would be
>> used
>> by later patches.
>>
>> Third one adds space for driver specific data in 'struct cpufreq_policy' and
>> later ones migrate cpufreq-cpu0 to cpufreq-generic, i.e. can be used for SoCs
>> which don't share clock lines across all CPUs.
>>
>> @Stephen: I haven't added your Tested-by as there were few modifications
>> since
>> the time you tested it last.
>>
>> Pushed here:
>> Rebased over v3.16-rc3:
>> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2
> Hi Stephen,
>
> As suggested by you I have updated patch
>
> 7/14: cpufreq: cpu0: OPPs can be populated at runtime
> 12/14: cpufreq: cpu0: Extend support beyond CPU0
>
> and dropped
> 2/14: clk: Create of_clk_shared_by_cpus()
>
> Please see if they look fine and work for you.
>
> git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3
I gave it a spin. It works so you can have my
Tested-by: Stephen Boyd
I'm still concerned about the patch where we figure out if the clocks
are shared. I worry about a configuration where there are different
clocks for on/off (i.e. gates) that are per-cpu but they all source from
the same divider or something that is per-cluster. In DT this may be
described as different clock provider outputs for the gates and in the
cpu node we would have different clock specifiers but in reality all the
CPUs in that cluster are affected by the same frequency scaling.
In this case we'll need to get help from the clock framework to
determine that those gates clocks don't have any .set_rate() callback so
they can't actually change rate independently, and then walk up the tree
to their parents to see if they have a common ancestor that does change
rates. That's where it becomes useful to have a clock framework API for
this, like clk_shares_rate(struct clk *clk, struct clk *peer) or
something that can hide all this from cpufreq. Here's what I think it
would look like (totally untested/uncompiled):
static struct clk *find_rate_changer(struct clk *clk)
{
if (!clk)
return NULL;
do {
/* Rate could change by changing parents */
if (clk->num_parents > 1)
return clk;
/* Rate could change by calling clk_set_rate() */
if (clk->ops->set_rate)
return clk;
/*
* This is odd, clk_set_rate() doesn't propagate
* and this clock can't change rate or parents
* so we must be at the root and the clock we
* started at can't change rates. Just return the
* root so that we can see if the other clock shares
* the same root although CPUfreq should never care.
*/
if (!(clk->flags & CLK_SET_RATE_PARENT))
return clk;
} while ((clk = clk->parent))
return NULL;
}
bool clk_shares_rate(struct clk *clk, struct clk *peer)
{
struct clk *p1, *p2;
p1 = find_rate_changer(clk);
p2 = find_rate_changer(peer)
return p1 == p2;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 07/01/14 21:12, Viresh Kumar wrote:
On 1 July 2014 22:02, Viresh Kumar viresh.ku...@linaro.org wrote:
V1: https://lkml.org/lkml/2014/6/25/152
Stephen Boyd sent few patches some time back around a new cpufreq driver for
Qualcomm's Krait SoC: https://lkml.org/lkml/2014/6/24/918.
Krait couldn't use existing cpufreq-cpu0 driver as it doesn't have support
for
SoC's with multiple clusters or SoC's which don't share clock line across all
CPUs.
This patchset is all about extending support beyond CPU0. It can be used for
platforms like Krait or ARM big LITTLE architecture now.
First two patches add helper routine for of and clk layer, which would be
used
by later patches.
Third one adds space for driver specific data in 'struct cpufreq_policy' and
later ones migrate cpufreq-cpu0 to cpufreq-generic, i.e. can be used for SoCs
which don't share clock lines across all CPUs.
@Stephen: I haven't added your Tested-by as there were few modifications
since
the time you tested it last.
Pushed here:
Rebased over v3.16-rc3:
git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2
Hi Stephen,
As suggested by you I have updated patch
7/14: cpufreq: cpu0: OPPs can be populated at runtime
12/14: cpufreq: cpu0: Extend support beyond CPU0
and dropped
2/14: clk: Create of_clk_shared_by_cpus()
Please see if they look fine and work for you.
git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3
I gave it a spin. It works so you can have my
Tested-by: Stephen Boyd sb...@codeaurora.org
I'm still concerned about the patch where we figure out if the clocks
are shared. I worry about a configuration where there are different
clocks for on/off (i.e. gates) that are per-cpu but they all source from
the same divider or something that is per-cluster. In DT this may be
described as different clock provider outputs for the gates and in the
cpu node we would have different clock specifiers but in reality all the
CPUs in that cluster are affected by the same frequency scaling.
In this case we'll need to get help from the clock framework to
determine that those gates clocks don't have any .set_rate() callback so
they can't actually change rate independently, and then walk up the tree
to their parents to see if they have a common ancestor that does change
rates. That's where it becomes useful to have a clock framework API for
this, like clk_shares_rate(struct clk *clk, struct clk *peer) or
something that can hide all this from cpufreq. Here's what I think it
would look like (totally untested/uncompiled):
static struct clk *find_rate_changer(struct clk *clk)
{
if (!clk)
return NULL;
do {
/* Rate could change by changing parents */
if (clk-num_parents 1)
return clk;
/* Rate could change by calling clk_set_rate() */
if (clk-ops-set_rate)
return clk;
/*
* This is odd, clk_set_rate() doesn't propagate
* and this clock can't change rate or parents
* so we must be at the root and the clock we
* started at can't change rates. Just return the
* root so that we can see if the other clock shares
* the same root although CPUfreq should never care.
*/
if (!(clk-flags CLK_SET_RATE_PARENT))
return clk;
} while ((clk = clk-parent))
return NULL;
}
bool clk_shares_rate(struct clk *clk, struct clk *peer)
{
struct clk *p1, *p2;
p1 = find_rate_changer(clk);
p2 = find_rate_changer(peer)
return p1 == p2;
}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 3 July 2014 06:54, Stephen Boyd sb...@codeaurora.org wrote:
I gave it a spin. It works so you can have my
Tested-by: Stephen Boyd sb...@codeaurora.org
Thanks, all suggested improvements are made and pushed again with
your Tested-by..
I'm still concerned about the patch where we figure out if the clocks
are shared. I worry about a configuration where there are different
clocks for on/off (i.e. gates) that are per-cpu but they all source from
the same divider or something that is per-cluster. In DT this may be
described as different clock provider outputs for the gates and in the
cpu node we would have different clock specifiers but in reality all the
CPUs in that cluster are affected by the same frequency scaling.
Yeah, this is probably what matches with Rob's doubt. These can
actually be different. Good point.
In this case we'll need to get help from the clock framework to
determine that those gates clocks don't have any .set_rate() callback so
they can't actually change rate independently, and then walk up the tree
to their parents to see if they have a common ancestor that does change
rates. That's where it becomes useful to have a clock framework API for
this, like clk_shares_rate(struct clk *clk, struct clk *peer) or
something that can hide all this from cpufreq. Here's what I think it
would look like (totally untested/uncompiled):
static struct clk *find_rate_changer(struct clk *clk)
{
if (!clk)
return NULL;
do {
/* Rate could change by changing parents */
if (clk-num_parents 1)
return clk;
/* Rate could change by calling clk_set_rate() */
if (clk-ops-set_rate)
return clk;
/*
* This is odd, clk_set_rate() doesn't propagate
* and this clock can't change rate or parents
* so we must be at the root and the clock we
* started at can't change rates. Just return the
* root so that we can see if the other clock shares
* the same root although CPUfreq should never care.
*/
if (!(clk-flags CLK_SET_RATE_PARENT))
return clk;
} while ((clk = clk-parent))
return NULL;
}
bool clk_shares_rate(struct clk *clk, struct clk *peer)
{
struct clk *p1, *p2;
p1 = find_rate_changer(clk);
p2 = find_rate_changer(peer)
return p1 == p2;
}
I find it much better then doing what I did initially, simply matching clk_get()
outputs. Lets see what Mike has to say..
@Mike: Is this less ugly ? :)
--
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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 1 July 2014 22:02, Viresh Kumar wrote: > V1: https://lkml.org/lkml/2014/6/25/152 > > Stephen Boyd sent few patches some time back around a new cpufreq driver for > Qualcomm's Krait SoC: https://lkml.org/lkml/2014/6/24/918. > > Krait couldn't use existing cpufreq-cpu0 driver as it doesn't have support for > SoC's with multiple clusters or SoC's which don't share clock line across all > CPUs. > > This patchset is all about extending support beyond CPU0. It can be used for > platforms like Krait or ARM big LITTLE architecture now. > > First two patches add helper routine for of and clk layer, which would be used > by later patches. > > Third one adds space for driver specific data in 'struct cpufreq_policy' and > later ones migrate cpufreq-cpu0 to cpufreq-generic, i.e. can be used for SoCs > which don't share clock lines across all CPUs. > > @Stephen: I haven't added your Tested-by as there were few modifications since > the time you tested it last. > > Pushed here: > Rebased over v3.16-rc3: > git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2 Hi Stephen, As suggested by you I have updated patch 7/14: cpufreq: cpu0: OPPs can be populated at runtime 12/14: cpufreq: cpu0: Extend support beyond CPU0 and dropped 2/14: clk: Create of_clk_shared_by_cpus() Please see if they look fine and work for you. git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3 -- 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 00/14] cpufreq: cpu0: Extend support beyond CPU0, V2
On 1 July 2014 22:02, Viresh Kumar viresh.ku...@linaro.org wrote: V1: https://lkml.org/lkml/2014/6/25/152 Stephen Boyd sent few patches some time back around a new cpufreq driver for Qualcomm's Krait SoC: https://lkml.org/lkml/2014/6/24/918. Krait couldn't use existing cpufreq-cpu0 driver as it doesn't have support for SoC's with multiple clusters or SoC's which don't share clock line across all CPUs. This patchset is all about extending support beyond CPU0. It can be used for platforms like Krait or ARM big LITTLE architecture now. First two patches add helper routine for of and clk layer, which would be used by later patches. Third one adds space for driver specific data in 'struct cpufreq_policy' and later ones migrate cpufreq-cpu0 to cpufreq-generic, i.e. can be used for SoCs which don't share clock lines across all CPUs. @Stephen: I haven't added your Tested-by as there were few modifications since the time you tested it last. Pushed here: Rebased over v3.16-rc3: git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v2 Hi Stephen, As suggested by you I have updated patch 7/14: cpufreq: cpu0: OPPs can be populated at runtime 12/14: cpufreq: cpu0: Extend support beyond CPU0 and dropped 2/14: clk: Create of_clk_shared_by_cpus() Please see if they look fine and work for you. git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-krait-v3 -- 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/
