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
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
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:
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
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
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
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
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
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
>>
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
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
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
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
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
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
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
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.
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
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
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
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
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
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.
>>
>>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
38 matches
Mail list logo
