* [PATCH 4/9] pinctrl: SPEAr1310: fix clcd high resolution pin group name
From: Viresh Kumar @ 2012-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351329224.git.viresh.kumar@linaro.org>
From: Shiraz Hashim <shiraz.hashim@st.com>
All group names in SPEAr pinctrl have "_grp" at the end of their name. Do the
same for clcd_high_res_grp.
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/pinctrl/spear/pinctrl-spear1310.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear1310.c b/drivers/pinctrl/spear/pinctrl-spear1310.c
index d6cca8c..c720d09 100644
--- a/drivers/pinctrl/spear/pinctrl-spear1310.c
+++ b/drivers/pinctrl/spear/pinctrl-spear1310.c
@@ -461,7 +461,7 @@ static struct spear_pingroup clcd_high_res_pingroup = {
.nmodemuxs = ARRAY_SIZE(clcd_high_res_modemux),
};
-static const char *const clcd_grps[] = { "clcd_grp", "clcd_high_res" };
+static const char *const clcd_grps[] = { "clcd_grp", "clcd_high_res_grp" };
static struct spear_function clcd_function = {
.name = "clcd",
.groups = clcd_grps,
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH 3/9] pinctrl: SPEAr320: Correct pad mux entries for rmii/smii
From: Viresh Kumar @ 2012-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351329224.git.viresh.kumar@linaro.org>
From: Deepak Sikri <deepak.sikri@st.com>
pin entries of rmii and smii are interchanged by mistake. Fix it.
Signed-off-by: Deepak Sikri <deepak.sikri@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
drivers/pinctrl/spear/pinctrl-spear320.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear320.c b/drivers/pinctrl/spear/pinctrl-spear320.c
index 4fccf95..ca47b0e 100644
--- a/drivers/pinctrl/spear/pinctrl-spear320.c
+++ b/drivers/pinctrl/spear/pinctrl-spear320.c
@@ -2960,9 +2960,9 @@ static struct spear_function mii2_function = {
};
/* Pad multiplexing for cadence mii 1_2 as smii or rmii device */
-static const unsigned smii0_1_pins[] = { 10, 11, 13, 14, 15, 16, 17, 18, 19, 20,
+static const unsigned rmii0_1_pins[] = { 10, 11, 13, 14, 15, 16, 17, 18, 19, 20,
21, 22, 23, 24, 25, 26, 27 };
-static const unsigned rmii0_1_pins[] = { 10, 11, 21, 22, 23, 24, 25, 26, 27 };
+static const unsigned smii0_1_pins[] = { 10, 11, 21, 22, 23, 24, 25, 26, 27 };
static struct spear_muxreg mii0_1_muxreg[] = {
{
.reg = PMX_CONFIG_REG,
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH 2/9] pinctrl: SPEAr3xx: correct register space to configure pwm
From: Viresh Kumar @ 2012-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351329224.git.viresh.kumar@linaro.org>
From: Shiraz Hashim <shiraz.hashim@st.com>
To have pwm on pad no. 34 we also need to select between pwm and SD_LED
functions. Add this to pwm pin mux register configuration.
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Vipin Kumar <vipin.kumar@st.com>
---
drivers/pinctrl/spear/pinctrl-spear320.c | 4 ++++
drivers/pinctrl/spear/pinctrl-spear3xx.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/pinctrl/spear/pinctrl-spear320.c b/drivers/pinctrl/spear/pinctrl-spear320.c
index 020b1e0..4fccf95 100644
--- a/drivers/pinctrl/spear/pinctrl-spear320.c
+++ b/drivers/pinctrl/spear/pinctrl-spear320.c
@@ -2240,6 +2240,10 @@ static struct spear_muxreg pwm2_pin_34_muxreg[] = {
.mask = PMX_SSP_CS_MASK,
.val = 0,
}, {
+ .reg = MODE_CONFIG_REG,
+ .mask = PMX_PWM_MASK,
+ .val = PMX_PWM_MASK,
+ }, {
.reg = IP_SEL_PAD_30_39_REG,
.mask = PMX_PL_34_MASK,
.val = PMX_PWM2_PL_34_VAL,
diff --git a/drivers/pinctrl/spear/pinctrl-spear3xx.h b/drivers/pinctrl/spear/pinctrl-spear3xx.h
index 31f4434..7860b36 100644
--- a/drivers/pinctrl/spear/pinctrl-spear3xx.h
+++ b/drivers/pinctrl/spear/pinctrl-spear3xx.h
@@ -15,6 +15,7 @@
#include "pinctrl-spear.h"
/* pad mux declarations */
+#define PMX_PWM_MASK (1 << 16)
#define PMX_FIRDA_MASK (1 << 14)
#define PMX_I2C_MASK (1 << 13)
#define PMX_SSP_CS_MASK (1 << 12)
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH 1/9] pinctrl: SPEAr: Don't update all non muxreg bits on pinctrl_disable
From: Viresh Kumar @ 2012-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351329224.git.viresh.kumar@linaro.org>
Not all bits of a register are used for pinctrl in SPEAr. So only update bits
relevant to pinctrl using muxreg->mask.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/spear/pinctrl-spear.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/spear/pinctrl-spear.c b/drivers/pinctrl/spear/pinctrl-spear.c
index 5d4f44f..b1fd6ee 100644
--- a/drivers/pinctrl/spear/pinctrl-spear.c
+++ b/drivers/pinctrl/spear/pinctrl-spear.c
@@ -244,7 +244,7 @@ static int spear_pinctrl_endisable(struct pinctrl_dev *pctldev,
else
temp = ~muxreg->val;
- val |= temp;
+ val |= muxreg->mask & temp;
pmx_writel(pmx, val, muxreg->reg);
}
}
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH 0/9] Pinctrl: SPEAr: Fixes for 3.7-rc3
From: Viresh Kumar @ 2012-10-27 9:17 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
This patchset fixes many errors/mistakes in current pinctrl configurations for
various SPEAr SoCs. Please see if they can be merged in next rc release, if they
look fine to you.
--
viresh
Deepak Sikri (2):
pinctrl: SPEAr320: Correct pad mux entries for rmii/smii
pinctrl: SPEAr1340: Make DDR reset & clock pads as gpio
Shiraz Hashim (3):
pinctrl: SPEAr3xx: correct register space to configure pwm
pinctrl: SPEAr1310: fix clcd high resolution pin group name
pinctrl: SPEAr1310: add register entries for enabling pad direction
Vipul Kumar Samar (3):
pinctrl: SPEAr1310: Fix value of PERIP_CFG reigster and
MCIF_SEL_SHIFT
pinctrl: SPEAr1310: Separate out pci pins from pcie_sata pin group
pinctrl: SPEAr1340: Add clcd sleep mode pin configuration
Viresh Kumar (1):
pinctrl: SPEAr: Don't update all non muxreg bits on pinctrl_disable
drivers/pinctrl/spear/pinctrl-spear.c | 2 +-
drivers/pinctrl/spear/pinctrl-spear1310.c | 365 ++++++++++++++++++++++++++----
drivers/pinctrl/spear/pinctrl-spear1340.c | 41 +++-
drivers/pinctrl/spear/pinctrl-spear320.c | 8 +-
drivers/pinctrl/spear/pinctrl-spear3xx.h | 1 +
5 files changed, 367 insertions(+), 50 deletions(-)
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply
* [PATCH] arm: kirkwood: add support for ZyXEL NSA310
From: Andrew Lunn @ 2012-10-27 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210261857100.20029@mirri>
> > > +
> > > +static struct i2c_board_info __initdata nsa310_i2c_info[] = {
> > > + { I2C_BOARD_INFO("adt7476", 0x2e) },
> > > +};
> >
> > how far off from the adt7461 (lm90) is this? If similar, please
> > consider extending lm90's compatibility list and describing this in the
> > dts instead.
>
> I did move at least the I2C to DT. Good catch, this is something
> worth of a experimentation when a free time slot arrives. The chip seems
> to have some sort of compatibility mode with adt7463 so it might just
> work somehow with the other driver too.
Hi Tero
Thanks for moving the I2C bus setup to DT.
The lm90 driver explicitly supports the adt7461. No changes needed. Please
try adding the necessary DT, something like:
adt7476: adt7476a at 2e {
compatible = "lm90";
reg = <0x2e>;
};
Thanks
Andrew
^ permalink raw reply
* [GIT PULL] omap plat header removal for v3.8 merge window, part1
From: Russell King - ARM Linux @ 2012-10-27 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026223848.GY11908@atomide.com>
On Fri, Oct 26, 2012 at 03:38:49PM -0700, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [121026 10:57]:
> > * Arnd Bergmann <arnd@arndb.de> [121026 10:30]:
> > >
> > > Well, once CONFIG_MULTIPLATFORM gets enabled, the mach/*.h files are
> > > not visible to drivers any more, but they are still visible to files
> > > in plat-omap if you add a line like
> > >
> > > ccflags-$(CONFIG_ARCH_OMAP2) := -I$(srctree)/arch/arm/mach-omap2/include
> > > ccflags-$(CONFIG_ARCH_OMAP1) := -I$(srctree)/arch/arm/mach-omap1/include
> > >
> > > to arch/arm/plat-omap/Makefile. That is how the other multiplatform
> > > Makefiles do it. If a driver writer really wants to cheat, they can of
> > > course do the same thing in their directory, but they can also do
> > > #include "../../../../arch/arm/mach-omap2/foo.h"
> >
> > OK thanks for clarifying that. Sounds like that can be used to
> > fix up the relative includes for plat-omap. I'll do some patches
> > for that after we have the #include <plat/*.h> and #include <mach/*.h>
> > issue sorted out.
>
> Here's a patch for that. It's against what I have queued up in
> omap-for-v3.8/cleanup-headers. Does that look OK to you?
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren <tony@atomide.com>
> Date: Fri, 26 Oct 2012 15:06:40 -0700
> Subject: [PATCH] ARM: OMAP: Fix relative includes for plat-omap with ccflags
>
> As suggested by Arnd Bergmann <arnd@arndb.de>, we can keep
> these headers local to arch/arm/*omap*/ by modifying the
> ccflags in plat/omap/Makefile.
>
> Note that eventually even most of these will go away
> as things like SRAM and PRCM become just regular device
> drivers.
>
> Also note that this will not fix plat/cpu.h, but that
> will be removed anyways as soon as the drivers are
> fixed.
>
> While at it, also sort the includes the standard way.
>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
>
> diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
> index cd169c3..03b1e80 100644
> --- a/arch/arm/mach-omap1/Makefile
> +++ b/arch/arm/mach-omap1/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for the linux kernel.
> #
>
> +ccflags-$(CONFIG_ARCH_OMAP) := -I$(srctree)/arch/arm
> +
Rather than moving all the files from plat-omap/include/plat into plat-omap
and then having all these totally disgusting relative includes, why don't
you add to these makefiles:
ccflags += -I$(srctree)/arch/arm/plat-omap/include
and avoid all that include moving and all the include name fixup?
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Andrew Lunn @ 2012-10-27 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210262217.46393.michael@walle.cc>
On Fri, Oct 26, 2012 at 10:17:46PM +0200, Michael Walle wrote:
> Hi Thomas.
>
> Am Freitag 26 Oktober 2012, 20:45:05 schrieb Thomas Petazzoni:
> > Ah, this is interesting. It is not entirely surprising, since the gpio
> > driver is new. Even though it re-uses most of the previous gpio driver,
> > it is by far not impossible that there will be a few regressions.
> >
> > Could you add a few debug prints to see if you're looping *inside* the
> > function (which I find pretty unlikely), or if the function gets called
> > over and over again?
>
> ah sorry, my bad. of course the handler is called forever:
>
> mvebu_gpio_to_irq pin=8
> mvebu_gpio_irq_set_type pin=8
> mvebu_gpio_edge_irq_unmask
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=100
> mvebu_gpio_level_irq_mask irq=100
> mvebu_gpio_irq_handler irq=101
> mvebu_gpio_level_irq_mask irq=101
> mvebu_gpio_irq_handler irq=102
> mvebu_gpio_level_irq_mask irq=102
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=112
> mvebu_gpio_level_irq_mask irq=112
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=103
> mvebu_gpio_level_irq_mask irq=103
> mvebu_gpio_irq_handler irq=103
That makes me think edge vs level triggering.
For gpio-keys you want edge triggered interrupts, but if the
controller is setup for level, you would see this.
Try adding some debug into the function mvebu_gpio_irq_set_type()
Andrew
^ permalink raw reply
* [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to pr_warn()
From: Sekhar Nori @ 2012-10-27 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C14311F0E03@DFLE08.ent.ti.com>
On 10/27/2012 6:29 AM, Tivy, Robert wrote:
> Thanks for your comments, Sergei. Please see below...
>
>> -----Original Message-----
>> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
>> Sent: Friday, October 26, 2012 2:46 AM
>> To: Tivy, Robert
>> Cc: davinci-linux-open-source at linux.davincidsp.com; linux-arm-
>> kernel at lists.infradead.org; Ring, Chris; Grosen, Mark; Nori, Sekhar
>> Subject: Re: [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to
>> pr_warn()
>>
>> Hello.
>>
>> It's not a good idea to send multiple patches with the same
>> subject.
>> Actually, in this case it's worth merging all 4 patches into one.
>
> My first patch submission had them all as one patch, but Sekhar asked that they be split into 4 separate patches to make the merge easier.
>
> I can make each one have a different subject, though.
Yes, it was I who asked for the patch to be separated out. My main
motivation was to keep board and soc file changes from mixing together.
The subject line for each patch should be different though.
>
>>
>> On 26-10-2012 0:35, Robert Tivy wrote:
>>
>>> Also, while modifying those pr_warning() calls I changed hardcoded
>>> function names to use '"%s:", __func__' instead
>>
>>> Signed-off-by: Robert Tivy <rtivy@ti.com>
>>> ---
>>> Clean up files that will be otherwise modified in subsequent patch.
>>
>>> Applies to v3.5 tag (commit 28a33cbc24e4256c143dce96c7d93bf423229f92)
>> of
>>> Linus' mainline kernel at git.kernel.org.
>>
>> 3.5 is too old. Why not to 3.6 or even 3.7-rc2?
>
> I will attempt to recreate this patch series on 3.7-rc2, although I will need to change it to use the newer "rproc" APIs and data structures.
All the more reason to rebase to v3.7-rc2!
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 6/9] ARM: Kirkwood: Convert GoFlex Net to pinctrl.
From: Andrew Lunn @ 2012-10-27 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMW5UfZ9KiDX=XHApvTGC=Um+RX-h8ZsvOVVwHyLH7cW==Qy7g@mail.gmail.com>
On Fri, Oct 26, 2012 at 01:28:08PM -0400, Josh Coombs wrote:
> Initial test with my 3.7-rc2 DT kernel config failed when it tried to
> build modules:
>
> Building modules, stage 2.
> MODPOST 733 modules
> ERROR: "read_current_timer" [drivers/video/udlfb.ko] undefined!
> ERROR: "read_current_timer" [crypto/tcrypt.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> I didn't realize my play kernel test package still includes the
> following patch, I thought it had been dealt with already. Should I
> start a new thread on this issue?
Hi Josh
It is a known issue which i've seen discussed on the lists. I expect
it to be fixed soon.
Andrew
^ permalink raw reply
* [GIT PULL] omap plat header removal for v3.8 merge window, part1
From: Arnd Bergmann @ 2012-10-27 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026223848.GY11908@atomide.com>
On Friday 26 October 2012, Tony Lindgren wrote:
> Here's a patch for that. It's against what I have queued up in
> omap-for-v3.8/cleanup-headers. Does that look OK to you?
Hi Tony,
thanks for the quick follow-up. Using the absolute #include statements
again looks good, but now there is another problem:
> diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
> index cd169c3..03b1e80 100644
> --- a/arch/arm/mach-omap1/Makefile
> +++ b/arch/arm/mach-omap1/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for the linux kernel.
> #
>
> +ccflags-$(CONFIG_ARCH_OMAP) := -I$(srctree)/arch/arm
> +
This is not what I meant, I don't think we want to have the entire
arch/arm/ hierarchy visible in platform directories. Instead, I thought
we'd keep using the existing arch/arm/mach-$foo/include/mach directories
that are currently visible to all files and make them available only
to platforms that explicitly add -I$(srctree)/arch/arm/include/mach-$foo/include
to their local include path.
This of course requires moving all those headers back to where they just came
from.
Arnd
^ permalink raw reply
* [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler
From: Preeti U Murthy @ 2012-10-27 3:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026130715.GB9886@gmail.com>
On 10/26/2012 06:37 PM, Ingo Molnar wrote:
>
> * Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
>> [...]
>>
>> So a sane series would introduce maybe two functions:
>> cpu_load() and task_load() and use those where we now use
>> rq->load.weight and p->se.load.weight for load balancing
>> purposes. Implement these functions using those two
>> expression. So effectively this patch is a NOP.
>>
>> Secondly, switch these two functions over to the per-task
>> based averages.
>>
>> Tada! all done. The load balancer will then try and equalize
>> effective load instead of instant load.
>>
>> It will do the 3x10% vs 100% thing correctly with just those
>> two patches. Simply because it will report a lower cpu-load
>> for the 3x10% case than it will for the 100% case, no need to
>> go fudge about in the load-balance internals.
>>
>> Once you've got this correctly done, you can go change
>> balancing to better utilize the new metric, like use the
>> effective load instead of nr_running against the capacity and
>> things like that. But for every such change you want to be
>> very careful and run all the benchmarks you can find -- in
>> fact you want to do that after the 2nd patch too.
>
> If anyone posted that simple two-patch series that switches over
> to the new load metrics I'd be happy to test the performance of
> those.
>
> Having two parallel load metrics is really not something that we
> should tolerate for too long.
>
> Thanks,
>
> Ingo
>
Right Ingo.I will incorporate this approach and post out very soon.
Thank you
Regards
Preeti
^ permalink raw reply
* [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler
From: Preeti U Murthy @ 2012-10-27 3:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254553.16863.52.camel@twins>
On 10/26/2012 05:59 PM, Peter Zijlstra wrote:
> On Thu, 2012-10-25 at 23:42 +0530, Preeti U Murthy wrote:
> firstly, cfs_rq is the wrong place for a per-cpu load measure, secondly
> why add another load field instead of fixing the one we have?
Hmm..,rq->load.weight is the place.
>> So why didnt I replace? I added cfs_rq->runnable_load_avg as an
>> additional metric instead of replacing the older metric.I let the old
>> metric be as a dead metric and used the newer metric as an
>> alternative.so if this alternate metric does not do us good we have the
>> old metric to fall back on.
>
> That's wrong.. either it works and we can apply the patches or it
> doesn't and we won't. What you did makes it very hard to see you
> preserve the current balancer -- which afaict you don't, you change the
> balancer with the very first patch.
You are right on this Peter.
>
> Why not update weighted_cpuload(), update_idle_cpu_load() and
> update_cpu_load_active() to use another metric and go from there. If you
> do that the whole balancer will auto-magically use the new weight
> measure.
>
> Once you have that running, you can look at modifying it.
Hmm...Correct.
>> a.find_busiest_group/find_idlest_group/update_sg_lb_stats:use sum of
>> cfs_rq->runnable_load_avg to decide this instead of sum of
>> cfs_rq->load.weight.
>
> But the first patches are about adding new balancing conditions, that's
> a complete fail..
>
>> b.find_busiest_queue/find_idlest_queue: use cfs_rq->runnable_load_avg
>> to decide this instead of cfs_rq->load.weight
>
> See, if you would have changed the input function (weighted_cpuload),
> you wouldn't have needed to touch any of this.
>
I see your point.
>> c.move_tasks: use se->avg.load_avg_contrib to decide the weight of of
>> each task instead of se->load.weight as the former reflects the runtime
>> of the sched entity and hence its actual load.
>
> The changelog in that patch (7) is completely devoid of any useful
> information.
>
>> This is what my patches3-13 do.Merely *Replace*.
>>
>> *Why am I doing it*: Feed the load balancer with a more realistic metric
>> to do load balancing and observe the consequences.
>
> I know why you're doing the entire thing, but you fail to motivate each
> individual change. A changelog should read something like:
>
> current code does blah, this has a problem when blah, we can improve
> this doing blah because blah.
>
Ah! I get it.
>>> you start out by some weird avoid short running task movement.
>>> why is that a good start?
>>
>> The short running tasks are not really burdening you,they have very
>> little run time,so why move them?
>
> The most important part is why this would be a good start to the series,
> it is not.
>
> The patch is also dubious at best; short running might be all you have,
> your definition of 'short' is also iffy.
My definition of 'short' was bursty loads.What I observed from using the
new metric to study the effective load calculation was,when there are
around 2-3 such bursty loads the effective load stays below the
threshold that i have stated,and I thought this would be a good enough
excuse to let the loads stay on the cpu.
Bursty being a load that sleeps for 9ms every 10ms for a duration of
10s.(a 10% load) in my experiments.
>
>> Throughout the concept of load balancing the focus is on *balancing the
>> *existing* load* between the sched groups.But not really evaluating the
>> *absolute load* of any given sched group.
>
> Which is why you're going to change the metrics.. the balancer really
> only cares about making load equal, flipping the metric of the load
> doesn't change anything fundamental.
Ok.
>
>> Why is this *the start*? This is like a round of elimination before the
>> actual interview round Try to have only those sched groups as
>> candidates for load balancing that are sufficiently loaded.[Patch1]
>> This *sufficiently loaded* is decided by the new metric explained in the
>> *How* above.
>
> No, this is absolutely wrong.
>
>
> So a sane series would introduce maybe two functions: cpu_load() and
> task_load() and use those where we now use rq->load.weight and
> p->se.load.weight for load balancing purposes. Implement these functions
> using those two expression. So effectively this patch is a NOP.
>
> Secondly, switch these two functions over to the per-task based
> averages.
>
> Tada! all done. The load balancer will then try and equalize effective
> load instead of instant load.
>
> It will do the 3x10% vs 100% thing correctly with just those two
> patches. Simply because it will report a lower cpu-load for the 3x10%
> case than it will for the 100% case, no need to go fudge about in the
> load-balance internals.
>
> Once you've got this correctly done, you can go change balancing to
> better utilize the new metric, like use the effective load instead of
> nr_running against the capacity and things like that. But for every such
> change you want to be very careful and run all the benchmarks you can
> find -- in fact you want to do that after the 2nd patch too.
>
I agree with this entire suggestion.Perhaps I was hesitant with
introducing the new metric into the scheduler which led to this two
faced approach.I will try out this approach suggested and post out the
results very soon.
Thank you very much for such a comprehensive and helpful feedback!
Regards
Preeti U Murthy
^ permalink raw reply
* [PATCHv9 0/8] ARM: OMAP4: core retention support
From: Paul Walmsley @ 2012-10-27 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350552010-28760-1-git-send-email-t-kristo@ti.com>
Hi Tero, Kevin,
On Thu, 18 Oct 2012, Tero Kristo wrote:
> Changes compared to previous version:
> - rebased on top of 3.7-rc1
> - applies on top of latest func pwrst code (v6)
> - added back patch #1 to this set (it wasn't queued yet after all)
That's because there was an interaction between it and the omap-serial
changes in the last merge window that caused several failures :-(
Hopefully it's good to go now...
> - added patch #7 for fixing a bug in the functional pwrst code
> - added patch #8 for fixing a regression with MUSB PHY power handling
> (not quite sure if this is the correct way to fix this or not)
>
> Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle +
> suspend.
>
> Branch also available here:
> git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
> branch: mainline-3.7-rc1-omap4-ret-v9
Looks like only patches #5 and #7 have dependencies on Jean's functional
powerstate series, so those should be postponed until that rework is
complete. Looks like #6 and #8 should go in via Tony, assuming there are
no dependencies on the rest of the patches. Have just queued #1 for 3.8
and kicked off a test to ensure that everything is working.
As far as the rest go, Kevin, do you want to take them?
- Paul
^ permalink raw reply
* [PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
From: Paul Walmsley @ 2012-10-27 3:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350552010-28760-2-git-send-email-t-kristo@ti.com>
Hi,
On Thu, 18 Oct 2012, Tero Kristo wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> OMAP4 has module specific context lost registers which makes it now
> possible to have module level context loss count, instead of relying
> on the powerdomain level context count.
>
> Add 2 private hwmod api's to update/clear the hwmod/module specific
> context lost counters/register.
>
> Update the module specific context_lost_counter and clear the hardware
> bits just after enabling the module.
>
> omap_hwmod_get_context_loss_count() now returns the hwmod context loss
> count them on platforms where they exist (OMAP4), else fall back on
> the pwrdm level counters for older platforms.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [paul at pwsan.com: added function kerneldoc, fixed structure kerneldoc,
> rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
> prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
> and clear, merged patches]
> [t-kristo at ti.com: added support for arch specific hwmod ops, and changed
> the no context offset indicator to USHRT_MAX]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> [paul at pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
> convert unsigned context lost counter to int to match the return type;
> get rid of hwmod_ops in favor of the existing soc_ops mechanism]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
Thanks, re-queued for 3.8.
- Paul
^ permalink raw reply
* [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used
From: Paul Walmsley @ 2012-10-27 2:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350552010-28760-9-git-send-email-t-kristo@ti.com>
Hi
On Thu, 18 Oct 2012, Tero Kristo wrote:
> Commit c9e4412ab8eb8ef82d645d8749c4ce96ad490007 removed all of the USB
> PHY functions for OMAP4, but this causes a problem with core retention
> as the MUSB module remains enabled if omap-usb2 phy driver is not used.
> This keeps the USB DPLL enabled and prevents l3_init pwrdm from idling.
>
> Fixed by adding a minimal function back that disables the USB PHY in
> case omap-usb2 driver is not used.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
Looks like another one for Tony...
- Paul
^ permalink raw reply
* [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic
From: Paul Walmsley @ 2012-10-27 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350552010-28760-7-git-send-email-t-kristo@ti.com>
Hi
On Thu, 18 Oct 2012, Tero Kristo wrote:
> From: Colin Cross <ccross@android.com>
>
> 'Workaround for ROM bug because of CA9 r2pX gic control'
> register change disables the gic distributor while the secondary
> cpu is being booted. If a localtimer interrupt on the primary cpu
> occurs when the distributor is turned off, the interrupt is lost,
> and the localtimer never fires again.
Looks like this one should go in separately via Tony.
- Paul
^ permalink raw reply
* [PATCH v5] pwm: vt8500: Update vt8500 PWM driver support
From: Tony Prisk @ 2012-10-27 1:49 UTC (permalink / raw)
To: linux-arm-kernel
This patch updates pwm-vt8500.c to support devicetree probing and
make use of the common clock subsystem.
A binding document describing the PWM controller found on
arch-vt8500 is also included.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
v4:
return err from clk_enable rather than -EBUSY
v5:
replace IS_ERR_OR_NULL with IS_ERR as pointed out by Chris Brand
.../devicetree/bindings/pwm/vt8500-pwm.txt | 17 ++++
drivers/pwm/pwm-vt8500.c | 86 ++++++++++++++------
2 files changed, 80 insertions(+), 23 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
new file mode 100644
index 0000000..bcc6367
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -0,0 +1,17 @@
+VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+
+Required properties:
+- compatible: should be "via,vt8500-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2. The first cell specifies the per-chip index
+ of the PWM to use and the second cell is the period in nanoseconds.
+- clocks: phandle to the PWM source clock
+
+Example:
+
+pwm1: pwm at d8220000 {
+ #pwm-cells = <2>;
+ compatible = "via,vt8500-pwm";
+ reg = <0xd8220000 0x1000>;
+ clocks = <&clkpwm>;
+};
diff --git a/drivers/pwm/pwm-vt8500.c b/drivers/pwm/pwm-vt8500.c
index ad14389..970b0c6 100644
--- a/drivers/pwm/pwm-vt8500.c
+++ b/drivers/pwm/pwm-vt8500.c
@@ -1,7 +1,8 @@
/*
* drivers/pwm/pwm-vt8500.c
*
- * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
+ * Copyright (C) 2012 Tony Prisk <linux@prisktech.co.nz>
+ * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -21,14 +22,24 @@
#include <linux/io.h>
#include <linux/pwm.h>
#include <linux/delay.h>
+#include <linux/clk.h>
#include <asm/div64.h>
-#define VT8500_NR_PWMS 4
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_address.h>
+
+/*
+ * SoC architecture allocates register space for 4 PWMs but only
+ * 2 are currently implemented.
+ */
+#define VT8500_NR_PWMS 2
struct vt8500_chip {
struct pwm_chip chip;
void __iomem *base;
+ struct clk *clk;
};
#define to_vt8500_chip(chip) container_of(chip, struct vt8500_chip, chip)
@@ -52,7 +63,7 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, prescale, pv, dc;
- c = 25000000/2; /* wild guess --- need to implement clocks */
+ c = clk_get_rate(vt8500->clk);
c = c * period_ns;
do_div(c, 1000000000);
period_cycles = c;
@@ -85,8 +96,15 @@ static int vt8500_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
static int vt8500_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
{
+ int err;
struct vt8500_chip *vt8500 = to_vt8500_chip(chip);
+ err = clk_enable(vt8500->clk);
+ if (err < 0)
+ dev_err(chip->dev, "failed to enable clock\n");
+ return err;
+ };
+
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(5, vt8500->base + (pwm->hwpwm << 4));
return 0;
@@ -98,6 +116,8 @@ static void vt8500_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
pwm_busy_wait(vt8500->base + 0x40 + pwm->hwpwm, (1 << 0));
writel(0, vt8500->base + (pwm->hwpwm << 4));
+
+ clk_disable(vt8500->clk);
}
static struct pwm_ops vt8500_pwm_ops = {
@@ -107,12 +127,24 @@ static struct pwm_ops vt8500_pwm_ops = {
.owner = THIS_MODULE,
};
-static int __devinit pwm_probe(struct platform_device *pdev)
+static const struct of_device_id vt8500_pwm_dt_ids[] = {
+ { .compatible = "via,vt8500-pwm", },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, vt8500_pwm_dt_ids);
+
+static int vt8500_pwm_probe(struct platform_device *pdev)
{
struct vt8500_chip *chip;
struct resource *r;
+ struct device_node *np = pdev->dev.of_node;
int ret;
+ if (!np) {
+ dev_err(&pdev->dev, "invalid devicetree node\n");
+ return -EINVAL;
+ }
+
chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
if (chip == NULL) {
dev_err(&pdev->dev, "failed to allocate memory\n");
@@ -124,6 +156,12 @@ static int __devinit pwm_probe(struct platform_device *pdev)
chip->chip.base = -1;
chip->chip.npwm = VT8500_NR_PWMS;
+ chip->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(chip->clk)) {
+ dev_err(&pdev->dev, "clock source not specified\n");
+ return PTR_ERR(chip->clk);
+ }
+
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (r == NULL) {
dev_err(&pdev->dev, "no memory resource defined\n");
@@ -131,18 +169,26 @@ static int __devinit pwm_probe(struct platform_device *pdev)
}
chip->base = devm_request_and_ioremap(&pdev->dev, r);
- if (chip->base == NULL)
+ if (!chip->base)
return -EADDRNOTAVAIL;
+ ret = clk_prepare(chip->clk);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to prepare clock\n");
+ return ret;
+ }
+
ret = pwmchip_add(&chip->chip);
- if (ret < 0)
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to add PWM chip\n");
return ret;
+ }
platform_set_drvdata(pdev, chip);
return ret;
}
-static int __devexit pwm_remove(struct platform_device *pdev)
+static int vt8500_pwm_remove(struct platform_device *pdev)
{
struct vt8500_chip *chip;
@@ -150,28 +196,22 @@ static int __devexit pwm_remove(struct platform_device *pdev)
if (chip == NULL)
return -ENODEV;
+ clk_unprepare(chip->clk);
+
return pwmchip_remove(&chip->chip);
}
-static struct platform_driver pwm_driver = {
+static struct platform_driver vt8500_pwm_driver = {
+ .probe = vt8500_pwm_probe,
+ .remove = vt8500_pwm_remove,
.driver = {
.name = "vt8500-pwm",
.owner = THIS_MODULE,
+ .of_match_table = vt8500_pwm_dt_ids,
},
- .probe = pwm_probe,
- .remove = __devexit_p(pwm_remove),
};
+module_platform_driver(vt8500_pwm_driver);
-static int __init pwm_init(void)
-{
- return platform_driver_register(&pwm_driver);
-}
-arch_initcall(pwm_init);
-
-static void __exit pwm_exit(void)
-{
- platform_driver_unregister(&pwm_driver);
-}
-module_exit(pwm_exit);
-
-MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("VT8500 PWM Driver");
+MODULE_AUTHOR("Tony Prisk <linux@prisktech.co.nz>");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to pr_warn()
From: Tivy, Robert @ 2012-10-27 0:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A5BF3.2060803@mvista.com>
Thanks for your comments, Sergei. Please see below...
> -----Original Message-----
> From: Sergei Shtylyov [mailto:sshtylyov at mvista.com]
> Sent: Friday, October 26, 2012 2:46 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> kernel at lists.infradead.org; Ring, Chris; Grosen, Mark; Nori, Sekhar
> Subject: Re: [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to
> pr_warn()
>
> Hello.
>
> It's not a good idea to send multiple patches with the same
> subject.
> Actually, in this case it's worth merging all 4 patches into one.
My first patch submission had them all as one patch, but Sekhar asked that they be split into 4 separate patches to make the merge easier.
I can make each one have a different subject, though.
>
> On 26-10-2012 0:35, Robert Tivy wrote:
>
> > Also, while modifying those pr_warning() calls I changed hardcoded
> > function names to use '"%s:", __func__' instead
>
> > Signed-off-by: Robert Tivy <rtivy@ti.com>
> > ---
> > Clean up files that will be otherwise modified in subsequent patch.
>
> > Applies to v3.5 tag (commit 28a33cbc24e4256c143dce96c7d93bf423229f92)
> of
> > Linus' mainline kernel at git.kernel.org.
>
> 3.5 is too old. Why not to 3.6 or even 3.7-rc2?
I will attempt to recreate this patch series on 3.7-rc2, although I will need to change it to use the newer "rproc" APIs and data structures.
>
> > diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-
> davinci/board-da850-evm.c
> > index 0149fb4..bbb3c73 100644
> > --- a/arch/arm/mach-davinci/board-da850-evm.c
> > +++ b/arch/arm/mach-davinci/board-da850-evm.c
> [...]
> > @@ -1046,21 +1046,19 @@ static int __init da850_evm_config_emac(void)
> > }
> >
> > if (ret)
> > - pr_warning("da850_evm_init: cpgmac/rmii mux setup failed:
> %d\n",
> > - ret);
> > + pr_warn("%s: cpgmac/rmii mux setup failed: %d\n",
> > + __func__, ret);
> >
> > /* configure the CFGCHIP3 register for RMII or MII */
> > __raw_writel(val, cfg_chip3_base);
> >
> > ret = davinci_cfg_reg(DA850_GPIO2_6);
> > if (ret)
> > - pr_warning("da850_evm_init:GPIO(2,6) mux setup "
> > - "failed\n");
> > + pr_warn("%s:GPIO(2,6) mux setup failed\n", __func__);
>
> Worth inserting space after colon here.
Will do.
>
> WBR, Sergei
Thanks & Regards,
- Rob
^ permalink raw reply
* [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Linus Walleij @ 2012-10-26 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026180349.3141.76336@nucleus>
On Fri, Oct 26, 2012 at 8:03 PM, Mike Turquette <mturquette@ti.com> wrote:
> Would be better to get ACKs but enough time has passed. I'll take these
> into clk-next (which will get built while I fly to Copenhagen for LCE).
OK FWIW: Acked-by: Linus Walleij <linus.walleij@linaro.org>
for all.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/2] ARM: integrator: get rid of preallocated irq descriptors
From: Linus Walleij @ 2012-10-26 23:33 UTC (permalink / raw)
To: linux-arm-kernel
The Integrators were using the .nr_irqs field of the machine
descriptor to pre-allocate a number of descriptors at boot. This
is not right: the irq chip implementations should allocate
their descriptors themselves, and as a result the simple
irqdomain code warns about it.
Get rid of this by just deleting the .nr_irq field from the
machine descriptors but take care: doing so makes the default
implementation hog the first 16 IRQ numbers, so these cannot
be used by the still static IRQ number assignments in the
ATAG boot case. So for these, bump the IRQ numbers to begin
at 64 and upward.
Introduce an offset to offset all IRQ numbers if need be,
though we don't expect to do that again as device tree comes
along.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/mach-integrator/include/mach/irqs.h | 109 +++++++++++++--------------
arch/arm/mach-integrator/integrator_ap.c | 2 -
arch/arm/mach-integrator/integrator_cp.c | 4 +-
3 files changed, 55 insertions(+), 60 deletions(-)
diff --git a/arch/arm/mach-integrator/include/mach/irqs.h b/arch/arm/mach-integrator/include/mach/irqs.h
index 7371018..eff0ada 100644
--- a/arch/arm/mach-integrator/include/mach/irqs.h
+++ b/arch/arm/mach-integrator/include/mach/irqs.h
@@ -19,64 +19,63 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-/*
- * Interrupt numbers
+/*
+ * Interrupt numbers, all of the above are just static reservations
+ * used so they can be encoded into device resources. They will finally
+ * be done away with when switching to device tree.
*/
-#define IRQ_PIC_START 1
-#define IRQ_SOFTINT 1
-#define IRQ_UARTINT0 2
-#define IRQ_UARTINT1 3
-#define IRQ_KMIINT0 4
-#define IRQ_KMIINT1 5
-#define IRQ_TIMERINT0 6
-#define IRQ_TIMERINT1 7
-#define IRQ_TIMERINT2 8
-#define IRQ_RTCINT 9
-#define IRQ_AP_EXPINT0 10
-#define IRQ_AP_EXPINT1 11
-#define IRQ_AP_EXPINT2 12
-#define IRQ_AP_EXPINT3 13
-#define IRQ_AP_PCIINT0 14
-#define IRQ_AP_PCIINT1 15
-#define IRQ_AP_PCIINT2 16
-#define IRQ_AP_PCIINT3 17
-#define IRQ_AP_V3INT 18
-#define IRQ_AP_CPINT0 19
-#define IRQ_AP_CPINT1 20
-#define IRQ_AP_LBUSTIMEOUT 21
-#define IRQ_AP_APCINT 22
-#define IRQ_CP_CLCDCINT 23
-#define IRQ_CP_MMCIINT0 24
-#define IRQ_CP_MMCIINT1 25
-#define IRQ_CP_AACIINT 26
-#define IRQ_CP_CPPLDINT 27
-#define IRQ_CP_ETHINT 28
-#define IRQ_CP_TSPENINT 29
-#define IRQ_PIC_END 29
+#define IRQ_PIC_START 64
+#define IRQ_SOFTINT (IRQ_PIC_START+0)
+#define IRQ_UARTINT0 (IRQ_PIC_START+1)
+#define IRQ_UARTINT1 (IRQ_PIC_START+2)
+#define IRQ_KMIINT0 (IRQ_PIC_START+3)
+#define IRQ_KMIINT1 (IRQ_PIC_START+4)
+#define IRQ_TIMERINT0 (IRQ_PIC_START+5)
+#define IRQ_TIMERINT1 (IRQ_PIC_START+6)
+#define IRQ_TIMERINT2 (IRQ_PIC_START+7)
+#define IRQ_RTCINT (IRQ_PIC_START+8)
+#define IRQ_AP_EXPINT0 (IRQ_PIC_START+9)
+#define IRQ_AP_EXPINT1 (IRQ_PIC_START+10)
+#define IRQ_AP_EXPINT2 (IRQ_PIC_START+11)
+#define IRQ_AP_EXPINT3 (IRQ_PIC_START+12)
+#define IRQ_AP_PCIINT0 (IRQ_PIC_START+13)
+#define IRQ_AP_PCIINT1 (IRQ_PIC_START+14)
+#define IRQ_AP_PCIINT2 (IRQ_PIC_START+15)
+#define IRQ_AP_PCIINT3 (IRQ_PIC_START+16)
+#define IRQ_AP_V3INT (IRQ_PIC_START+17)
+#define IRQ_AP_CPINT0 (IRQ_PIC_START+18)
+#define IRQ_AP_CPINT1 (IRQ_PIC_START+19)
+#define IRQ_AP_LBUSTIMEOUT (IRQ_PIC_START+20)
+#define IRQ_AP_APCINT (IRQ_PIC_START+21)
+#define IRQ_CP_CLCDCINT (IRQ_PIC_START+22)
+#define IRQ_CP_MMCIINT0 (IRQ_PIC_START+23)
+#define IRQ_CP_MMCIINT1 (IRQ_PIC_START+24)
+#define IRQ_CP_AACIINT (IRQ_PIC_START+25)
+#define IRQ_CP_CPPLDINT (IRQ_PIC_START+26)
+#define IRQ_CP_ETHINT (IRQ_PIC_START+27)
+#define IRQ_CP_TSPENINT (IRQ_PIC_START+28)
+#define IRQ_PIC_END (IRQ_PIC_START+28)
-#define IRQ_CIC_START 32
-#define IRQ_CM_SOFTINT 32
-#define IRQ_CM_COMMRX 33
-#define IRQ_CM_COMMTX 34
-#define IRQ_CIC_END 34
+#define IRQ_CIC_START (IRQ_PIC_END+1)
+#define IRQ_CM_SOFTINT (IRQ_CIC_START+0)
+#define IRQ_CM_COMMRX (IRQ_CIC_START+1)
+#define IRQ_CM_COMMTX (IRQ_CIC_START+2)
+#define IRQ_CIC_END (IRQ_CIC_START+2)
/*
* IntegratorCP only
*/
-#define IRQ_SIC_START 35
-#define IRQ_SIC_CP_SOFTINT 35
-#define IRQ_SIC_CP_RI0 36
-#define IRQ_SIC_CP_RI1 37
-#define IRQ_SIC_CP_CARDIN 38
-#define IRQ_SIC_CP_LMINT0 39
-#define IRQ_SIC_CP_LMINT1 40
-#define IRQ_SIC_CP_LMINT2 41
-#define IRQ_SIC_CP_LMINT3 42
-#define IRQ_SIC_CP_LMINT4 43
-#define IRQ_SIC_CP_LMINT5 44
-#define IRQ_SIC_CP_LMINT6 45
-#define IRQ_SIC_CP_LMINT7 46
-#define IRQ_SIC_END 46
-
-#define NR_IRQS_INTEGRATOR_AP 34
-#define NR_IRQS_INTEGRATOR_CP 47
+#define IRQ_SIC_START (IRQ_CIC_END+1)
+#define IRQ_SIC_CP_SOFTINT (IRQ_SIC_START+0)
+#define IRQ_SIC_CP_RI0 (IRQ_SIC_START+1)
+#define IRQ_SIC_CP_RI1 (IRQ_SIC_START+2)
+#define IRQ_SIC_CP_CARDIN (IRQ_SIC_START+3)
+#define IRQ_SIC_CP_LMINT0 (IRQ_SIC_START+4)
+#define IRQ_SIC_CP_LMINT1 (IRQ_SIC_START+5)
+#define IRQ_SIC_CP_LMINT2 (IRQ_SIC_START+6)
+#define IRQ_SIC_CP_LMINT3 (IRQ_SIC_START+7)
+#define IRQ_SIC_CP_LMINT4 (IRQ_SIC_START+8)
+#define IRQ_SIC_CP_LMINT5 (IRQ_SIC_START+9)
+#define IRQ_SIC_CP_LMINT6 (IRQ_SIC_START+10)
+#define IRQ_SIC_CP_LMINT7 (IRQ_SIC_START+11)
+#define IRQ_SIC_END (IRQ_SIC_START+11)
diff --git a/arch/arm/mach-integrator/integrator_ap.c b/arch/arm/mach-integrator/integrator_ap.c
index e6617c1..4f13bc5 100644
--- a/arch/arm/mach-integrator/integrator_ap.c
+++ b/arch/arm/mach-integrator/integrator_ap.c
@@ -499,7 +499,6 @@ static const char * ap_dt_board_compat[] = {
DT_MACHINE_START(INTEGRATOR_AP_DT, "ARM Integrator/AP (Device Tree)")
.reserve = integrator_reserve,
.map_io = ap_map_io,
- .nr_irqs = NR_IRQS_INTEGRATOR_AP,
.init_early = ap_init_early,
.init_irq = ap_init_irq_of,
.handle_irq = fpga_handle_irq,
@@ -609,7 +608,6 @@ MACHINE_START(INTEGRATOR, "ARM-Integrator")
.atag_offset = 0x100,
.reserve = integrator_reserve,
.map_io = ap_map_io,
- .nr_irqs = NR_IRQS_INTEGRATOR_AP,
.init_early = ap_init_early,
.init_irq = ap_init_irq,
.handle_irq = fpga_handle_irq,
diff --git a/arch/arm/mach-integrator/integrator_cp.c b/arch/arm/mach-integrator/integrator_cp.c
index 5b08e8e..4423bc8 100644
--- a/arch/arm/mach-integrator/integrator_cp.c
+++ b/arch/arm/mach-integrator/integrator_cp.c
@@ -350,7 +350,6 @@ static const char * intcp_dt_board_compat[] = {
DT_MACHINE_START(INTEGRATOR_CP_DT, "ARM Integrator/CP (Device Tree)")
.reserve = integrator_reserve,
.map_io = intcp_map_io,
- .nr_irqs = NR_IRQS_INTEGRATOR_CP,
.init_early = intcp_init_early,
.init_irq = intcp_init_irq_of,
.handle_irq = fpga_handle_irq,
@@ -423,7 +422,7 @@ static void __init intcp_init_irq(void)
u32 pic_mask, cic_mask, sic_mask;
/* These masks are for the HW IRQ registers */
- pic_mask = ~((~0u) << (11 - IRQ_PIC_START));
+ pic_mask = ~((~0u) << (11 - 0));
pic_mask |= (~((~0u) << (29 - 22))) << 22;
cic_mask = ~((~0u) << (1 + IRQ_CIC_END - IRQ_CIC_START));
sic_mask = ~((~0u) << (1 + IRQ_SIC_END - IRQ_SIC_START));
@@ -504,7 +503,6 @@ MACHINE_START(CINTEGRATOR, "ARM-IntegratorCP")
.atag_offset = 0x100,
.reserve = integrator_reserve,
.map_io = intcp_map_io,
- .nr_irqs = NR_IRQS_INTEGRATOR_CP,
.init_early = intcp_init_early,
.init_irq = intcp_init_irq,
.handle_irq = fpga_handle_irq,
--
1.7.11.7
^ permalink raw reply related
* [PATCH 1/2] ARM: plat-versatile: use simple irqdomain for FPGA IRQ
From: Linus Walleij @ 2012-10-26 23:32 UTC (permalink / raw)
To: linux-arm-kernel
This switches the FPGA IRQ driver over to using the simple IRQ
domain. We can then use the same codepath for this in the
DT and non-DT cases.
To be able to use quicker irq_find_mapping() in the handlers
we first call irq_create_mapping() on all the valid HW IRQ
numbers so that descriptors will be created for them in the
DT case where a linear domain will be the outcome of the
call.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
arch/arm/plat-versatile/fpga-irq.c | 50 +++++++++++++++++---------------------
1 file changed, 22 insertions(+), 28 deletions(-)
diff --git a/arch/arm/plat-versatile/fpga-irq.c b/arch/arm/plat-versatile/fpga-irq.c
index 091ae10..dfe317c 100644
--- a/arch/arm/plat-versatile/fpga-irq.c
+++ b/arch/arm/plat-versatile/fpga-irq.c
@@ -1,6 +1,7 @@
/*
* Support for Versatile FPGA-based IRQ controllers
*/
+#include <linux/bitops.h>
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/irqdomain.h>
@@ -117,13 +118,12 @@ static int fpga_irqdomain_map(struct irq_domain *d, unsigned int irq,
struct fpga_irq_data *f = d->host_data;
/* Skip invalid IRQs, only register handlers for the real ones */
- if (!(f->valid & (1 << hwirq)))
+ if (!(f->valid & BIT(hwirq)))
return -ENOTSUPP;
irq_set_chip_data(irq, f);
irq_set_chip_and_handler(irq, &f->chip,
handle_level_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
- f->used_irqs++;
return 0;
}
@@ -132,13 +132,15 @@ static struct irq_domain_ops fpga_irqdomain_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
-static __init struct fpga_irq_data *
-fpga_irq_prep_struct(void __iomem *base, const char *name, u32 valid) {
+void __init fpga_irq_init(void __iomem *base, const char *name, int irq_start,
+ int parent_irq, u32 valid, struct device_node *node)
+{
struct fpga_irq_data *f;
+ int i;
if (fpga_irq_id >= ARRAY_SIZE(fpga_irq_devices)) {
- printk(KERN_ERR "%s: too few FPGA IRQ controllers, increase CONFIG_PLAT_VERSATILE_FPGA_IRQ_NR\n", __func__);
- return NULL;
+ pr_err("%s: too few FPGA IRQ controllers, increase CONFIG_PLAT_VERSATILE_FPGA_IRQ_NR\n", __func__);
+ return;
}
f = &fpga_irq_devices[fpga_irq_id];
f->base = base;
@@ -147,29 +149,28 @@ fpga_irq_prep_struct(void __iomem *base, const char *name, u32 valid) {
f->chip.irq_mask = fpga_irq_mask;
f->chip.irq_unmask = fpga_irq_unmask;
f->valid = valid;
- fpga_irq_id++;
-
- return f;
-}
-
-void __init fpga_irq_init(void __iomem *base, const char *name, int irq_start,
- int parent_irq, u32 valid, struct device_node *node)
-{
- struct fpga_irq_data *f;
-
- f = fpga_irq_prep_struct(base, name, valid);
- if (!f)
- return;
if (parent_irq != -1) {
irq_set_handler_data(parent_irq, f);
irq_set_chained_handler(parent_irq, fpga_irq_handle);
}
- f->domain = irq_domain_add_legacy(node, fls(valid), irq_start, 0,
+ /* This will also allocate irq descriptors */
+ f->domain = irq_domain_add_simple(node, fls(valid), irq_start,
&fpga_irqdomain_ops, f);
+
+ /* This will allocate all valid descriptors in the linear case */
+ for (i = 0; i < fls(valid); i++)
+ if (valid & BIT(i)) {
+ if (!irq_start)
+ irq_create_mapping(f->domain, i);
+ f->used_irqs++;
+ }
+
pr_info("FPGA IRQ chip %d \"%s\" @ %p, %u irqs\n",
fpga_irq_id, name, base, f->used_irqs);
+
+ fpga_irq_id++;
}
#ifdef CONFIG_OF
@@ -193,18 +194,11 @@ int __init fpga_irq_of_init(struct device_node *node,
if (of_property_read_u32(node, "valid-mask", &valid_mask))
valid_mask = 0;
- f = fpga_irq_prep_struct(base, node->name, valid_mask);
- if (!f)
- return -ENOMEM;
+ fpga_irq_init(base, node->name, 0, -1, valid_mask, node);
writel(clear_mask, base + IRQ_ENABLE_CLEAR);
writel(clear_mask, base + FIQ_ENABLE_CLEAR);
- f->domain = irq_domain_add_linear(node, fls(valid_mask), &fpga_irqdomain_ops, f);
- f->used_irqs = hweight32(valid_mask);
-
- pr_info("FPGA IRQ chip %d \"%s\" @ %p, %u irqs\n",
- fpga_irq_id, node->name, base, f->used_irqs);
return 0;
}
#endif
--
1.7.11.7
^ permalink raw reply related
* [PATCH] i2c: omap: ensure writes to dev->buf_len are ordered
From: Paul Walmsley @ 2012-10-26 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351155648-20429-1-git-send-email-balbi@ti.com>
Hi Felipe
just two quick comments
On Thu, 25 Oct 2012, Felipe Balbi wrote:
> if we allow compiler reorder our writes, we could
> fall into a situation where dev->buf_len is reset
> for no apparent reason.
>
> This bug was found with a simple script which would
> transfer data to an i2c client from 1 to 1024 bytes
> (a simple for loop), when we got to transfer sizes
> bigger than the fifo size, dev->buf_len was reset
> to zero before we had an oportunity to handle XDR
> Interrupt. Because dev->buf_len was zero, we entered
> omap_i2c_transmit_data() to transfer zero bytes,
> which would mean we would just silently exit
> omap_i2c_transmit_data() without actually writing
> anything to DATA register. That would cause XDR
> IRQ to trigger forever and we would never transfer
> the remaining bytes.
>
> After adding the memory barrier, we also drop resetting
> dev->buf_len to zero in omap_i2c_xfer_msg() because
> both omap_i2c_transmit_data() and omap_i2c_receive_data()
> will act until dev->buf_len reaches zero, rendering the
> other write in omap_i2c_xfer_msg() redundant.
>
> This patch has been tested with pandaboard for a few
> iterations of the script mentioned above.
>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
> ---
>
> This bug has been there forever, but it's quite annoying.
> I think it deserves being pushed upstream during this -rc
> cycle, but if Wolfram decides to wait until v3.8, I don't
> mind.
>
> drivers/i2c/busses/i2c-omap.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..1ec4e6e 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -521,6 +521,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> /* REVISIT: Could the STB bit of I2C_CON be used with probing? */
> dev->buf = msg->buf;
> dev->buf_len = msg->len;
> + wmb();
>
> omap_i2c_write_reg(dev, OMAP_I2C_CNT_REG, dev->buf_len);
>
Would suggest moving the wmb() immediately before the point at which the
interrupt can occur. Looks to me that's when the OMAP_I2C_CON_REG write
occurs.
Also would suggest adding a comment to clarify what the wmb() is intended
to do. Maybe something like 'Prevent the compiler from moving earlier
changes to dev->buf and dev->buf_len after the write to CON_REG. This
write enables interrupts and those variables are used in the interrupt
handler'.
checkpatch is supposed to flag uncommented barriers, but maybe that's only
with --strict.
# check for memory barriers without a comment.
if ($line =~ /\b(mb|rmb|wmb|read_barrier_depends|smp_mb|smp_rmb|smp_wmb|smp_read_barrier_depends)\(/) {
if (!ctx_has_comment($first_line, $linenr)) {
CHK("MEMORY_BARRIER",
"memory barrier without comment\n" .
$herecurr);
}
}
- Paul
^ permalink raw reply
* [PATCH] arm: socfpga: fix build break for allyesconfig
From: Pavel Machek @ 2012-10-26 23:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026224358.GD21164@n2100.arm.linux.org.uk>
Hi!
> > > If the above assembly file can only run on ARMv7, consider putting
> > >
> > > .march armv7
> > >
> > > or similar before it.
> >
> > My version of gas does not seem to recognize .march
>
> Ah, that's because it's .arch not .march. Please could you check with
> .arch instead. If proven successful we should move the existing
> AFLAGS_xxx.o Makefile stuff into the assembly files concerned.
.arch armv7
results in
arch/arm/mach-socfpga/headsmp.S:21: Error: attempt to use an ARM
instruction on a Thumb-only processor -- `movw
r0,#:lower16:(0xffd08000+0x10)'
...
Using .arch armv7-a indeed works and is a very nice solution.
Signed-off-by: Pavel Machek <pavel@denx.de>
--- a/arch/arm/mach-socfpga/headsmp.S
+++ b/arch/arm/mach-socfpga/headsmp.S
@@ -11,6 +11,7 @@
#include <linux/init.h>
__INIT
+ .arch armv7-a
#define HPS_SYSMGR_ADDRESS 0xffd08000
#define CONFIG_SYSTEM_MANAGER HPS_SYSMGR_ADDRESS
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH] arm: socfpga: fix build break for allyesconfig
From: Russell King - ARM Linux @ 2012-10-26 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026223654.GB2597@elf.ucw.cz>
On Sat, Oct 27, 2012 at 12:36:54AM +0200, Pavel Machek wrote:
> Hi!
>
> > > index 17d6eaf..9031a3c 100644
> > > --- a/arch/arm/mach-socfpga/headsmp.S
> > > +++ b/arch/arm/mach-socfpga/headsmp.S
> > > @@ -15,8 +15,10 @@
> > > #define CPU1_START_ADDR 0xffd08010
> > >
> > > ENTRY(secondary_trampoline)
> > > +#if __LINUX_ARM_ARCH__ >= 7
> > > movw r0, #:lower16:CPU1_START_ADDR
> > > movt r0, #:upper16:CPU1_START_ADDR
> > > +#endif
> >
> > If you do that, then it effectively means you don't need these instructions
> > and you might as well just delete them... but looking at the following one:
> >
> > > ldr r1, [r0]
> >
> > it's clear that you do need it. So you need to find a different solution.
> > If the above assembly file can only run on ARMv7, consider putting
> >
> > .march armv7
> >
> > or similar before it.
>
> My version of gas does not seem to recognize .march
Ah, that's because it's .arch not .march. Please could you check with
.arch instead. If proven successful we should move the existing
AFLAGS_xxx.o Makefile stuff into the assembly files concerned.
^ 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