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 fo
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 m
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 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 find
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
>> cp
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
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 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.
I
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 becaus
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.
>>
>> The
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 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 p
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 ex
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 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 whic
19 matches
Mail list logo