* [PATCH 01/14] pinctrl: SPEAr: add spi chipselect control driver
From: Linus Walleij @ 2012-11-15 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpomLRYAKJ=dNLVsjj1xf=G6xj4EcTpPmhSDvgBYUMXc1mA@mail.gmail.com>
On Thu, Nov 15, 2012 at 3:19 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 15 November 2012 19:47, Linus Walleij <linus.walleij@linaro.org> wrote:
>> Just one question: since this driver is not using any
>> pinctrl interfaces, why is it under drivers/pinctrl/*?
>>
>> Shouldn't it be under drivers/gpio from a technical
>> point of view?
>>
>> I think I'd accept it under drivers/pinctrl/spear/*
>> if you just want this to keep everything SPEAr-related
>> in one place though, so enlighten me.
>
> That's because they are controlling few pads. They are not
> actually gpio's but just pads that we are controlling.
>
> That's why we thought they are better in this place.
The grouping of drivers in the kernel is about what in-kernel
subsystem interface they're using, not how their electronics
work...
Since this driver is only using the GPIO API it should be
in drivers/gpio/gpio-*.c.
Many, many drivers in drivers/gpio* are controlling pads
too, so it will be in good company ;-)
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm
From: Omar Ramirez Luna @ 2012-11-15 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbaTupjayMLmgptfLtNkkk_GZL8RYQrYn8O7FG5GpANswg@mail.gmail.com>
On 15 November 2012 11:39, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> I do agree description is missing, again I thought I had done this
>> somewhere but looks like I didn't, will update these. If you think
>> these should be different patches please let me know, otherwise I
>> would like to keep a single *documented* patch.
>
> It seems like there are 3 different logical changes here:
>
> 1. remove clk_* invocations from iommu_fault_handler()
> 2. keep clocks enabled as long as iommu is enabled
> 3. convert to runtime pm
>
> If we split this to three patches in this order, you won't have to add
> and remove runtime pm functions.
>
> Let's do it, please. It's a small nuisance now, but may be really
> helpful in the future when someone tries to debug stuff and understand
> the motivation behind these changes. It'd make it much easier for you
> to document the changes, too: you have an entire commit log per
> change.
Ok, not a problem then.
Cheers,
Omar
^ permalink raw reply
* [PATCH 0/2] clk: ux500: Make mtu driver use apb_pclock
From: Mike Turquette @ 2012-11-15 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaFkS_8i=8FmVYujzm1cMe1+=SO6MJyUbFyFPX7xhz-YA@mail.gmail.com>
Quoting Linus Walleij (2012-11-15 05:29:32)
> On Thu, Nov 15, 2012 at 1:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > If I understand the problem at hand correctly, the safe solution
> > should be to base the ux500 clk changes on top of c3b9d1db23c4e,
> > which is in the nomadik/plat-removal branch in arm-soc that got
> > merged into next/multiplatform. I would prefer if you use that
> > as a base instead of the larger next/multiplatform branch that
> > also contains vt8500 and other changes.
>
> OK I'll take a stab at this and see if I can fix it...
>
I've dropped both of these patches from clk-next.
Regards,
Mike
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH] Remove inline from clock framework function definitions to build the kernel with GCC 4.7
From: Paul Walmsley @ 2012-11-15 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A52134.2010502@gmail.com>
+ Mike
On Thu, 15 Nov 2012, Igor Mazanov wrote:
> Remove inline from clock framework function definitions to
> build the kernel with GCC 4.7
sparse warns about this also.
> Signed-off-by: Igor Mazanov <i.mazanov@gmail.com>
This one is for Mike to deal with as CCF maintainer; it's out of the hands
of the OMAP folks.
Acked-by: Paul Walmsley <paul@pwsan.com>
> ---
> include/linux/clk-provider.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index c127315..f9f5e9e 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk);
> struct clk_hw *__clk_get_hw(struct clk *clk);
> u8 __clk_get_num_parents(struct clk *clk);
> struct clk *__clk_get_parent(struct clk *clk);
> -inline int __clk_get_enable_count(struct clk *clk);
> -inline int __clk_get_prepare_count(struct clk *clk);
> +int __clk_get_enable_count(struct clk *clk);
> +int __clk_get_prepare_count(struct clk *clk);
> unsigned long __clk_get_rate(struct clk *clk);
> unsigned long __clk_get_flags(struct clk *clk);
> int __clk_is_enabled(struct clk *clk);
> --
> 1.7.4.4
>
- Paul
^ permalink raw reply
* [PATCH] Remove inline from clock framework function definitions to build the kernel with GCC 4.7
From: Paul Walmsley @ 2012-11-15 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A53368.6090306@ti.com>
On Thu, 15 Nov 2012, Jon Hunter wrote:
>
> On 11/15/2012 11:07 AM, Igor Mazanov wrote:
> > Remove inline from clock framework function definitions to
> > build the kernel with GCC 4.7
>
> Adding Mike to the party ...
>
> May be good to add some details about the exact problem seen.
>
> I am seeing the same problem today with GCC 4.7 and Tony's master
> branch. For a bit of background it seems that for 4.7 not having
> the body of the inlined function available in the header is
> causing this error. Another example here [1].
>
> The actual compiler error seen for OMAP is ...
>
> In file included from arch/arm/mach-omap2/clockdomain.c:25:0:
> arch/arm/mach-omap2/clockdomain.c: In function ?clkdm_clk_disable?:
> include/linux/clk-provider.h:338:12: error: inlining failed in call to always_inline ?__clk_get_enable_count?: function body not available
> arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here
> make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
> make: *** [arch/arm/mach-omap2] Error 2
Yep this one is for Mike to fix in the main CCF code; it's not an
OMAP-specific issue. sparse warns about this too, so it's not just a gcc
4.7 problem.
> Do we also need to remove the inline from the functions declared in
> drivers/clk/clk.c too?
It's usually best to just let the compiler decide whether to inline
functions. For example, Documentation/CodingStyle Chapter 15.
- Paul
^ permalink raw reply
* [PATCH] RFC: pinctrl: grab default handler with bus notifiers
From: Stephen Warren @ 2012-11-15 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaXCA9ZDbkGTtdtFBWLhBKQmPf1=EgnLhUSqKOT1xU7oQ@mail.gmail.com>
On 11/15/2012 10:24 AM, Linus Walleij wrote:
> On Thu, Nov 15, 2012 at 3:26 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>
>> At ELCE, I've discussed with one person having an interesting use case:
>> they are using the same pin for two different purposes during the
>> system operation.
>>
>> At boot time, this pin is muxed as a SPI pin and is used to program the
>> bitstream of a FPGA. This is done in Linux, through a userspace
>> application.
>>
>> Then, once it is done, this pin is remuxed as a UART pin, and used to
>> communicate with another device on the board.
>
> This is not related to the current discussion but interesting
> anyway...
>
>> If the pinctrl configuration is done at probe() time inside the driver
>> core, then how can this kind of use case be supported? If each driver
>> does its own muxing, we could think of letting the SPI and UART driver
>> only do their muxing when the device is opened, and remove their muxing
>> when the device is closed, so that such sharing of pins for two
>> separate functions could be supported. Is this something we want to
>> support?
>
> This is trivial to support after this commit in the current patch
> queue:
> commit 1a78958dc212f3698fdc543857af80155cb30f7f
> pinctrl: reserve pins when states are activated
>
> Just define function maps for both devices using the same
> pins. Since the devices need to actively release their
> pins they need to go to a state which does not mux in
> any pins, so that the pins will be free:ed.
>
> This state can be any arbitrary string, but if so desired
> for consistency we can define something like
> #define PINCTRL_STATE_DECOUPLED "decoupled"
> in include/linux/pinctrl/pinctrl-state.h to clearly
> mark that this is a state where the device is not
> using any pins at all.
Well, you'd also need to explicitly code the pinmux logic into the UART
driver, so that the UART's default state didn't prevent the SPI driver
from temporarily acquiring the pin to program the FPGA. It's rather
nasty to put that into the UART driver, which would presumably otherwise
be completely generic and not need runtime pinmux state changes. I
wonder if interjecting a mux driver between the UART/SPI and the pins
would help here, although presumably the UART driver would still need
some way of interacting with the mux driver which wouldn't be any better...
^ permalink raw reply
* [PATCH] Remove inline from clock framework function definitions to build the kernel with GCC 4.7
From: Jon Hunter @ 2012-11-15 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A52134.2010502@gmail.com>
On 11/15/2012 11:07 AM, Igor Mazanov wrote:
> Remove inline from clock framework function definitions to
> build the kernel with GCC 4.7
Adding Mike to the party ...
May be good to add some details about the exact problem seen.
I am seeing the same problem today with GCC 4.7 and Tony's master
branch. For a bit of background it seems that for 4.7 not having
the body of the inlined function available in the header is
causing this error. Another example here [1].
The actual compiler error seen for OMAP is ...
In file included from arch/arm/mach-omap2/clockdomain.c:25:0:
arch/arm/mach-omap2/clockdomain.c: In function ?clkdm_clk_disable?:
include/linux/clk-provider.h:338:12: error: inlining failed in call to always_inline ?__clk_get_enable_count?: function body not available
arch/arm/mach-omap2/clockdomain.c:1001:28: error: called from here
make[1]: *** [arch/arm/mach-omap2/clockdomain.o] Error 1
make: *** [arch/arm/mach-omap2] Error 2
> Signed-off-by: Igor Mazanov <i.mazanov@gmail.com>
> ---
> include/linux/clk-provider.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index c127315..f9f5e9e 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk);
> struct clk_hw *__clk_get_hw(struct clk *clk);
> u8 __clk_get_num_parents(struct clk *clk);
> struct clk *__clk_get_parent(struct clk *clk);
> -inline int __clk_get_enable_count(struct clk *clk);
> -inline int __clk_get_prepare_count(struct clk *clk);
> +int __clk_get_enable_count(struct clk *clk);
> +int __clk_get_prepare_count(struct clk *clk);
> unsigned long __clk_get_rate(struct clk *clk);
> unsigned long __clk_get_flags(struct clk *clk);
> int __clk_is_enabled(struct clk *clk);
Do we also need to remove the inline from the functions declared in
drivers/clk/clk.c too?
Cheers
Jon
[1] https://bugs.launchpad.net/linaro-android/+bug/983496
^ permalink raw reply
* [PATCH] RFC: pinctrl: grab default handler with bus notifiers
From: Stephen Warren @ 2012-11-15 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY-tye5LNOwxQ-XrjM-x9RffAvj-tPfsFQA3ZWOY8P-Vw@mail.gmail.com>
On 11/15/2012 07:03 AM, Linus Walleij wrote:
> On Tue, Nov 13, 2012 at 7:35 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
>> On Mon, Nov 12, 2012 at 01:21:40PM -0700, Stephen Warren wrote:
>>> On 11/11/2012 05:22 AM, Linus Walleij wrote:
>>
>>>> Another solution that was discussed was whether to move
>>>> the default pinctrl handle and state grab to the device
>>>> core as an optional field in struct device itself, but
>>>> I'd like to first propose this less intrusive mechanism.
>>
>>> I think doing that approach makes a lot more sense; wouldn't it
>>> completely avoid the issues with deferred probe that this notifier-based
>>> method can't solve? It would also be very much in line with e.g.
>>> dev_get_regmap() - if every resource that a driver required were handled
>>> like that, then deferred probe could be significantly isolated into the
>>> driver core rather than in every driver...
>>
>> I have to say that I agree with this, notifiers seem to make life more
>> complicated for limited gain. Otherwise I guess we could enhance
>> notifiers so that they're able to trigger deferrals?
>
> OK I'll have to come up with a patch to the device core
> instead... it'll be much simpler anyway and if both of you guys
> can back it I guess Greg might be OK with it too.
I did have one thought here; how will this interact with hogs? If a
device's pinctrl configuration must be pinctrl_get()'d before the device
is probed, then a pinctrl device with hogs will never get probed because
it won't be registered to provide the pinctrl node parsing. Solutions
might include:
a) Some special case where if the pinctrl driver only can't probe due to
missing pinctrl from its own node, don't defer the probe, but defer the
pinctrl_get().
b) Separate out DT node parsing from device instantiation, so that the
driver can always parse the DT, without needing the context of a
specific pinctrl device to do so.
I haven't thought through this in any detail though.
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Grant Likely @ 2012-11-15 18:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211151810050.25381@marmot.wormnet.eu>
On Thu, Nov 15, 2012 at 6:11 PM, Jamie Lentin <jm@lentin.co.uk> wrote:
> On Thu, 15 Nov 2012, Grant Likely wrote:
>
>> On Sun, 11 Nov 2012 17:21:29 +0100, Andrew Lunn <andrew@lunn.ch> wrote:
>>>
>>> From: Jamie Lentin <jm@lentin.co.uk>
>>>
>>> Given appropriate devicetree bindings, this driver registers a
>>> pm_power_off function to set a GPIO line high/low to power down
>>> your board.
>>>
>>> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
>>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>>> ---
>>> .../devicetree/bindings/gpio/gpio-poweroff.txt | 22 ++++
>>> drivers/gpio/Kconfig | 10 ++
>>> drivers/gpio/Makefile | 2 +
>>> drivers/gpio/gpio-poweroff.c | 129
>>> ++++++++++++++++++++
>>
>>
>> This isn't a gpio controller driver. Don't put it into drivers/gpio
>
>
> There's a v2 which puts it in drivers/power/reset/gpio-poweroff.c
Okay, thanks.
g.
^ permalink raw reply
* [RFC PATCH 3.7.0-rc4] ARM:smp: introduce smp_notify_cpu_stop to fix kexec smp case
From: Srinivas KANDAGATLA @ 2012-11-15 18:17 UTC (permalink / raw)
To: linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Use-case is simple kexec on smp system.
Lets say there are two cores core-0 and core-1.
sequence here is:
As part of kexec call, the secondary cores are stopped by calling
machine_shutdown(), which in turn issues IPIs to off-line the other CPUs
and then call smp_ops.cpu_kill.
machine_shutdown invokes smp_send_stop from core-0 which then sends
IPI_CPU_STOP ipi message for core-1 and then smp_kill_cpus call
smp_ops.cpu_kill from core-0 with cpu=1.
The expectation here is that cpu_kill will relocate secondary-core
to safe location from primary-core(core-0).
This is a catch 22 situation for SOCs, which can't change PC's of other
cores. At the point when cpu_kill is invoked, it cant execute any
function calls for core-1, as it is off-line and is spinning in
cpu_relax.
So the only way is to put the core into safe place by executing some
SOC specific relocation code.
Having a callback from ipi handler when cpu is stopped would be very
usefull for SOC's which want to relocate the secondary-core to safe
location.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
---
Hi All,
I just tried kexec on an CA9 dual core board, and it looks like it is broken
on smp system.
It looks like its a very basic issue, Am not not sure if I missed something here?
It is almost impossible to get kexec working, For cases where SOC's can't change PC
of secondary-core from a primary-core.
As cpu_kill is the only callback which is invoked from primary core to stop an
secondary-core during machine_shutdown it to relocate the secondary-core to safe place,
as it is offine and it is spinning in cpu_relax.
Having a callback from ipi handler when cpu is stopped would be very usefull for SOC's
which want to relocate the secondary-core to safe location.
Thanks,
srini
arch/arm/include/asm/smp.h | 7 +++++++
arch/arm/kernel/smp.c | 3 +++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index 2e3be16..0071a54 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -100,6 +100,13 @@ struct smp_operations {
* This also gives us the initial stack to use for this CPU.
*/
int (*smp_boot_secondary)(unsigned int cpu, struct task_struct *idle);
+
+ /* Notify interested parties before parking core in cpu_relax.
+ * SOC's can park cores in safe place in this callback, is very useful
+ * for cases like kexec. Stopping cpu is the victim cpu in this case.
+ */
+ int (*smp_notify_cpu_stop)(unsigned int cpu);
+
#ifdef CONFIG_HOTPLUG_CPU
int (*cpu_kill)(unsigned int cpu);
void (*cpu_die)(unsigned int cpu);
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index fbc8b26..06fcef9 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -564,6 +564,9 @@ static void ipi_cpu_stop(unsigned int cpu)
local_fiq_disable();
local_irq_disable();
+ if (smp_ops.smp_notify_cpu_stop)
+ smp_ops.smp_notify_cpu_stop(cpu);
+
while (1)
cpu_relax();
}
--
1.7.0.4
^ permalink raw reply related
* [RFC v2 PATCH 2/2] sched: Use Per-Entity-Load-Tracking metric for load balancing
From: Vincent Guittot @ 2012-11-15 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115165422.17426.3978.stgit@preeti.in.ibm.com>
Hi Preeti,
On 15 November 2012 17:54, Preeti U Murthy <preeti@linux.vnet.ibm.com> wrote:
> Currently the load balancer weighs a task based upon its priority,and this
> weight consequently gets added up to the weight of the run queue that it is
> on.It is this weight of the runqueue that sums up to a sched group's load
> which is used to decide the busiest or the idlest group and the runqueue
> thereof.
>
> The Per-Entity-Load-Tracking metric however measures how long a task has
> been runnable over the duration of its lifetime.This gives us a hint of
> the amount of CPU time that the task can demand.This metric takes care of the
> task priority as well.Therefore apart from the priority of a task we also
> have an idea of the live behavior of the task.This seems to be a more
> realistic metric to use to compute task weight which adds upto the run queue
> weight and the weight of the sched group.Consequently they can be used for
> load balancing.
>
> The semantics of load balancing is left untouched.The two functions
> load_balance() and select_task_rq_fair() perform the task of load
> balancing.These two paths have been browsed through in this patch to make
> necessary changes.
>
> weighted_cpuload() and task_h_load() provide the run queue weight and the
> weight of the task respectively.They have been modified to provide the
> Per-Entity-Load-Tracking metric as relevant for each.
> The rest of the modifications had to be made to suit these two changes.
>
> Completely Fair Scheduler class is the only sched_class which contributes to
> the run queue load.Therefore the rq->load.weight==cfs_rq->load.weight when
> the cfs_rq is the root cfs_rq (rq->cfs) of the hierarchy.When replacing this
> with Per-Entity-Load-Tracking metric,cfs_rq->runnable_load_avg needs to be
> used as this is the right reflection of the run queue load when
> the cfs_rq is the root cfs_rq (rq->cfs) of the hierarchy.This metric reflects
> the percentage uptime of the tasks that are queued on it and hence that contribute
> to the load.Thus cfs_rq->runnable_load_avg replaces the metric earlier used in
> weighted_cpuload().
>
> The task load is aptly captured by se.avg.load_avg_contrib which captures the
> runnable time vs the alive time of the task against its priority.This metric
> replaces the earlier metric used in task_h_load().
>
> The consequent changes appear as data type changes for the helper variables;
> they abound in number.Because cfs_rq->runnable_load_avg needs to be big enough
> to capture the tasks' load often and accurately.
You are now using cfs_rq->runnable_load_avg instead of
cfs_rq->load.weight for calculation of cpu_load but
cfs_rq->runnable_load_avg is smaller or equal to cfs_rq->load.weight
value. This implies that the new value is smaller or equal to the old
statistic so you should be able to keep the same variable width for
the computation of cpu_load
>
> The following patch does not consider CONFIG_FAIR_GROUP_SCHED AND
> CONFIG_SCHED_NUMA.This is done so as to evaluate this approach starting from the
> simplest scenario.Earlier discussions can be found in the link below.
>
> Link: https://lkml.org/lkml/2012/10/25/162
> Signed-off-by: Preeti U Murthy<preeti@linux.vnet.ibm.com>
> ---
> include/linux/sched.h | 2 +-
> kernel/sched/core.c | 12 +++++----
> kernel/sched/fair.c | 64 +++++++++++++++++++++++++------------------------
> kernel/sched/sched.h | 2 +-
> 4 files changed, 40 insertions(+), 40 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 087dd20..302756e 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -924,7 +924,7 @@ struct sched_domain {
> unsigned int lb_count[CPU_MAX_IDLE_TYPES];
> unsigned int lb_failed[CPU_MAX_IDLE_TYPES];
> unsigned int lb_balanced[CPU_MAX_IDLE_TYPES];
> - unsigned int lb_imbalance[CPU_MAX_IDLE_TYPES];
> + u64 lb_imbalance[CPU_MAX_IDLE_TYPES];
> unsigned int lb_gained[CPU_MAX_IDLE_TYPES];
> unsigned int lb_hot_gained[CPU_MAX_IDLE_TYPES];
> unsigned int lb_nobusyg[CPU_MAX_IDLE_TYPES];
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 24d8b9b..4dea057 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -2415,8 +2415,8 @@ static const unsigned char
> * would be when CPU is idle and so we just decay the old load without
> * adding any new load.
> */
> -static unsigned long
> -decay_load_missed(unsigned long load, unsigned long missed_updates, int idx)
> +static u64
> +decay_load_missed(u64 load, unsigned long missed_updates, int idx)
> {
> int j = 0;
>
> @@ -2444,7 +2444,7 @@ decay_load_missed(unsigned long load, unsigned long missed_updates, int idx)
> * scheduler tick (TICK_NSEC). With tickless idle this will not be called
> * every tick. We fix it up based on jiffies.
> */
> -static void __update_cpu_load(struct rq *this_rq, unsigned long this_load,
> +static void __update_cpu_load(struct rq *this_rq, u64 this_load,
> unsigned long pending_updates)
> {
> int i, scale;
> @@ -2454,7 +2454,7 @@ static void __update_cpu_load(struct rq *this_rq, unsigned long this_load,
> /* Update our load: */
> this_rq->cpu_load[0] = this_load; /* Fasttrack for idx 0 */
> for (i = 1, scale = 2; i < CPU_LOAD_IDX_MAX; i++, scale += scale) {
> - unsigned long old_load, new_load;
> + u64 old_load, new_load;
>
> /* scale is effectively 1 << i now, and >> i divides by scale */
>
> @@ -2496,7 +2496,7 @@ static void __update_cpu_load(struct rq *this_rq, unsigned long this_load,
> void update_idle_cpu_load(struct rq *this_rq)
> {
> unsigned long curr_jiffies = ACCESS_ONCE(jiffies);
> - unsigned long load = this_rq->load.weight;
> + u64 load = this_rq->cfs.runnable_load_avg;
> unsigned long pending_updates;
>
> /*
> @@ -2546,7 +2546,7 @@ static void update_cpu_load_active(struct rq *this_rq)
> * See the mess around update_idle_cpu_load() / update_cpu_load_nohz().
> */
> this_rq->last_load_update_tick = jiffies;
> - __update_cpu_load(this_rq, this_rq->load.weight, 1);
> + __update_cpu_load(this_rq, this_rq->cfs.runnable_load_avg, 1);
>
> calc_load_account_active(this_rq);
> }
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index a9cdc8f..f8f3a29 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2935,9 +2935,9 @@ static void dequeue_task_fair(struct rq *rq, struct task_struct *p, int flags)
>
> #ifdef CONFIG_SMP
> /* Used instead of source_load when we know the type == 0 */
> -static unsigned long weighted_cpuload(const int cpu)
> +static u64 weighted_cpuload(const int cpu)
> {
> - return cpu_rq(cpu)->load.weight;
> + return cpu_rq(cpu)->cfs.runnable_load_avg;
> }
>
> /*
> @@ -2947,10 +2947,10 @@ static unsigned long weighted_cpuload(const int cpu)
> * We want to under-estimate the load of migration sources, to
> * balance conservatively.
> */
> -static unsigned long source_load(int cpu, int type)
> +static u64 source_load(int cpu, int type)
> {
> struct rq *rq = cpu_rq(cpu);
> - unsigned long total = weighted_cpuload(cpu);
> + u64 total = weighted_cpuload(cpu);
>
> if (type == 0 || !sched_feat(LB_BIAS))
> return total;
> @@ -2962,10 +2962,10 @@ static unsigned long source_load(int cpu, int type)
> * Return a high guess at the load of a migration-target cpu weighted
> * according to the scheduling class and "nice" value.
> */
> -static unsigned long target_load(int cpu, int type)
> +static u64 target_load(int cpu, int type)
> {
> struct rq *rq = cpu_rq(cpu);
> - unsigned long total = weighted_cpuload(cpu);
> + u64 total = weighted_cpuload(cpu);
>
> if (type == 0 || !sched_feat(LB_BIAS))
> return total;
> @@ -2978,13 +2978,13 @@ static unsigned long power_of(int cpu)
> return cpu_rq(cpu)->cpu_power;
> }
>
> -static unsigned long cpu_avg_load_per_task(int cpu)
> +static u64 cpu_avg_load_per_task(int cpu)
> {
> struct rq *rq = cpu_rq(cpu);
> unsigned long nr_running = ACCESS_ONCE(rq->nr_running);
>
> if (nr_running)
> - return rq->load.weight / nr_running;
> + return rq->cfs.runnable_load_avg / nr_running;
You now need to use div_u64 for all division of a 64bits variable like
runnable_load_avg otherwise it can't compile on 32bits platform like
ARM. This one is obvious because it appears in your patch but other
division could be now 64bits division
Regards,
Vincent
>
> return 0;
> }
> @@ -3131,7 +3131,7 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)
> {
> s64 this_load, load;
> int idx, this_cpu, prev_cpu;
> - unsigned long tl_per_task;
> + u64 tl_per_task;
> struct task_group *tg;
> unsigned long weight;
> int balanced;
> @@ -3149,14 +3149,14 @@ static int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)
> */
> if (sync) {
> tg = task_group(current);
> - weight = current->se.load.weight;
> + weight = current->se.avg.load_avg_contrib;
>
> this_load += effective_load(tg, this_cpu, -weight, -weight);
> load += effective_load(tg, prev_cpu, 0, -weight);
> }
>
> tg = task_group(p);
> - weight = p->se.load.weight;
> + weight = p->se.avg.load_avg_contrib;
>
> /*
> * In low-load situations, where prev_cpu is idle and this_cpu is idle
> @@ -3219,11 +3219,11 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> int this_cpu, int load_idx)
> {
> struct sched_group *idlest = NULL, *group = sd->groups;
> - unsigned long min_load = ULONG_MAX, this_load = 0;
> + u64 min_load = ~0ULL, this_load = 0;
> int imbalance = 100 + (sd->imbalance_pct-100)/2;
>
> do {
> - unsigned long load, avg_load;
> + u64 load, avg_load;
> int local_group;
> int i;
>
> @@ -3270,7 +3270,7 @@ find_idlest_group(struct sched_domain *sd, struct task_struct *p,
> static int
> find_idlest_cpu(struct sched_group *group, struct task_struct *p, int this_cpu)
> {
> - unsigned long load, min_load = ULONG_MAX;
> + u64 load, min_load = ~0ULL;
> int idlest = -1;
> int i;
>
> @@ -3911,7 +3911,7 @@ struct lb_env {
> struct cpumask *dst_grpmask;
> int new_dst_cpu;
> enum cpu_idle_type idle;
> - long imbalance;
> + long long imbalance;
> /* The set of CPUs under consideration for load-balancing */
> struct cpumask *cpus;
>
> @@ -4314,7 +4314,7 @@ static inline void update_h_load(long cpu)
> #ifdef CONFIG_SMP
> static unsigned long task_h_load(struct task_struct *p)
> {
> - return p->se.load.weight;
> + return p->se.avg.load_avg_contrib;
> }
> #endif
> #endif
> @@ -4327,21 +4327,21 @@ static unsigned long task_h_load(struct task_struct *p)
> struct sd_lb_stats {
> struct sched_group *busiest; /* Busiest group in this sd */
> struct sched_group *this; /* Local group in this sd */
> - unsigned long total_load; /* Total load of all groups in sd */
> + u64 total_load; /* Total load of all groups in sd */
> unsigned long total_pwr; /* Total power of all groups in sd */
> - unsigned long avg_load; /* Average load across all groups in sd */
> + u64 avg_load; /* Average load across all groups in sd */
>
> /** Statistics of this group */
> - unsigned long this_load;
> - unsigned long this_load_per_task;
> + u64 this_load;
> + u64 this_load_per_task;
> unsigned long this_nr_running;
> unsigned long this_has_capacity;
> unsigned int this_idle_cpus;
>
> /* Statistics of the busiest group */
> unsigned int busiest_idle_cpus;
> - unsigned long max_load;
> - unsigned long busiest_load_per_task;
> + u64 max_load;
> + u64 busiest_load_per_task;
> unsigned long busiest_nr_running;
> unsigned long busiest_group_capacity;
> unsigned long busiest_has_capacity;
> @@ -4363,9 +4363,9 @@ struct sd_lb_stats {
> */
> struct sg_lb_stats {
> unsigned long avg_load; /*Avg load across the CPUs of the group */
> - unsigned long group_load; /* Total load over the CPUs of the group */
> + u64 group_load; /* Total load over the CPUs of the group */
> unsigned long sum_nr_running; /* Nr tasks running in the group */
> - unsigned long sum_weighted_load; /* Weighted load of group's tasks */
> + u64 sum_weighted_load; /* Weighted load of group's tasks */
> unsigned long group_capacity;
> unsigned long idle_cpus;
> unsigned long group_weight;
> @@ -4688,9 +4688,9 @@ static inline void update_sg_lb_stats(struct lb_env *env,
> int local_group, int *balance, struct sg_lb_stats *sgs)
> {
> unsigned long nr_running, max_nr_running, min_nr_running;
> - unsigned long load, max_cpu_load, min_cpu_load;
> + u64 load, max_cpu_load, min_cpu_load;
> unsigned int balance_cpu = -1, first_idle_cpu = 0;
> - unsigned long avg_load_per_task = 0;
> + u64 avg_load_per_task = 0;
> int i;
>
> if (local_group)
> @@ -4698,7 +4698,7 @@ static inline void update_sg_lb_stats(struct lb_env *env,
>
> /* Tally up the load of all CPUs in the group */
> max_cpu_load = 0;
> - min_cpu_load = ~0UL;
> + min_cpu_load = ~0ULL;
> max_nr_running = 0;
> min_nr_running = ~0UL;
>
> @@ -4948,9 +4948,9 @@ static int check_asym_packing(struct lb_env *env, struct sd_lb_stats *sds)
> static inline
> void fix_small_imbalance(struct lb_env *env, struct sd_lb_stats *sds)
> {
> - unsigned long tmp, pwr_now = 0, pwr_move = 0;
> + u64 tmp, pwr_now = 0, pwr_move = 0;
> unsigned int imbn = 2;
> - unsigned long scaled_busy_load_per_task;
> + u64 scaled_busy_load_per_task;
>
> if (sds->this_nr_running) {
> sds->this_load_per_task /= sds->this_nr_running;
> @@ -5016,7 +5016,7 @@ void fix_small_imbalance(struct lb_env *env, struct sd_lb_stats *sds)
> */
> static inline void calculate_imbalance(struct lb_env *env, struct sd_lb_stats *sds)
> {
> - unsigned long max_pull, load_above_capacity = ~0UL;
> + u64 max_pull, load_above_capacity = ~0ULL;
>
> sds->busiest_load_per_task /= sds->busiest_nr_running;
> if (sds->group_imb) {
> @@ -5192,14 +5192,14 @@ static struct rq *find_busiest_queue(struct lb_env *env,
> struct sched_group *group)
> {
> struct rq *busiest = NULL, *rq;
> - unsigned long max_load = 0;
> + u64 max_load = 0;
> int i;
>
> for_each_cpu(i, sched_group_cpus(group)) {
> unsigned long power = power_of(i);
> unsigned long capacity = DIV_ROUND_CLOSEST(power,
> SCHED_POWER_SCALE);
> - unsigned long wl;
> + u64 wl;
>
> if (!capacity)
> capacity = fix_small_capacity(env->sd, group);
> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index bfd004a..cff1926 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -362,7 +362,7 @@ struct rq {
> */
> unsigned int nr_running;
> #define CPU_LOAD_IDX_MAX 5
> - unsigned long cpu_load[CPU_LOAD_IDX_MAX];
> + u64 cpu_load[CPU_LOAD_IDX_MAX];
> unsigned long last_load_update_tick;
> #ifdef CONFIG_NO_HZ
> u64 nohz_stamp;
>
^ permalink raw reply
* [PATCH] ARM: OMAP3: Devkit8000: Add DDC i2c_bus_num
From: Thomas Weber @ 2012-11-15 18:12 UTC (permalink / raw)
To: linux-arm-kernel
Add i2c bus number for DVI output.
The driver uses this to detect if a panel is connected and to read EDID.
Signed-off-by: Thomas Weber <thomas@tomweber.eu>
---
arch/arm/mach-omap2/board-devkit8000.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..6f04f0f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -139,6 +139,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio = -1,
+ .i2c_bus_num = 1,
};
static struct omap_dss_device devkit8000_dvi_device = {
--
1.8.0
^ permalink raw reply related
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Jamie Lentin @ 2012-11-15 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115180557.924713E197F@localhost>
On Thu, 15 Nov 2012, Grant Likely wrote:
> On Sun, 11 Nov 2012 17:21:29 +0100, Andrew Lunn <andrew@lunn.ch> wrote:
>> From: Jamie Lentin <jm@lentin.co.uk>
>>
>> Given appropriate devicetree bindings, this driver registers a
>> pm_power_off function to set a GPIO line high/low to power down
>> your board.
>>
>> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>> ---
>> .../devicetree/bindings/gpio/gpio-poweroff.txt | 22 ++++
>> drivers/gpio/Kconfig | 10 ++
>> drivers/gpio/Makefile | 2 +
>> drivers/gpio/gpio-poweroff.c | 129 ++++++++++++++++++++
>
> This isn't a gpio controller driver. Don't put it into drivers/gpio
There's a v2 which puts it in drivers/power/reset/gpio-poweroff.c
>
> g.
>
>
--
Jamie Lentin
^ permalink raw reply
* [PATCH 01/10] ARM: imx6q: print silicon version on boot
From: Moseley, Drew @ 2012-11-15 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351005779-30347-2-git-send-email-shawn.guo@linaro.org>
On Oct 23, 2012, at 11:22 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> i.MX6Q has 3 revisions 1.0, 1.1 and 1.2. Print revision on boot.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> arch/arm/mach-imx/mach-imx6q.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
Hi Shawn,
An addition to this patch to add some error checking. Thoughts?
Drew
Add error checking to imx6q_revision()
Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
---
arch/arm/mach-imx/mach-imx6q.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 265c311..072e32a 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -54,9 +54,16 @@ static int imx6q_revision(void)
if (!rev) {
np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
+ if (!np)
+ return IMX_CHIP_REVISION_UNKNOWN;
base = of_iomap(np, 0);
+ if (!base) {
+ of_node_put(np);
+ return IMX_CHIP_REVISION_UNKNOWN;
+ }
rev = readl_relaxed(base + IMX6Q_ANALOG_DIGPROG);
iounmap(base);
+ of_node_put(np);
}
switch (rev & 0xff) {
--
1.8.0
^ permalink raw reply related
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Grant Likely @ 2012-11-15 18:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352650891-18356-2-git-send-email-andrew@lunn.ch>
On Sun, 11 Nov 2012 17:21:29 +0100, Andrew Lunn <andrew@lunn.ch> wrote:
> From: Jamie Lentin <jm@lentin.co.uk>
>
> Given appropriate devicetree bindings, this driver registers a
> pm_power_off function to set a GPIO line high/low to power down
> your board.
>
> Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
> ---
> .../devicetree/bindings/gpio/gpio-poweroff.txt | 22 ++++
> drivers/gpio/Kconfig | 10 ++
> drivers/gpio/Makefile | 2 +
> drivers/gpio/gpio-poweroff.c | 129 ++++++++++++++++++++
This isn't a gpio controller driver. Don't put it into drivers/gpio
g.
^ permalink raw reply
* [PATCH 1/3] gpio: Add simple poweroff-gpio driver
From: Stephen Warren @ 2012-11-15 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115105954.GA17119@lizard>
On 11/15/2012 03:59 AM, Anton Vorontsov wrote:
> On Thu, Nov 15, 2012 at 11:35:36AM +0100, Linus Walleij wrote:
>> On Mon, Nov 12, 2012 at 7:58 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> On 11/12/2012 11:43 AM, Anton Vorontsov wrote:
>>
>>>> Should the gpio driver fix its bindings then?.. Polarity is a quite
>>>> generic concept of a GPIO, and flags are there for a reason. I'd rather
>>>> prefer having
>>>
>>> There is no "GPIO driver" to fix; each GPIO driver has its own bindings,
>>> and unfortunately, some of the GPIO binding authors chose not to include
>>> any flags cell in the GPIO specifier (e.g. Samsung ARM SoCs IIRC, but
>>> there are probably more).
>>
>> So can I read this something like we have been too liberal with the
>> GPIO DT bindings and they are now a bit messy and need to be shaped
>> up? I don't know how to achieve that :-(
>
> I guess there's really no reason to panic. :)
>
> 'git grep gpio-cells Documentation/' shows just mrvl-gpio.txt and
> twl6040.txt having the wrong gpio-cells (i.e. 1).
If there are too-few cells, the binding and driver can always be
expanded to support more cells in a backwards-compatible way.
> But even these can use one cells for both flags and pin number (unless you
> really have 4294967295 GPIOs per controller).
>
> FWIW, current Samsung SOCs use 3 and even 4 cells for a GPIO specifier,
> which is absolutely fine. Plus, the Samsung bindings do specify the
> inversion flag. So, unless we have a lot of other [undocumented] bindings,
> I don't see a big mess. And everything I currently see is fixable.
Oh, I always thought that the Samsung bindings were one of the major
issues here, but you're right - they do have the inversion flag already.
So, perhaps there really isn't an issue, and we should revisit the
GPIO-based regulator bindings and drivers, and allow them to
(additionally) rely on the GPIO flags in the standard way.
^ permalink raw reply
* [arm-soc:for-next 24/32] arch/arm/mach-omap2/board-generic.c:115:13: error: 'omap_prcm_restart' undeclared here (not in a function)
From: Arnd Bergmann @ 2012-11-15 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50a52344.hTPnPrYFuOqQEPAJ%fengguang.wu@intel.com>
On Thursday 15 November 2012, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
> head: 85f1e7156cfb396d46327b9e6cdf4dbf576f3bcc
> commit: 3b7b5ae34c4604e6a1e0724fc8bd60e44f07e1ef [24/32] Merge branch 'next/dt' into for-next
> config: make ARCH=arm omap2plus_defconfig
>
> Note: the arm-soc/for-next HEAD 85f1e71 builds fine.
> It only hurts bisectibility.
>
> All error/warnings:
>
> arch/arm/mach-omap2/board-generic.c:115:13: error: 'omap_prcm_restart' undeclared here (not in a function)
>
> vim +115 +/omap_prcm_restart arch/arm/mach-omap2/board-generic.c
>
Thanks for the fast report!
Not quite fast enough this time, I found the same problem 20 minutes
earlier and immediately fixed it already ;-)
Tony also reported this one already.
Arnd
^ permalink raw reply
* [arm-soc:for-next 24/32] arch/arm/mach-omap2/board-generic.c:115:13: error: 'omap_prcm_restart' undeclared here (not in a function)
From: Tony Lindgren @ 2012-11-15 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50a52344.hTPnPrYFuOqQEPAJ%fengguang.wu@intel.com>
* kbuild test robot <fengguang.wu@intel.com> [121115 09:21]:
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git for-next
> head: 85f1e7156cfb396d46327b9e6cdf4dbf576f3bcc
> commit: 3b7b5ae34c4604e6a1e0724fc8bd60e44f07e1ef [24/32] Merge branch 'next/dt' into for-next
> config: make ARCH=arm omap2plus_defconfig
>
> Note: the arm-soc/for-next HEAD 85f1e71 builds fine.
> It only hurts bisectibility.
>
> All error/warnings:
>
> arch/arm/mach-omap2/board-generic.c:115:13: error: 'omap_prcm_restart' undeclared here (not in a function)
>
> vim +115 +/omap_prcm_restart arch/arm/mach-omap2/board-generic.c
>
> 7dd9d502 Jon Hunter 2012-09-12 109 .init_early = omap3430_init_early,
> 7dd9d502 Jon Hunter 2012-09-12 110 .init_irq = omap_intc_of_init,
> 7dd9d502 Jon Hunter 2012-09-12 111 .handle_irq = omap3_intc_handle_irq,
> 7dd9d502 Jon Hunter 2012-09-12 112 .init_machine = omap_generic_init,
> 7dd9d502 Jon Hunter 2012-09-12 113 .timer = &omap3_secure_timer,
> 7dd9d502 Jon Hunter 2012-09-12 114 .dt_compat = omap3_gp_boards_compat,
> 7dd9d502 Jon Hunter 2012-09-12 @115 .restart = omap_prcm_restart,
> 7dd9d502 Jon Hunter 2012-09-12 116 MACHINE_END
> 8d61649d Benoit Cousson 2011-09-20 117 #endif
> 8d61649d Benoit Cousson 2011-09-20 118
Thanks I've posted a fix for that. The solution is to use
omap3xxx_restart there.
Regards,
Tony
^ permalink raw reply
* [PATCH v4 2/2] ARM: OMAP3/4: iommu: adapt to runtime pm
From: Ohad Ben-Cohen @ 2012-11-15 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALLhW=46xUZzuEBaQD7vsOTQOGR7bwXMSM_mugN_gWa-oqwfuw@mail.gmail.com>
Hi Omar,
On Thu, Nov 15, 2012 at 6:53 PM, Omar Ramirez Luna <omar.luna@linaro.org> wrote:
> On 14 November 2012 03:54, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> Most of the above questions imply this patch not only converts the
>> iommu to runtime PM, but may carry additional changes that may imply
>> previous implementation is sub-optimal. I hope we can clearly document
>> the motivation behind these changes too (maybe even consider
>> extracting them to a different patch ?).
>
> I didn't want to extract this changes into different patches since
> they could be included in this one, otherwise it would look like lines
> adding and then deleting runtime pm functions.
>
> I do agree description is missing, again I thought I had done this
> somewhere but looks like I didn't, will update these. If you think
> these should be different patches please let me know, otherwise I
> would like to keep a single *documented* patch.
It seems like there are 3 different logical changes here:
1. remove clk_* invocations from iommu_fault_handler()
2. keep clocks enabled as long as iommu is enabled
3. convert to runtime pm
If we split this to three patches in this order, you won't have to add
and remove runtime pm functions.
Let's do it, please. It's a small nuisance now, but may be really
helpful in the future when someone tries to debug stuff and understand
the motivation behind these changes. It'd make it much easier for you
to document the changes, too: you have an entire commit log per
change.
Thanks,
Ohad.
^ permalink raw reply
* [GIT PULL 1/5] omap non critical fixes for v3.8 merge window
From: Tony Lindgren @ 2012-11-15 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211151651.59049.arnd@arndb.de>
* Arnd Bergmann <arnd@arndb.de> [121115 08:54]:
> On Thursday 15 November 2012, Tony Lindgren wrote:
> > The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
> >
> > Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/fixes-non-critical-v4-signed
>
> Pulled all five. Please have a look to make sure everything you need is
> there now and still works.
Thanks! Diffs fine against what I have in omap-for-v3.8/tmp-merge
except for the following bit that breaks compile for omap2plus_defconfig,
maybe apply it directly to one of your branches?
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 15 Nov 2012 09:22:34 -0800
Subject: [PATCH] ARM: OMAP2+: Fix build for board-generic after a merge conflict
Commit 187e3e06 (ARM: OMAP2+: board files: use SoC-specific system
restart functions) changed to use SoC specific restart functions to
simplify the PRCM code. The changes done to board-generic.c in commit
7dd9d502 (ARM: OMAP3: Add generic machine descriptor for boards with
OMAP3 GP devices) need to be updated accordingly.
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -122,7 +122,7 @@ DT_MACHINE_START(OMAP3_GP_DT, "Generic OMAP3-GP (Flattened Device Tree)")
.init_machine = omap_generic_init,
.timer = &omap3_secure_timer,
.dt_compat = omap3_gp_boards_compat,
- .restart = omap_prcm_restart,
+ .restart = omap3xxx_restart,
MACHINE_END
#endif
^ permalink raw reply
* [PATCH] pinctrl: nomadik: Staticize non-exported symbols
From: Linus Walleij @ 2012-11-15 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352995295.10636.1.camel@phoenix>
On Thu, Nov 15, 2012 at 5:01 PM, Axel Lin <axel.lin@ingics.com> wrote:
> They are not referenced outside of this file, make them static.
>
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
Applied with Lee's ACK, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] Boottime: A tool for automatic measurement of kernel/bootloader boot time
From: Linus Walleij @ 2012-11-15 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211151225.31066.arnd@arndb.de>
On Thu, Nov 15, 2012 at 1:25 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 15 November 2012, Lee Jones wrote:
>>
>> > > +/* for automatic boot timing testcases */
>> > > +#define ATAG_BOOTTIME 0x41000403
>> > Where can I refer this ATAG usage? can you point out the reference URL
>> > or patches?
>>
>> I assumed this would be in Mainline u-boot, but apparently not.
>> On closer inspection of the internal ST-Ericsson u-boot, this
>> functionality appears to be provided by patches which currently
>> exist as delta. So in essence, the bootloader you use will have
>> to be patched in a similar way for you to retrieve information
>> surrounding bootloader boot times.
>>
>> And there was me thinking it was magic. ;)
>>
>
> And since we're moving away from ATAG on ux500 towards DT, it won't
> even work in the future. How essential is this part for the operation
> of your code?
To be fun we need some mechanism to pass this info from the
boot loader to the kernel.
I think most bootloaders are already dynamically altering their
device trees to put in things like memory size etc so this would
probably be done the same way: a standard binding like for
everything else, then put the data in there.
I don't know if Lee has a modifiable U-boot to try out such
concepts on though?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/1] ARM: ux500: Describe UART platform registering issues more accurately
From: Linus Walleij @ 2012-11-15 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352968401-6092-1-git-send-email-lee.jones@linaro.org>
On Thu, Nov 15, 2012 at 9:33 AM, Lee Jones <lee.jones@linaro.org> wrote:
> UARTs no longer require call-back information, since the reset
> call-back was removed in 43b5f0d69291374f602ad8e1817f329573a59010.
> The only AUXDATA dependencies remaining for UARTs are DMA settings.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 02/14] ARM: SPEAr13xx: DT: Add spics gpio controller nodes
From: Linus Walleij @ 2012-11-15 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpok7-iBCoYk+aAXZPsOODyh6tp2nutC+6wYOot-bK3=wkg@mail.gmail.com>
On Thu, Nov 15, 2012 at 3:08 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 15 November 2012 19:36, Linus Walleij <linus.walleij@linaro.org> wrote:
>> I seldom comment on individual DT bindings, I just want
>> to know that they're there :-)
>
> Its not that simple. You are required to Ack it, as we have added it in
> drivers/pinctrl/spear because we are controlling pins here :)
Yeah I saw, I've commented on it now..
Yours,
Linus Walleij
^ permalink raw reply
* Kernel uncompression error
From: Woody Wu @ 2012-11-15 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115093357.GN3290@n2100.arm.linux.org.uk>
2012-11-15 PM5:34?"Russell King - ARM Linux" <linux@arm.linux.org.uk>
>
> On Thu, Nov 15, 2012 at 07:35:30AM +0800, Woody Wu wrote:
> > ? 2012-11-15 AM1:34?"Russell King - ARM Linux" <linux@arm.linux.org.uk>
wrote:
> > >
> > > On Wed, Nov 14, 2012 at 10:23:55PM +0800, woody wrote:
> > > > I just built a 3.2.x ARM kernel and tried to have it boot by a boot
> > > > loader (vivi) on my s3c2410a ARM board. The kernel was built with
> > > > default configuration s3c2410.
> > >
> > > I reported that S3C2410 is totally dead with 3.x kernels about a month
> > > ago and got no response what so ever from anyone. I guess S3C2410 is
> > > just not cared for anymore.
> > >
> > > When I get sufficient motivation, I'll try and track down what's going
> > > wrong, but it means taking the old mailing list server (and now list
> > > archive) offline for a while.
> > >
> > > I don't think it's cache related; different image sizes seem to behave
> > > differently - and when they _do_ successfully decompress, they don't
> > > boot at all.
> >
> > So, in your opinion, what version of kernel I should go for s3c2410?
>
> lists.arm.linux.org.uk currently runs 2.6.32.8. That's the last working
> kernel I currently know of.
For the 2.6 kernel, I just found a working one, that 2.6.36. From 2.6.7 on,
even the compiling cant passed, an unresolved function call to a LED
backlight related function. But 2.6.36 work, passed compiling,
uncompressing, load and run.
> As I said, I tried several 3.x kernels, all of them failed.
By far, I probably met the same kind of error with you for the 3.x kernel.
Uncompressing done, then halt. I really hope someone told me there is a
working 3.2+ kernel since newer kernels usually have better driver surpport.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121116/2b45d9de/attachment.html>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox