On Tue, Aug 26, 2014 at 04:30:08PM -0700, Mike Turquette wrote:
> 2) for the kexec-kernel-case, the responsibility is on the first kernel
> to set things up in a good state for the second kernel, with the
> exception of using kexec to debug/examime/recover from a kernel crash,
> in which case you
On Tue, Aug 26, 2014 at 04:30:08PM -0700, Mike Turquette wrote:
2) for the kexec-kernel-case, the responsibility is on the first kernel
to set things up in a good state for the second kernel, with the
exception of using kexec to debug/examime/recover from a kernel crash,
in which case you
On Tue, Aug 26, 2014 at 5:35 PM, Andrew Lunn wrote:
>> One final thought I have had is that it might be a good idea to have a
>> mux clock which represents the clock signal that feeds into the cpu. It
>> seems that a mux is exactly what is going on here with cpuclk rate and
>> ddrclk rate.
>
> I
> One final thought I have had is that it might be a good idea to have a
> mux clock which represents the clock signal that feeds into the cpu. It
> seems that a mux is exactly what is going on here with cpuclk rate and
> ddrclk rate.
I did think of this when i implemented the cpufreq driver.
> > Not quite true. u-boot might of touch the clock. Weird things happen
> > with some kirkwood boards. Some don't have the ability to control
> > there power supplies. So some boards implement "power off" by
> > rebooting, and letting u-boot spin until a button is pressed. I hope
> > such a
Not quite true. u-boot might of touch the clock. Weird things happen
with some kirkwood boards. Some don't have the ability to control
there power supplies. So some boards implement power off by
rebooting, and letting u-boot spin until a button is pressed. I hope
such a u-boot powers off
One final thought I have had is that it might be a good idea to have a
mux clock which represents the clock signal that feeds into the cpu. It
seems that a mux is exactly what is going on here with cpuclk rate and
ddrclk rate.
I did think of this when i implemented the cpufreq driver. What
On Tue, Aug 26, 2014 at 5:35 PM, Andrew Lunn and...@lunn.ch wrote:
One final thought I have had is that it might be a good idea to have a
mux clock which represents the clock signal that feeds into the cpu. It
seems that a mux is exactly what is going on here with cpuclk rate and
ddrclk rate.
> It was clearer in earlier versions of the driver, but code has been
> refactored into the cpufreq core. The core should call
> kirkwood_cpufreq_get_cpu_frequency() in order to get the current
> frequency, and only perform a change if the requested frequency is
> different. In the current code,
> Thanks for reviewing. I think my patch is equivalent to the old way of
> doing things, with one exception that I will address later below.
>
> struct cpufreq_frequency_table kirkwood_freq_table has clock rates
> initialized to zero, so there is no regression compared to my unsigned
> long
Quoting Andrew Lunn (2014-08-21 06:38:25)
> On Thu, Aug 21, 2014 at 09:53:43AM +0200, Tomeu Vizoso wrote:
> > On 08/21/2014 12:55 AM, Mike Turquette wrote:
> > >Quoting Tomeu Vizoso (2014-08-18 08:30:29)
> > >>Signed-off-by: Tomeu Vizoso
> > >>---
> > >> drivers/cpufreq/kirkwood-cpufreq.c | 3
Quoting Andrew Lunn (2014-08-21 06:38:25)
On Thu, Aug 21, 2014 at 09:53:43AM +0200, Tomeu Vizoso wrote:
On 08/21/2014 12:55 AM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2014-08-18 08:30:29)
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
Thanks for reviewing. I think my patch is equivalent to the old way of
doing things, with one exception that I will address later below.
struct cpufreq_frequency_table kirkwood_freq_table has clock rates
initialized to zero, so there is no regression compared to my unsigned
long
It was clearer in earlier versions of the driver, but code has been
refactored into the cpufreq core. The core should call
kirkwood_cpufreq_get_cpu_frequency() in order to get the current
frequency, and only perform a change if the requested frequency is
different. In the current code,
On Thu, Aug 21, 2014 at 09:53:43AM +0200, Tomeu Vizoso wrote:
> On 08/21/2014 12:55 AM, Mike Turquette wrote:
> >Quoting Tomeu Vizoso (2014-08-18 08:30:29)
> >>Signed-off-by: Tomeu Vizoso
> >>---
> >> drivers/cpufreq/kirkwood-cpufreq.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
On 08/21/2014 12:55 AM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2014-08-18 08:30:29)
Signed-off-by: Tomeu Vizoso
---
drivers/cpufreq/kirkwood-cpufreq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
On 08/21/2014 12:55 AM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2014-08-18 08:30:29)
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
drivers/cpufreq/kirkwood-cpufreq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
On Thu, Aug 21, 2014 at 09:53:43AM +0200, Tomeu Vizoso wrote:
On 08/21/2014 12:55 AM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2014-08-18 08:30:29)
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
drivers/cpufreq/kirkwood-cpufreq.c | 3 +--
1 file changed, 1 insertion(+), 2
Signed-off-by: Tomeu Vizoso
---
drivers/cpufreq/kirkwood-cpufreq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
b/drivers/cpufreq/kirkwood-cpufreq.c
index 37a4806..f3d087f 100644
--- a/drivers/cpufreq/kirkwood-cpufreq.c
+++
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
drivers/cpufreq/kirkwood-cpufreq.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/cpufreq/kirkwood-cpufreq.c
b/drivers/cpufreq/kirkwood-cpufreq.c
index 37a4806..f3d087f 100644
---
20 matches
Mail list logo
