Title: Samsung Enterprise Portal mySingle
> 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
> On 27 September 2012 13:50, MyungJoo Ham wrote:
> >> 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
Quoting Graeme Russ (2012-10-01 19:58:14)
> Hello,
>
> Firstly, sorry if this is the wrong forum - please feel free to
> re-direct me to a more appropriate place.
>
> I've been searching around for the 'net for a while but really have
> not come across a conclusive answer to just how well the fre
Hello,
Firstly, sorry if this is the wrong forum - please feel free to
re-direct me to a more appropriate place.
I've been searching around for the 'net for a while but really have
not come across a conclusive answer to just how well the free software
community is supported by ARM vendors. Now I
On Sunday 30 of September 2012 18:34:31 Daniel Lezcano wrote:
> On 09/30/2012 12:07 AM, Rafael J. Wysocki wrote:
> > On Saturday, September 29, 2012, Daniel Lezcano wrote:
> >> On 09/29/2012 11:41 AM, Francesco Lavra wrote:
> >>> Hi,
> >> Hi Francesco,
> >>
> >> thanks for reviewing the patch.
> >>
On Monday 01 of October 2012 15:42:39 Vincent Guittot wrote:
> Hi Rafael,
>
> Ping.
I'm considering this for v3.8, but I'd like Paul (CCed) to tell me what he
thinks about it.
Thanks,
Rafael
> On 25 September 2012 15:42, Vincent Guittot
> wrote:
> > synchronize_rcu blocks the caller of opp_e
On Monday 01 of October 2012 15:42:39 Vincent Guittot wrote:
> Hi Rafael,
>
> Ping.
I'm considering this for v3.8, but I'd like Paul (CCed) to tell me what he
thinks about it.
Thanks,
Rafael
> On 25 September 2012 15:42, Vincent Guittot
> wrote:
> > synchronize_rcu blocks the caller of opp_e
>>> For omap34/35xx class hardware definitely turn on
>>> CONFIG_ARM_ERRATA_430973=y
>>>
>>> When using a mix of arm/thumb application binaries on this core.
I can confirm that this fixed my problem. The other two errata seem to have
no noticeable effect, e.g. not using them doesn't cause cras
On Mon, 2012-10-01 at 17:35 +0100, Dave Martin wrote:
> On Thu, Sep 27, 2012 at 07:06:19PM +0100, Jon Medhurst (Tixy) wrote:
> > From: Jon Medhurst
> >
> > We will be reusing this functionality later.
>
> Commit message? ;)
>
Yep, that's what it is ;-) Couldn't think what more needed to be sai
On Mon, 2012-10-01 at 17:33 +0100, Dave Martin wrote:
> On Thu, Sep 27, 2012 at 07:06:20PM +0100, Jon Medhurst (Tixy) wrote:
> > + if (offset >= 0) {
> > + p = fdt_getprop(fdt, offset, "reg", &len);
> > + if(len != (addrcells + sizecells) * 4)
> > + info("Fai
On Thu, Sep 27, 2012 at 07:06:18PM +0100, Jon Medhurst (Tixy) wrote:
> From: Jon Medhurst
>
> Check all the CPU affinity fields of MPIDR, so we select only
> the first CPU of the first cluster as the one to boot on.
This seems reasonable.
The bfc could be a bic, but we only care about ARMv7 her
On Thu, Sep 27, 2012 at 07:06:19PM +0100, Jon Medhurst (Tixy) wrote:
> From: Jon Medhurst
>
> We will be reusing this functionality later.
Commit message? ;)
Makes sense to factor this out, though.
Cheers
---Dave
> Signed-off-by: Jon Medhurst
> ---
> semi_loader.c | 56 +++
On Thu, Sep 27, 2012 at 07:06:20PM +0100, Jon Medhurst (Tixy) wrote:
> From: Jon Medhurst
>
> The A15xA7 models simulate a Cache Coherent Interconnect (CCI) and this
> needs to be initialised correctly for Linux to boot.
>
> To perform this initiation we add the new function configure_from_fdt()
Hi Rafael,
Ping.
Regards,
Vincent
On 25 September 2012 15:42, Vincent Guittot wrote:
> synchronize_rcu blocks the caller of opp_enable/disbale
> for a complete grace period. This blocking duration prevents
> any intensive use of the functions. Replace synchronize_rcu
> by call_rcu which will ca
On Thu, Sep 27, 2012 at 01:22:14PM +0100, Peter Maydell wrote:
> On 26 September 2012 18:08, Jon Medhurst (Tixy) wrote:
> > On Wed, 2012-09-26 at 16:01 +0100, Peter Maydell wrote:
> >> The patch has added an 'enter_hyp'
> >> call into the chunk of code which is relocated to some random
> >> addre
> did you have a look at arnd and anton comments regarding
> 'supplied-to' and boolean property
Try to keep your comments inline, situated below the relevant comment.
> >> + ab8500_battery_info: ab8500_bat_type {
> >> + battery-type = <2>;
> >> + thermistor-on-batctrl
Sorry, some mistakes:
> > From: "Rajanikanth H.V"
> >
> > - This patch adds device tree support for fuelguage driver
> > - optimize bm devices platform_data usage and of_probe(...)
> > Note: of_probe() routine for battery managed devices is made
> > common across all bm drivers.
Spelling er
On Mon, 01 Oct 2012, Rajanikanth H.V wrote:
> From: "Rajanikanth H.V"
>
> - This patch adds device tree support for fuelguage driver
> - optimize bm devices platform_data usage and of_probe(...)
> Note: of_probe() routine for battery managed devices is made
> common across all bm drivers.
>
On 1 October 2012 05:47, Viresh Kumar wrote:
> On 1 October 2012 06:02, Tejun Heo wrote:
>> It isn't about the CPU being actually idle?
>
> No. Being idle only from scheduler's perspective. :)
>
>> Also, if it's only about timers, shouldn't it be enough to implement
>> it for timer and delayed_wo
19 matches
Mail list logo