On 2 July 2014 03:30, Mike Turquette wrote:
> I can't help but think this is a pretty ugly solution. Why not specify
Thanks :)
> the nature of the cpu clock(s) in DT directly? There was a thread
> already that discussed adding such a property to the CPU DT binding but
> it seems to have gone
Quoting Viresh Kumar (2014-07-01 04:14:04)
> On 1 July 2014 00:03, Rob Herring wrote:
> >> What about comparing "clocks" property in cpu DT nodes?
> >
> > What if a different clock is selected for some reason.
>
> I don't know why that will happen for CPUs sharing clock line.
>
> > I think a
On 1 July 2014 00:03, Rob Herring wrote:
>> What about comparing "clocks" property in cpu DT nodes?
>
> What if a different clock is selected for some reason.
I don't know why that will happen for CPUs sharing clock line.
> I think a clock api function would be better.
@Mike: What do you
On 1 July 2014 00:03, Rob Herring rob.herr...@linaro.org wrote:
What about comparing clocks property in cpu DT nodes?
What if a different clock is selected for some reason.
I don't know why that will happen for CPUs sharing clock line.
I think a clock api function would be better.
@Mike:
Quoting Viresh Kumar (2014-07-01 04:14:04)
On 1 July 2014 00:03, Rob Herring rob.herr...@linaro.org wrote:
What about comparing clocks property in cpu DT nodes?
What if a different clock is selected for some reason.
I don't know why that will happen for CPUs sharing clock line.
I
On 2 July 2014 03:30, Mike Turquette mturque...@linaro.org wrote:
I can't help but think this is a pretty ugly solution. Why not specify
Thanks :)
the nature of the cpu clock(s) in DT directly? There was a thread
already that discussed adding such a property to the CPU DT binding but
it
On Mon, Jun 30, 2014 at 2:57 AM, Viresh Kumar wrote:
> On 27 June 2014 07:45, Viresh Kumar wrote:
>> On 27 June 2014 07:23, Mike Turquette wrote:
but it isn't future-proof if/when the clock framework starts returning
dynamically allocated clock pointers for each clk_get() invocation.
On 27 June 2014 07:45, Viresh Kumar wrote:
> On 27 June 2014 07:23, Mike Turquette wrote:
>>> but it isn't future-proof if/when the clock framework starts returning
>>> dynamically allocated clock pointers for each clk_get() invocation.
>>> Maybe we need a function in the common clock framework
On 27 June 2014 07:45, Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 June 2014 07:23, Mike Turquette mturque...@linaro.org wrote:
but it isn't future-proof if/when the clock framework starts returning
dynamically allocated clock pointers for each clk_get() invocation.
Maybe we need a
On Mon, Jun 30, 2014 at 2:57 AM, Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 June 2014 07:45, Viresh Kumar viresh.ku...@linaro.org wrote:
On 27 June 2014 07:23, Mike Turquette mturque...@linaro.org wrote:
but it isn't future-proof if/when the clock framework starts returning
dynamically
On 28 June 2014 20:22, Shawn Guo wrote:
> Thanks for all the effort on maintaining and improving cpufreq-cpu0
> driver.
You're welcome..
> Your patch rewrote the most part of the driver, so I'd like to
> hand over the driver to you. Please add yourself as the primary person
> for
On 28 June 2014 20:22, Shawn Guo shawn@linaro.org wrote:
Thanks for all the effort on maintaining and improving cpufreq-cpu0
driver.
You're welcome..
Your patch rewrote the most part of the driver, so I'd like to
hand over the driver to you. Please add yourself as the primary person
On Wed, Jun 25, 2014 at 02:12:29PM +0530, Viresh Kumar wrote:
> cpufreq-cpu0 driver supports only platforms which have single clock line
> shared
> among all CPUs.
>
> We already have platforms where this limitation doesn't hold true.For example
> on
> Qualcomm's KRAIT all CPUs have separate
On Wed, Jun 25, 2014 at 02:12:29PM +0530, Viresh Kumar wrote:
cpufreq-cpu0 driver supports only platforms which have single clock line
shared
among all CPUs.
We already have platforms where this limitation doesn't hold true.For example
on
Qualcomm's KRAIT all CPUs have separate clock
On 27 June 2014 05:36, Stephen Boyd wrote:
> I gave it a spin. It looks mostly good except for the infinite loop:
Great !!
> diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
> index b7ee67c4d1c0..6744321ae33d 100644
> --- a/drivers/cpufreq/cpufreq-cpu0.c
> +++
On 27 June 2014 07:23, Mike Turquette wrote:
>> but it isn't future-proof if/when the clock framework starts returning
>> dynamically allocated clock pointers for each clk_get() invocation.
>> Maybe we need a function in the common clock framework that tells us if
>> the clocks are the same
Quoting Stephen Boyd (2014-06-26 17:06:00)
> Finally, checking for equivalent pointers from clk_get() will work now,
Please don't do that. Even though it works for the current
implementation, comparing those pointers from a driver violates how
clkdev is supposed to work. The pointer returned by
On 06/26/14 03:52, Viresh Kumar wrote:
> On 26 June 2014 00:32, Stephen Boyd wrote:
>> I don't think this driver should be using regulator_get_optional() (Mark
>> B. please correct me if I'm wrong). I doubt a supply is actually
>> optional for CPUs, just some DTs aren't specifying them. In those
On Wed, Jun 25, 2014 at 12:02:25PM -0700, Stephen Boyd wrote:
> I don't think this driver should be using regulator_get_optional() (Mark
> B. please correct me if I'm wrong). I doubt a supply is actually
> optional for CPUs, just some DTs aren't specifying them. In those cases,
> the regulator
On 26 June 2014 00:32, Stephen Boyd wrote:
> I don't think this driver should be using regulator_get_optional() (Mark
> B. please correct me if I'm wrong). I doubt a supply is actually
> optional for CPUs, just some DTs aren't specifying them. In those cases,
> the regulator core will insert a
On 26 June 2014 00:32, Stephen Boyd wrote:
>> + cpu_reg = regulator_get_optional(cpu_dev, "cpu0");
> I don't think this driver should be using regulator_get_optional() (Mark
> B. please correct me if I'm wrong). I doubt a supply is actually
> optional for CPUs, just some DTs aren't
On 26 June 2014 00:32, Stephen Boyd sb...@codeaurora.org wrote:
+ cpu_reg = regulator_get_optional(cpu_dev, cpu0);
I don't think this driver should be using regulator_get_optional() (Mark
B. please correct me if I'm wrong). I doubt a supply is actually
optional for CPUs, just some DTs
On 26 June 2014 00:32, Stephen Boyd sb...@codeaurora.org wrote:
I don't think this driver should be using regulator_get_optional() (Mark
B. please correct me if I'm wrong). I doubt a supply is actually
optional for CPUs, just some DTs aren't specifying them. In those cases,
the regulator core
On Wed, Jun 25, 2014 at 12:02:25PM -0700, Stephen Boyd wrote:
I don't think this driver should be using regulator_get_optional() (Mark
B. please correct me if I'm wrong). I doubt a supply is actually
optional for CPUs, just some DTs aren't specifying them. In those cases,
the regulator core
On 06/26/14 03:52, Viresh Kumar wrote:
On 26 June 2014 00:32, Stephen Boyd sb...@codeaurora.org wrote:
I don't think this driver should be using regulator_get_optional() (Mark
B. please correct me if I'm wrong). I doubt a supply is actually
optional for CPUs, just some DTs aren't specifying
Quoting Stephen Boyd (2014-06-26 17:06:00)
Finally, checking for equivalent pointers from clk_get() will work now,
Please don't do that. Even though it works for the current
implementation, comparing those pointers from a driver violates how
clkdev is supposed to work. The pointer returned by
On 27 June 2014 07:23, Mike Turquette mturque...@linaro.org wrote:
but it isn't future-proof if/when the clock framework starts returning
dynamically allocated clock pointers for each clk_get() invocation.
Maybe we need a function in the common clock framework that tells us if
the clocks are
On 27 June 2014 05:36, Stephen Boyd sb...@codeaurora.org wrote:
I gave it a spin. It looks mostly good except for the infinite loop:
Great !!
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index b7ee67c4d1c0..6744321ae33d 100644
---
On 26 June 2014 00:32, Stephen Boyd wrote:
> It should be easy enough to read the clocks property from DT for all the
> CPU nodes and check to see if they're the same?
Not everybody has clocks supported in DT and I am not sure if it will
even work for the current users as well..
But yeah,
On 06/25/14 01:42, Viresh Kumar wrote:
> cpufreq-cpu0 driver supports only platforms which have single clock line
> shared
> among all CPUs.
>
> We already have platforms where this limitation doesn't hold true.For example
> on
> Qualcomm's KRAIT all CPUs have separate clock line and so have
cpufreq-cpu0 driver supports only platforms which have single clock line shared
among all CPUs.
We already have platforms where this limitation doesn't hold true.For example on
Qualcomm's KRAIT all CPUs have separate clock line and so have separate
policies.
Instead of adding another driver for
cpufreq-cpu0 driver supports only platforms which have single clock line shared
among all CPUs.
We already have platforms where this limitation doesn't hold true.For example on
Qualcomm's KRAIT all CPUs have separate clock line and so have separate
policies.
Instead of adding another driver for
On 06/25/14 01:42, Viresh Kumar wrote:
cpufreq-cpu0 driver supports only platforms which have single clock line
shared
among all CPUs.
We already have platforms where this limitation doesn't hold true.For example
on
Qualcomm's KRAIT all CPUs have separate clock line and so have separate
On 26 June 2014 00:32, Stephen Boyd sb...@codeaurora.org wrote:
It should be easy enough to read the clocks property from DT for all the
CPU nodes and check to see if they're the same?
Not everybody has clocks supported in DT and I am not sure if it will
even work for the current users as
34 matches
Mail list logo
