> On 4 October 2012 18:06, MyungJoo Ham wrote:
> >> This patchset updates devfreq core to add support for devices
> >> which can idle. When device idleness is detected perhaps
> >> through runtime-pm, need some mechanism to suspend devfreq
> >> load monitoring and resume when device is back online
On 4 October 2012 19:16, Bernard Ogden wrote:
> Please check the config.txt file on the motherboard micro SDCard and make
> sure the following entry is set:
>
> ASSERTNPOR: TRUE ;External resets assert nPOR
It was false earlier. Changed it to TRUE, still unable to reboot after
pr
On 4 October 2012 18:06, MyungJoo Ham wrote:
>> This patchset updates devfreq core to add support for devices
>> which can idle. When device idleness is detected perhaps
>> through runtime-pm, need some mechanism to suspend devfreq
>> load monitoring and resume when device is back online.
>>
>> pa
On 4 October 2012 21:26, Ryan Harkin wrote:
> I'm not understanding this email thread at all... perhaps because I've
> read it from the top ;-)
>
> I thought from the first email that Viresh was trying to get the board
> to boot up completely from when he applies power to the board in
> that
Hi Tixy
On 10/04/2012 12:55 PM, Jon Medhurst (Tixy) wrote:
Hi Andrey
Now I'm providing a single LT topic based off linux-linaro-core-tracking
(llct), and you said that you need everyone to base off the same version
of llct,
Yes, this is currently the case.
don't we need some kind of notific
I'm not understanding this email thread at all... perhaps because I've
read it from the top ;-)
I thought from the first email that Viresh was trying to get the board
to boot up completely from when he applies power to the board in
that case, editing /media/VEMSD/config.txt and changing "AUTO
> >>
> >> eg.
> >> cpu0: acpi_idle
> >> cpu1: acpi_idle
> >>
> >
> > Is this allowed? I thought sysfs files can output only 1 line of data?
>
> Ah yeah :)
>
> Does it make sense to put the following files:
>
> /sys/devices/system/cpu/cpu0/cpuidle/driver
> => acpi_idle
> /sys/devices/system/cpu
On 10/04/2012 04:16 PM, Peter De Schrijver wrote:
> On Tue, Sep 25, 2012 at 12:43:50AM +0200, Daniel Lezcano wrote:
>> The discussion about having different cpus on the system with
>> different latencies bring us to a first attemp by adding a
>> pointer in the cpuidle_device to the states array.
>>
On 10/04/2012 04:14 PM, Peter De Schrijver wrote:
> On Tue, Sep 25, 2012 at 12:43:54AM +0200, Daniel Lezcano wrote:
>> With the tegra3 and the big.LITTLE [1] new architectures, several cpus
>> with different characteristics (latencies and states) can co-exists on the
>> system.
>>
>> The cpuidle fr
On Tue, Sep 25, 2012 at 12:43:50AM +0200, Daniel Lezcano wrote:
> The discussion about having different cpus on the system with
> different latencies bring us to a first attemp by adding a
> pointer in the cpuidle_device to the states array.
>
> But as Rafael suggested, it would make more sense to
On Tue, Sep 25, 2012 at 12:43:54AM +0200, Daniel Lezcano wrote:
> With the tegra3 and the big.LITTLE [1] new architectures, several cpus
> with different characteristics (latencies and states) can co-exists on the
> system.
>
> The cpuidle framework has the limitation of handling only identical cp
On Thu, 2012-10-04 at 14:46 +0100, Bernard Ogden wrote:
> Please check the config.txt file on the motherboard micro SDCard and make
> sure the following entry is set:
>
> ASSERTNPOR: TRUE ;External resets assert nPOR
>
> (config.txt should be in the root of the filesystem.)
It i
Please check the config.txt file on the motherboard micro SDCard and make sure
the following entry is set:
ASSERTNPOR: TRUE ;External resets assert nPOR
(config.txt should be in the root of the filesystem.)
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@l
On 4 October 2012 17:18, Jon Medhurst (Tixy) wrote:
> Just tried it, and that's how my TC2 behaves as well. Whereas on A9 it
> does reset the CoreTile CPU and the bootmonitor runs again.
Good to know, i am not alone. :)
> I should also note that even when booting from the motherboard
> bootloade
> This patchset updates devfreq core to add support for devices
> which can idle. When device idleness is detected perhaps
> through runtime-pm, need some mechanism to suspend devfreq
> load monitoring and resume when device is back online.
>
> patch 1 introduce core design changes - per device wo
On Thu, 2012-10-04 at 15:04 +0530, Viresh Kumar wrote:
> On 4 October 2012 14:48, Bernard Ogden wrote:
> > Pawel's on holiday this week. I'm no expert in this area, but I ran your
> > question past one of our platform guys. Does the following help?
>
> Thanks for helping :)
>
> > A "reboot" cau
On 4 October 2012 16:18, Bernard Ogden wrote:
> Does the Red button work when the core is just running Boot Monitor?
No... It has no effect during that time.
--
viresh
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mai
No problem, I'm just playing piggy-in-the-middle :)
Does the Red button work when the core is just running Boot Monitor?
If not then it may be a hardware problem and I'll ping the platform folks
again. Otherwise it's more likely to be something going on in Linux-land and
we'll need to wait for
On 4 October 2012 14:48, Bernard Ogden wrote:
> Pawel's on holiday this week. I'm no expert in this area, but I ran your
> question past one of our platform guys. Does the following help?
Thanks for helping :)
> A "reboot" causes the motherboard micro to reset and do all its stuff like
> repro
Prepare devfreq core framework to support devices which
can idle. When device idleness is detected perhaps through
runtime-pm, need some mechanism to suspend devfreq load
monitoring and resume back when device is online. Present
code continues monitoring unless device is removed from
devfreq core.
This patchset updates devfreq core to add support for devices
which can idle. When device idleness is detected perhaps
through runtime-pm, need some mechanism to suspend devfreq
load monitoring and resume when device is back online.
patch 1 introduce core design changes - per device work, decouple
Add devfreq suspend/resume apis for devfreq users. This patch
supports suspend and resume of devfreq load monitoring, required
for devices which can idle.
Signed-off-by: Rajagopal Venkat
Acked-by: MyungJoo Ham
---
drivers/devfreq/devfreq.c | 28
driv
Devfreq returns governor predicted frequency as current frequency
via sysfs interface. But device may not support all frequencies
that governor predicts. So add a callback in device profile to get
current freq from driver. Also add a new sysfs node to expose
governor predicted next target frequency
Hi Viresh,
Pawel's on holiday this week. I'm no expert in this area, but I ran your
question past one of our platform guys. Does the following help?
A "reboot" causes the motherboard micro to reset and do all its stuff like
reprogramming the FPGA and then reset the core which then runs boot mon
Hi Andrey
Now I'm providing a single LT topic based off linux-linaro-core-tracking
(llct), and you said that you need everyone to base off the same version
of llct, don't we need some kind of notification system where you
announce a plan to rebuild linux-linaro and give us a version of llct to
bas
On 22 September 2012 00:02, wrote:
> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
> +void __init arch_get_hmp_domains(struct list_head *hmp_domains_list)
> +{
> + struct cpumask hmp_fast_cpu_mask;
> + struct cpumask hmp_slow_cpu_mask;
can be merged to single
26 matches
Mail list logo
