Re: [PATCH V2 3/3] workqueue: Schedule work on non-idle cpu instead of current one

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

Re: [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge

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. >

Re: [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge

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

Re: [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge

> 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

Re: [PATCH v2 3/3] bootwrapper: Delay switch to Hyp mode until kernel entry

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

Re: [PATCH][RESEND] power: opp: rcu reclaim

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

Re: [PATCH 3/3] bootwrapper: Initialise CCI device if found in the fdt

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()

Re: [PATCH 2/3] bootwrapper: Factor out parsing of fdt #address-cells and #size-cells

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 +++

Re: [PATCH 1/3] bootwrapper: Allow for multiple clusters in boot CPU detection

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

Re: [PATCH 3/3] bootwrapper: Initialise CCI device if found in the fdt

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

Re: [PATCH 2/3] bootwrapper: Factor out parsing of fdt #address-cells and #size-cells

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

Re: [Gumstix-users] Linaro, Gumstix, and illegal instructions

>>> 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

Re: [PATCH][RESEND] power: opp: rcu reclaim

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

Re: [PATCH][RESEND] power: opp: rcu reclaim

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

Re: [PATCH 4/4] cpuidle - support multiple drivers

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. > >>

Question: What is the current level of Free Software support by vendors?

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

Re: Question: What is the current level of Free Software support by vendors?

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

Re: Re: [PATCH v3 1/3] devfreq: Core updates to support devices which can idle

> 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

Re: [PATCH v3 2/3] devfreq: Add suspend and resume apis

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