* [GIT PULL] Convert arch-vt8500 to multiplatform
From: Arnd Bergmann @ 2012-10-26 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351223497.30694.2.camel@gitbox>
On Friday 26 October 2012, Tony Prisk wrote:
> Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
>
> are available in the git repository at:
>
> git://server.prisktech.co.nz/git/linuxwmt.git/ tags/armsoc-for-3.8
>
> for you to fetch changes up to 6f35f9a9fabe8f0a89a17e353a77a7edef461bb2:
>
> ARM: vt8500: Convert arch-vt8500 to multiplatform (2012-10-26 16:45:19
> +1300)
>
> ----------------------------------------------------------------
> Two patches for 3.8 to finish converting arch-vt8500 to multiplatform.
> Single arch build is maintained as we still need earlyprintk for
> development work.
>
Merged into next/multiplatform
Thanks!
Arnd
^ permalink raw reply
* [PATCH V2 0/4] Adding SATA support for Armada 370/XP
From: Andrew Lunn @ 2012-10-26 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254650-26861-1-git-send-email-gregory.clement@free-electrons.com>
On Fri, Oct 26, 2012 at 02:30:45PM +0200, Gregory CLEMENT wrote:
> Hello,
>
> this patch set adds the SATA support for Armada 370 and Armada XP. Few
> changes have been done since the first version by taking in account
> the comments received for the first version.
>
> The evaluation boards for Armada 370 and Armada XP come with 2 SATA
> ports, and when both are enable the coherent pool for DMA mapping was
> too short. It was exactly the same issue that was fixed for Kirkwood
> two months ago. So I used the same fix in the first patch. Later when
> Kirkwood will be part of mach-mvebu, then this fix will be shared
> between the 2 SoCs families.
>
> This patch set is based on 3.7-rc2 and depends one the framework clock
> support (the last version was posted last week:
> http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
> called mvebu-SATA-for-3.8 is also available at
> https://github.com/MISL-EBU-System-SW/mainline-public.git.
Hi Gregory
What about the openblocks-ax3?
Andrew
^ permalink raw reply
* [PATCH RESEND] cpufreq: Make sure target freq is within limits
From: Viresh Kumar @ 2012-10-26 12:35 UTC (permalink / raw)
To: linux-arm-kernel
__cpufreq_driver_target() must not pass target frequency beyond the limits of
current policy.
Today most of cpufreq platform drivers are doing this check in their target
routines. Why not move it to __cpufreq_driver_target().
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
Hi Rafael,
Resend doesn't contain any change, but fixed commit log
drivers/cpufreq/cpufreq.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 28dc134..2f5ac2d 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
unsigned int relation)
{
int retval = -EINVAL;
+ unsigned int old_target_freq = target_freq;
if (cpufreq_disabled())
return -ENODEV;
- pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
- target_freq, relation);
+ /* Make sure that target_freq is within supported range */
+ if (target_freq > policy->max)
+ target_freq = policy->max;
+ if (target_freq < policy->min)
+ target_freq = policy->min;
+
+ pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
+ policy->cpu, target_freq, relation, old_target_freq);
if (target_freq == policy->cur)
return 0;
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH 1/2] spi: mxs: Assign message status after transfer finished
From: Marek Vasut @ 2012-10-26 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017071026.GB14199@opensource.wolfsonmicro.com>
Dear Mark Brown,
> On Sun, Oct 14, 2012 at 04:32:55AM +0200, Marek Vasut wrote:
> > In the current code implementing the MXS SPI driver, every transferred
> > message had assigned status = 0, which is not correct. Properly assign
> > status returned from the I/O functions.
>
> Applied both, thanks.
Will they hit 3.7 please?
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH V2 4/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP boards
From: Gregory CLEMENT @ 2012-10-26 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254650-26861-1-git-send-email-gregory.clement@free-electrons.com>
Add the SATA device tree bindings for
- Armada XP evaluation board (DB-78460-BP)
- Armada 370 evaluation board (DB-88F6710-BP-DDR3)
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/boot/dts/armada-370-db.dts | 4 ++++
arch/arm/boot/dts/armada-xp-db.dts | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index 4a31b03..060e5ba 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,5 +34,9 @@
clock-frequency = <200000000>;
status = "okay";
};
+ sata at d00a0000 {
+ nr-ports = <2>;
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/armada-xp-db.dts b/arch/arm/boot/dts/armada-xp-db.dts
index b1fc728..375436b 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -46,5 +46,9 @@
clock-frequency = <250000000>;
status = "okay";
};
+ sata at d00a0000 {
+ nr-ports = <2>;
+ status = "okay";
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 3/4] arm: mvebu: adding SATA support: configs update
From: Gregory CLEMENT @ 2012-10-26 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254650-26861-1-git-send-email-gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
arch/arm/configs/mvebu_defconfig | 3 +++
2 files changed, 5 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 159f75f..dbea6f4 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -17,8 +17,10 @@ CONFIG_ARM_APPENDED_DTB=y
CONFIG_VFP=y
CONFIG_NEON=y
CONFIG_NET=y
+CONFIG_BLK_DEV_SD=y
CONFIG_ATA=y
CONFIG_SATA_HIGHBANK=y
+CONFIG_SATA_MV=y
CONFIG_NETDEVICES=y
CONFIG_NET_CALXEDA_XGMAC=y
CONFIG_SMSC911X=y
diff --git a/arch/arm/configs/mvebu_defconfig b/arch/arm/configs/mvebu_defconfig
index 7bcf850..76a60b5 100644
--- a/arch/arm/configs/mvebu_defconfig
+++ b/arch/arm/configs/mvebu_defconfig
@@ -18,6 +18,9 @@ CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_ARM_APPENDED_DTB=y
CONFIG_VFP=y
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_BLK_DEV_SD=y
+CONFIG_ATA=y
+CONFIG_SATA_MV=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_OF_PLATFORM=y
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 2/4] arm: mvebu: adding SATA support: dt binding for Armada 370/XP
From: Gregory CLEMENT @ 2012-10-26 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254650-26861-1-git-send-email-gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Lior Amsalem <alior@marvell.com>
---
arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 94b4b9e..a911f7a 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -69,6 +69,15 @@
compatible = "marvell,armada-addr-decoding-controller";
reg = <0xd0020000 0x258>;
};
+
+ sata at d00a0000 {
+ compatible = "marvell,orion-sata";
+ reg = <0xd00a0000 0x2400>;
+ interrupts = <55>;
+ clocks = <&coreclk 0>;
+ status = "disabled";
+ };
+
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 1/4] arm: mvebu: increase atomic coherent pool size for armada 370/XP
From: Gregory CLEMENT @ 2012-10-26 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351254650-26861-1-git-send-email-gregory.clement@free-electrons.com>
For Armada 370/XP we have the same problem that for the commit
cb01b63, so we applied the same solution: "The default 256 KiB
coherent pool may be too small for some of the Kirkwood devices, so
increase it to make sure that devices will be able to allocate their
buffers with GFP_ATOMIC flag"
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
arch/arm/mach-mvebu/armada-370-xp.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 2af6ce5..cbad821 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -17,6 +17,7 @@
#include <linux/of_platform.h>
#include <linux/io.h>
#include <linux/time-armada-370-xp.h>
+#include <linux/dma-mapping.h>
#include <asm/mach/arch.h>
#include <asm/mach/map.h>
#include <asm/mach/time.h>
@@ -43,6 +44,16 @@ void __init armada_370_xp_timer_and_clk_init(void)
armada_370_xp_timer_init();
}
+void __init armada_370_xp_init_early(void)
+{
+ /*
+ * Some Armada 370/XP devices allocate their coherent buffers
+ * from atomic context. Increase size of atomic coherent pool
+ * to make sure such the allocations won't fail.
+ */
+ init_dma_coherent_pool_size(SZ_1M);
+}
+
struct sys_timer armada_370_xp_timer = {
.init = armada_370_xp_timer_and_clk_init,
};
@@ -61,6 +72,7 @@ static const char * const armada_370_xp_dt_board_dt_compat[] = {
DT_MACHINE_START(ARMADA_XP_DT, "Marvell Aramada 370/XP (Device Tree)")
.init_machine = armada_370_xp_dt_init,
.map_io = armada_370_xp_map_io,
+ .init_early = armada_370_xp_init_early,
.init_irq = armada_370_xp_init_irq,
.handle_irq = armada_370_xp_handle_irq,
.timer = &armada_370_xp_timer,
--
1.7.9.5
^ permalink raw reply related
* [PATCH V2 0/4] Adding SATA support for Armada 370/XP
From: Gregory CLEMENT @ 2012-10-26 12:30 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
this patch set adds the SATA support for Armada 370 and Armada XP. Few
changes have been done since the first version by taking in account
the comments received for the first version.
The evaluation boards for Armada 370 and Armada XP come with 2 SATA
ports, and when both are enable the coherent pool for DMA mapping was
too short. It was exactly the same issue that was fixed for Kirkwood
two months ago. So I used the same fix in the first patch. Later when
Kirkwood will be part of mach-mvebu, then this fix will be shared
between the 2 SoCs families.
This patch set is based on 3.7-rc2 and depends one the framework clock
support (the last version was posted last week:
http://thread.gmane.org/gmane.linux.kernel/1375701). The git branch
called mvebu-SATA-for-3.8 is also available at
https://github.com/MISL-EBU-System-SW/mainline-public.git.
Changelog:
V1 -> V2:
- Added the acked-by from Marek Szyprowski for the first patch.
- Moved the port number from dtsi to board file t o be coherent with
Kirwkood boards.
- Cleaned armada-370-xp.dtsi from test strings.
- Split the second patch in 3 part one for dts, one for config update,
and the last for dtsi.
- Updated the mvebu_defconfig file with only the necessary symbols.
- Updated also the multi_v7_defconfig file.
Regards,
Gregory
Gregory CLEMENT (4):
arm: mvebu: increase atomic coherent pool size for armada 370/XP
arm: mvebu: adding SATA support: dt binding for Armada 370/XP
arm: mvebu: adding SATA support: configs update
arm: mvebu: adding SATA support: dt binding for Armada 370/XP boards
arch/arm/boot/dts/armada-370-db.dts | 4 ++++
arch/arm/boot/dts/armada-370-xp.dtsi | 9 +++++++++
arch/arm/boot/dts/armada-xp-db.dts | 4 ++++
arch/arm/configs/multi_v7_defconfig | 2 ++
arch/arm/configs/mvebu_defconfig | 3 +++
arch/arm/mach-mvebu/armada-370-xp.c | 12 ++++++++++++
6 files changed, 34 insertions(+)
--
1.7.9.5
^ permalink raw reply
* [PATCH 3/9] ARM: Kirkwood: Convert dnskw to pinctrl
From: Jamie Lentin @ 2012-10-26 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026102450.GG21046@lunn.ch>
On Fri, 26 Oct 2012, Andrew Lunn wrote:
>> I did look at using the gpio-regulator stuff a while back, and
>> decided it wasn't quite the right shape. Although I can't remember
>> why, and it might have changed since.
>
> O.K. I will look at it this weekend.
>
>> The power-off GPIO registration could happen in dnskw_power_off
>> instead, or the attempt at a gpio-poweroff driver could be
>> resurrected (I'd forgotten about it until now).
>
> I dusted the code off last weekend, but ran out of time. I wanted to
> make it also support the pxa use-case.
Okay, I'm unlikely to get a chance to have a play with it for a week or so
but if I do I'll let you know.
>> I could accept dnskw:power:recover is a weirdo configuration option
>> that should be set in the bootloader / userland rather than the
>> kernel supporting it. Although it would be nice if the kernel
>> registered it's purpose. Maybe GPIO pins could be exported by adding
>> sub-nodes to the GPIO chip, if that's not too hackish?
>
> We need some sort of solution. It is quite common to use GPIO this
> way, to enable power, etc. So either we need some form of gpio
> regulator, or the ability to set gpio defaults as you said in the gpio
> DT node, or fix the ordering so the init function can set them up.
Setting the defaults in the DT gpio node would get my vote, as it pretty
much removes board-dnskw.c, and there'd be easy sysfs files to turn the
pins on/off (maybe someone out there doesn't want their NAS to turn back
on after a power failure...).
>>> First thing that comes to mind, is it registering them for the correct
>>> GPIO controller. I think with the new setup, pinctrl and gpio are
>>> closely linked, so maybe, its modifying pins on the wrong controller.
>>> Bit of a long shot....
>>>
>>
>> I did wonder that, but then why would turning the LEDs on work fine?
>> I wonder if both pins are being toggled or something. I'll
>> investigate further and report back. The two that cause the NAS to
>> lock up are the only ones on &gpio1 though.
>
> What would they map to on gpio0? NAND?
>
3 & 11, so NAND and UART0 RX. But it's not just that the console is dead,
I can't ping the NAS any more either. However the power LED is still
blinking via. hardware GPIO blink.
>> The sata0 and sata1 activity leds are definitely MPP20 and
>> MPP21---I've set them up as GPIO leds before successfully.
>
> O.K.
>
>>> [ 16.187814] initial MPP regs: 01112222 43303311 55550000 00000000 00000000 00000000 00000000
>>> [ 16.187833] final MPP regs: 01552222 03303311 55550000 00000000 00000000 00000000 00000000
>>>
>>> The first line is how uboot setup the MPP pins. The second is after
>>> the init function was called.
>>
>> initial MPP regs: 01111111 03303311 00551100 00000000 00000000 00000000 00000000
>> final MPP regs: 01111111 03303311 00551100 00000000 00000000 00000000 00000000
>>
>> Although the initial MPP regs is also set by a recompiled u-boot
>> with ~identical MPP setup code.
>
> It might be useful to generate the same sort of dumps with the new
> driver, even if its code just hacked in for testing.
I'd been looking at the debugfs output if you hadn't spotted it:
root at rocoto:~# cat /debug/pinctrl/f1010000.pinctrl/pinmux-pins
Pinmux settings per pin
Format: pin (name): mux_owner gpio_owner hog?
pin 0 (PIN0): f1010000.pinctrl (GPIO UNCLAIMED) (HOG) function nand group mpp0
pin 1 (PIN1): f1010000.pinctrl (GPIO UNCLAIMED) (HOG) function nand group mpp1
pin 2 (PIN2): f1010000.pinctrl (GPIO UNCLAIMED) (HOG) function nand group mpp2
. . .
Although it doesn't say what the initial MPP setup was.
>
> Andrew
>
--
Jamie Lentin
^ permalink raw reply
* [RFC PATCH 00/13] sched: Integrating Per-entity-load-tracking with the core scheduler
From: Peter Zijlstra @ 2012-10-26 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50898118.1050402@linux.vnet.ibm.com>
On Thu, 2012-10-25 at 23:42 +0530, Preeti U Murthy wrote:
> > Do explain..
> >
> Let me see if I get what you are saying here right.You want to replace
> for example cfs_rq->load.weight with a saner metric because it does not
> consider the run time of the sched entities queued on it,merely their
> priorities.If this is right,in this patchset I believe
> cfs_rq->runnable_load_avg would be that right metric because it
> considers the run time of the sched entities queued on it.
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?
> 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.
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.
> > At best they mention what you're doing, not why and how.
> So the above explains *what* I am doing.
>
> *How* am i doing it: Everywhere the scheduler needs to make a decision on:
>
> 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.
> 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.
> > 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.
> 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.
> 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.
^ permalink raw reply
* [PATCH] davinci: check for presence of channel controller on slot alloc
From: Matt Porter @ 2012-10-26 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A7665.4030109@ti.com>
On Fri, Oct 26, 2012 at 05:09:17PM +0530, Sekhar Nori wrote:
> + Matt, who is doing the DMA engine conversion for EDMA
>
> On 9/12/2012 11:44 PM, Cyril Chemparathy wrote:
> > This patch adds a check for the presence of the channel controller when
> > trying to allocate a slot. Without this fix, the kernel panics with a NULL
> > pointer dereference when the dma-engine drivers are probed.
> >
> > Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> > ---
> > arch/arm/mach-davinci/dma.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
> > index a685e97..2fee31e 100644
> > --- a/arch/arm/mach-davinci/dma.c
> > +++ b/arch/arm/mach-davinci/dma.c
> > @@ -743,6 +743,9 @@ EXPORT_SYMBOL(edma_free_channel);
> > */
> > int edma_alloc_slot(unsigned ctlr, int slot)
> > {
> > + if (!edma_cc[ctlr])
> > + return -ENODEV;
>
> I am ok with this patch, although I wonder if a better error is -ENXIO
> or even -EINVAL (since its most likely the result of a wrong argument).
>
> This patch will conflict with the EDMA movement series that Matt is
> doing and he should probably include it in his series to avoid
> conflicts. From the description it appears to be not required for v3.7
> anyway.
I'll add this to the am33xx dmaengine series with -EINVAL, thanks.
-Matt
^ permalink raw reply
* [PATCH] davinci: check for presence of channel controller on slot alloc
From: Sekhar Nori @ 2012-10-26 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347473642-9948-1-git-send-email-cyril@ti.com>
+ Matt, who is doing the DMA engine conversion for EDMA
On 9/12/2012 11:44 PM, Cyril Chemparathy wrote:
> This patch adds a check for the presence of the channel controller when
> trying to allocate a slot. Without this fix, the kernel panics with a NULL
> pointer dereference when the dma-engine drivers are probed.
>
> Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> ---
> arch/arm/mach-davinci/dma.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
> index a685e97..2fee31e 100644
> --- a/arch/arm/mach-davinci/dma.c
> +++ b/arch/arm/mach-davinci/dma.c
> @@ -743,6 +743,9 @@ EXPORT_SYMBOL(edma_free_channel);
> */
> int edma_alloc_slot(unsigned ctlr, int slot)
> {
> + if (!edma_cc[ctlr])
> + return -ENODEV;
I am ok with this patch, although I wonder if a better error is -ENXIO
or even -EINVAL (since its most likely the result of a wrong argument).
This patch will conflict with the EDMA movement series that Matt is
doing and he should probably include it in his series to avoid
conflicts. From the description it appears to be not required for v3.7
anyway.
Thanks,
Sekhar
^ permalink raw reply
* [RFC] cpufreq: Make sure target freq is within limits
From: Rafael J. Wysocki @ 2012-10-26 11:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f0099171c1c4f3048d0f29b7deb42144f26ac5d5.1351146515.git.viresh.kumar@linaro.org>
On Thursday, October 25, 2012 12:03:34 PM Viresh Kumar wrote:
> Hi Rafael,
>
> __cpufreq_driver_target() must not pass target frequency beyond the limits of
> current policy.
>
> Today most of cpufreq platform drivers are doing this check in their target
> routines. Why not move it to __cpufreq_driver_target().
>
> I wanted to get your opinion on this before making changes in all driver files.
> That's why this is an RFC.
I'd prefer to apply the patch below before changing the drviers.
Thanks,
Rafael
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/cpufreq/cpufreq.c | 11 +++++++++--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index f552d5f..59264f1 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1470,12 +1470,19 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
> unsigned int relation)
> {
> int retval = -EINVAL;
> + unsigned int old_target_freq = target_freq;
>
> if (cpufreq_disabled())
> return -ENODEV;
>
> - pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
> - target_freq, relation);
> + /* Make sure that target_freq is within supported range */
> + if (target_freq > policy->max)
> + target_freq = policy->max;
> + if (target_freq < policy->min)
> + target_freq = policy->min;
> +
> + pr_debug("target for CPU %u: %u kHz, relation %u, requested %u kHz\n",
> + policy->cpu, target_freq, relation, old_target_freq);
> if (cpu_online(policy->cpu) && cpufreq_driver->target)
> retval = cpufreq_driver->target(policy, target_freq, relation);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH 8/8] cpufreq: db8500: Use armss clk to update frequency
From: Rafael J. Wysocki @ 2012-10-26 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFp8OVn1kXzQB_PVxb4PBYCdvE7QGzCiqN+Zmm9LsX3HDg@mail.gmail.com>
On Friday, October 26, 2012 10:10:40 AM Ulf Hansson wrote:
> On 10 October 2012 13:42, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> >
> > Using the armss clk to update the frequency makes the driver no more
> > directly dependant on the prmcu API.
> >
> > Cc: Rafael J. Wysocki <rjw@sisk.pl>
> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> > ---
> > drivers/cpufreq/db8500-cpufreq.c | 24 ++++++++++++++++--------
> > 1 file changed, 16 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/cpufreq/db8500-cpufreq.c b/drivers/cpufreq/db8500-cpufreq.c
> > index dea9a49..4f154bc 100644
> > --- a/drivers/cpufreq/db8500-cpufreq.c
> > +++ b/drivers/cpufreq/db8500-cpufreq.c
> > @@ -14,10 +14,11 @@
> > #include <linux/delay.h>
> > #include <linux/slab.h>
> > #include <linux/platform_device.h>
> > -#include <linux/mfd/dbx500-prcmu.h>
> > +#include <linux/clk.h>
> > #include <mach/id.h>
> >
> > static struct cpufreq_frequency_table *freq_table;
> > +static struct clk *armss_clk;
> >
> > static struct freq_attr *db8500_cpufreq_attr[] = {
> > &cpufreq_freq_attr_scaling_available_freqs,
> > @@ -58,9 +59,9 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
> > for_each_cpu(freqs.cpu, policy->cpus)
> > cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
> >
> > - /* request the PRCM unit for opp change */
> > - if (prcmu_set_arm_opp(freq_table[idx].index)) {
> > - pr_err("db8500-cpufreq: Failed to set OPP level\n");
> > + /* update armss clk frequency */
> > + if (clk_set_rate(armss_clk, freq_table[idx].frequency * 1000)) {
> > + pr_err("db8500-cpufreq: Failed to update armss clk\n");
> > return -EINVAL;
> > }
> >
> > @@ -74,16 +75,16 @@ static int db8500_cpufreq_target(struct cpufreq_policy *policy,
> > static unsigned int db8500_cpufreq_getspeed(unsigned int cpu)
> > {
> > int i = 0;
> > - /* request the prcm to get the current ARM opp */
> > - int opp = prcmu_get_arm_opp();
> > + unsigned long freq = clk_get_rate(armss_clk) / 1000;
> >
> > while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
> > - if (opp == freq_table[i].index)
> > + if (freq <= freq_table[i].frequency)
> > return freq_table[i].frequency;
> > i++;
> > }
> >
> > - /* We could not find a corresponding opp frequency. */
> > + /* We could not find a corresponding frequency. */
> > + pr_err("db8500-cpufreq: Failed to find cpufreq speed\n");
> > return 0;
> > }
> >
> > @@ -92,6 +93,12 @@ static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
> > int i = 0;
> > int res;
> >
> > + armss_clk = clk_get(NULL, "armss");
> > + if (IS_ERR(armss_clk)) {
> > + pr_err("db8500-cpufreq : Failed to get armss clk\n");
> > + return PTR_ERR(armss_clk);
> > + }
> > +
> > pr_info("db8500-cpufreq : Available frequencies:\n");
> > while (freq_table[i].frequency != CPUFREQ_TABLE_END) {
> > pr_info(" %d Mhz\n", freq_table[i].frequency/1000);
> > @@ -104,6 +111,7 @@ static int __cpuinit db8500_cpufreq_init(struct cpufreq_policy *policy)
> > cpufreq_frequency_table_get_attr(freq_table, policy->cpu);
> > else {
> > pr_err("db8500-cpufreq : Failed to read policy table\n");
> > + clk_put(armss_clk);
> > return res;
> > }
> >
> > --
> > 1.7.10
> >
>
> Just a kind reminder on this Rafael; trying to collect acks, do you
> think we can advise Mike to merge this though his clk tree?
Yes, please.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [PATCH] cpufreq: Avoid calling cpufreq driver's target() routine if target_freq == policy->cur
From: Rafael J. Wysocki @ 2012-10-26 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1d7b6e421a335255da956804b43ce3517538409c.1351244153.git.viresh.kumar@linaro.org>
On Friday, October 26, 2012 03:06:26 PM Viresh Kumar wrote:
> Avoid calling cpufreq driver's target() routine if new frequency is same as
> policies current frequency.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Looks reasonable.
Any objection from anyone?
Rafael
> ---
> drivers/cpufreq/cpufreq.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 261ef65..28dc134 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1476,6 +1476,10 @@ int __cpufreq_driver_target(struct cpufreq_policy *policy,
>
> pr_debug("target for CPU %u: %u kHz, relation %u\n", policy->cpu,
> target_freq, relation);
> +
> + if (target_freq == policy->cur)
> + return 0;
> +
> if (cpu_online(policy->cpu) && cpufreq_driver->target)
> retval = cpufreq_driver->target(policy, target_freq, relation);
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* [BUG] read_current_timer undefined
From: Will Deacon @ 2012-10-26 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.64.1210261306370.20835@axis700.grange>
On Fri, Oct 26, 2012 at 12:09:18PM +0100, Guennadi Liakhovetski wrote:
> A recent commit
>
> commit 923df96b9f31b7d08d8438ff9677326d9537accf
> Author: Will Deacon <will.deacon@arm.com>
> Date: Fri Jul 6 15:46:45 2012 +0100
>
> ARM: 7451/1: arch timer: implement read_current_timer and get_cycles
>
> breaks linkage of modules, using get_cycles(), e.g.
>
> ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
>
> This is present in "next" of 23 October.
It's been present for a lot longer than that, but a fix has been merged into
mainline, so next should be ok now. See mainline commit f3accb122f2 ("ARM:
export default read_current_timer").
Will
^ permalink raw reply
* [RFC/PATCH] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete
From: Venkatraman S @ 2012-10-26 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025180418.GB18046@arwen.pp.htv.fi>
On Thursday 25 October 2012 11:34 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 22, 2012 at 04:27:08PM +0300, Felipe Balbi wrote:
>> On Mon, Oct 22, 2012 at 03:59:28PM +0300, Felipe Balbi wrote:
>>> prepare() is supposed to prevent new children from
>>> being registered. On the MMC subsystem, children
>>> (new cards) registration starts with the card
>>> detect IRQ.
>>>
>>> Move card detect IRQ disabling to prepare() so that
>>> no new cards will be registered while we're trying
>>> to suspend.
>>>
>>> Likewise, move card detect IRQ enabling to complete()
>>> so we only try to register new children after our MMC
>>> IP is back up.
>>>
>>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>>> ---
>>>
>>> Venkat, do you think the patch below makes sense ?
>> btw, just checked suspend to ram with beagle and panda. We still have
>> our filesystem after waking up.
>>
>> ps: you will [1] to test it:
>>
>> [1] http://marc.info/?l=linux-arm-kernel&m=135090724817604&w=2
> ping
>
I've been off for the past 3 days. Will test this on Monday once I'm
back in office.
^ permalink raw reply
* [BUG] read_current_timer undefined
From: Guennadi Liakhovetski @ 2012-10-26 11:09 UTC (permalink / raw)
To: linux-arm-kernel
A recent commit
commit 923df96b9f31b7d08d8438ff9677326d9537accf
Author: Will Deacon <will.deacon@arm.com>
Date: Fri Jul 6 15:46:45 2012 +0100
ARM: 7451/1: arch timer: implement read_current_timer and get_cycles
breaks linkage of modules, using get_cycles(), e.g.
ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined!
This is present in "next" of 23 October.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH 2/2] ARM: mach-imx: CAN clock fix for i.MX53
From: Roland Stigge @ 2012-10-26 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A665C.80107@pengutronix.de>
On 10/26/2012 12:30 PM, Marc Kleine-Budde wrote:
>>>> + clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate",
>>>> "can_sel", MXC_CCM_CCGR4, 6); + clk[can1_ipg_gate] =
>>>> imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR4, 8); +
>>>> clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate",
>>>> "can_sel", MXC_CCM_CCGR4, 6); + clk[can2_ipg_gate] =
>>>> imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
>>>
>>> This doesn't.
>>
>> This may be right, but unfortunately, since the introduction of
>> your can1 + can2 clocking change, the first block stopped working
>> for me.
>
> You are effectively using can2's clock for can1. Are you sure you
> haven't mixed up can1 and can2?
Just using the above patch and patch 1/2 from this series (missing can
pinmuxing), doing like this in custom .dts:
+ can1: can at 53fc8000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1_1>;
+ clock-frequency = <66500000>;
+ status = "okay";
+ };
Then, the can0 interface appears which can be upped as network interface.
Quite straightforward, isn't it?
Roland
^ permalink raw reply
* [PATCH] ARM: dma-mapping: support debug_dma_mapping_error
From: Russell King - ARM Linux @ 2012-10-26 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350909843-5273-1-git-send-email-ming.lei@canonical.com>
On Mon, Oct 22, 2012 at 08:44:03PM +0800, Ming Lei wrote:
> Without the patch, kind of below warning will be dumped if DMA-API
> debug is enabled:
>
> [ 11.069763] ------------[ cut here ]------------
> [ 11.074645] WARNING: at lib/dma-debug.c:948 check_unmap+0x770/0x860()
> [ 11.081420] ehci-omap ehci-omap.0: DMA-API: device driver failed to
> check map error[device address=0x0000000
> 0adb78e80] [size=8 bytes] [mapped as single]
> [ 11.095611] Modules linked in:
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Ming Lei <ming.lei@canonical.com>
Would you mind explaining why you think it's fine to send a patch for the
mainline kernel adding a function call to a header file which is not even
in the mainline kernel?
My guess is that the Canonical kernel has some additional checking here
which mainline kernels don't have, which means your patch should never have
been submitted (or even applied.)
On Marek's side, why didn't you try to build your tree at least once in
the last 3 days before pushing this patch to Linus?
^ permalink raw reply
* [PATCH 2/2] ARM: tegra: common: using OF api for L2 cache init
From: Joseph Lo @ 2012-10-26 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351247649-15859-1-git-send-email-josephl@nvidia.com>
Moving L2 cache init to DT support.
Signed-off-by: Joseph Lo <josephl@nvidia.com>
---
arch/arm/mach-tegra/common.c | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 0e31f8c..a8f9175 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -114,20 +114,17 @@ static __initdata struct tegra_clk_init_table tegra30_clk_init_table[] = {
#endif
-static void __init tegra_init_cache(u32 tag_latency, u32 data_latency)
+static void __init tegra_init_cache(void)
{
#ifdef CONFIG_CACHE_L2X0
void __iomem *p = IO_ADDRESS(TEGRA_ARM_PERIF_BASE) + 0x3000;
u32 aux_ctrl, cache_type;
- writel_relaxed(tag_latency, p + L2X0_TAG_LATENCY_CTRL);
- writel_relaxed(data_latency, p + L2X0_DATA_LATENCY_CTRL);
-
cache_type = readl(p + L2X0_CACHE_TYPE);
aux_ctrl = (cache_type & 0x700) << (17-8);
aux_ctrl |= 0x6C000001;
- l2x0_init(p, aux_ctrl, 0x8200c3fe);
+ l2x0_of_init(aux_ctrl, 0x8200c3fe);
#endif
}
@@ -139,7 +136,7 @@ void __init tegra20_init_early(void)
tegra_init_fuse();
tegra2_init_clocks();
tegra_clk_init_from_table(tegra20_clk_init_table);
- tegra_init_cache(0x331, 0x441);
+ tegra_init_cache();
tegra_pmc_init();
tegra_powergate_init();
tegra20_hotplug_init();
@@ -152,7 +149,7 @@ void __init tegra30_init_early(void)
tegra_init_fuse();
tegra30_init_clocks();
tegra_clk_init_from_table(tegra30_clk_init_table);
- tegra_init_cache(0x441, 0x551);
+ tegra_init_cache();
tegra_pmc_init();
tegra_powergate_init();
tegra30_hotplug_init();
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] ARM: tegra: dt: add L2 cache controller
From: Joseph Lo @ 2012-10-26 10:34 UTC (permalink / raw)
To: linux-arm-kernel
Add L2 cache controller binding into DT for Tegra.
Signed-off-by: Joseph Lo <josephl@nvidia.com>
---
arch/arm/boot/dts/tegra20.dtsi | 9 +++++++++
arch/arm/boot/dts/tegra30.dtsi | 9 +++++++++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 6934bca..be18361 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -4,6 +4,15 @@
compatible = "nvidia,tegra20";
interrupt-parent = <&intc>;
+ L2: cache-controller at 50043000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x50043000 0x1000>;
+ arm,data-latency = <5 5 2>;
+ arm,tag-latency = <4 4 2>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
timer at 50004600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x50040600 0x20>;
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 81f5df4..71da933 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -4,6 +4,15 @@
compatible = "nvidia,tegra30";
interrupt-parent = <&intc>;
+ L2: cache-controller at 50043000 {
+ compatible = "arm,pl310-cache";
+ reg = <0x50043000 0x1000>;
+ arm,data-latency = <6 6 2>;
+ arm,tag-latency = <5 5 2>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
timer at 50004600 {
compatible = "arm,cortex-a9-twd-timer";
reg = <0x50040600 0x20>;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/2] ARM: mach-imx: CAN clock fix for i.MX53
From: Marc Kleine-Budde @ 2012-10-26 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A54E4.2060108@antcom.de>
On 10/26/2012 11:16 AM, Roland Stigge wrote:
> Hi!
>
> On 10/26/2012 10:59 AM, Sascha Hauer wrote:
>> On Thu, Oct 25, 2012 at 01:26:40PM +0200, Roland Stigge wrote:
>>> This patch fixes CAN clocking on i.MX53.
>>>
>>> Signed-off-by: Roland Stigge <stigge@antcom.de>
>>>
>>> ---
>>> arch/arm/mach-imx/clk-imx51-imx53.c | 8 ++++----
>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>> --- linux-2.6.orig/arch/arm/mach-imx/clk-imx51-imx53.c
>>> +++ linux-2.6/arch/arm/mach-imx/clk-imx51-imx53.c
>>> @@ -426,10 +426,10 @@ int __init mx53_clocks_init(unsigned lon
>>> clk[usb_phy2_gate] = imx_clk_gate2("usb_phy2_gate", "usb_phy_sel", MXC_CCM_CCGR4, 12);
>>> clk[can_sel] = imx_clk_mux("can_sel", MXC_CCM_CSCMR2, 6, 2,
>>> mx53_can_sel, ARRAY_SIZE(mx53_can_sel));
>>> - clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate", "can_sel", MXC_CCM_CCGR6, 22);
>>> - clk[can1_ipg_gate] = imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR6, 20);
>>> - clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate", "can_sel", MXC_CCM_CCGR4, 8);
>>> - clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 6);
>>
>> I just rechecked. The above matches the i.MX53 Reference Manual rev 2.1
An old rev 1 manual has lists the same bits.
>>> + clk[can1_serial_gate] = imx_clk_gate2("can1_serial_gate", "can_sel", MXC_CCM_CCGR4, 6);
>>> + clk[can1_ipg_gate] = imx_clk_gate2("can1_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
>>> + clk[can2_serial_gate] = imx_clk_gate2("can2_serial_gate", "can_sel", MXC_CCM_CCGR4, 6);
>>> + clk[can2_ipg_gate] = imx_clk_gate2("can2_ipg_gate", "ipg", MXC_CCM_CCGR4, 8);
>>
>> This doesn't.
>
> This may be right, but unfortunately, since the introduction of your
> can1 + can2 clocking change, the first block stopped working for me.
You are effectively using can2's clock for can1. Are you sure you
haven't mixed up can1 and can2?
> My above patch is basically a rollback which works for the first block.
>
> An interesting hint is: can2 (which was the only one defined _before_
> your can1 + can2 change) didn't work before and afterwards at all. (But
> I'm not using it anyway.)
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121026/f9790b6b/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 8/8] ARM: hw_breakpoint: kill WARN_ONCE usage
From: Will Deacon @ 2012-10-26 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351247415-25090-1-git-send-email-will.deacon@arm.com>
WARN_ONCE is a bit OTT for some of the simple failure cases encountered
in hw_breakpoint, so use either pr_warning or pr_warn_once instead.
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/hw_breakpoint.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 05febba..5ff2e77 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -261,10 +261,11 @@ static int enable_monitor_mode(void)
/* Check that the write made it through. */
ARM_DBG_READ(c0, c1, 0, dscr);
- if (WARN_ONCE(!(dscr & ARM_DSCR_MDBGEN),
- "Failed to enable monitor mode on CPU %d.\n",
- smp_processor_id()))
+ if (!(dscr & ARM_DSCR_MDBGEN)) {
+ pr_warn_once("Failed to enable monitor mode on CPU %d.\n",
+ smp_processor_id());
return -EPERM;
+ }
out:
return 0;
@@ -357,8 +358,10 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
}
}
- if (WARN_ONCE(i == max_slots, "Can't find any breakpoint slot\n"))
+ if (i == max_slots) {
+ pr_warning("Can't find any breakpoint slot\n");
return -EBUSY;
+ }
/* Override the breakpoint data with the step data. */
if (info->step_ctrl.enabled) {
@@ -407,8 +410,10 @@ void arch_uninstall_hw_breakpoint(struct perf_event *bp)
}
}
- if (WARN_ONCE(i == max_slots, "Can't find any breakpoint slot\n"))
+ if (i == max_slots) {
+ pr_warning("Can't find any breakpoint slot\n");
return;
+ }
/* Ensure that we disable the mismatch breakpoint. */
if (info->ctrl.type != ARM_BREAKPOINT_EXECUTE &&
--
1.7.4.1
^ permalink raw reply related
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