Re: Calling irq_set_irq_wake() from .set_irq_wake()?
Hi,
On Wed, 3 Jun 2015 22:52:47 +0300
Grygorii Strashko grygorii.stras...@ti.com wrote:
Hi Geert,
On 05/19/2015 12:38 PM, Geert Uytterhoeven wrote:
On Mon, May 18, 2015 at 4:52 PM, grygorii.stras...@linaro.org
grygorii.stras...@linaro.org wrote:
On 05/18/2015 05:31 PM, Thomas Gleixner wrote:
On Sun, 17 May 2015, Geert Uytterhoeven wrote:
At least the recursive locking message no longer appears after the
revert.
[ 30.591905] PM: Syncing filesystems ... done.
[ 30.623060] Freezing user space processes ... (elapsed 0.003
seconds) done.
[ 30.634470] Freezing remaining freezable tasks ... (elapsed 0.002
seconds) done.
[ 30.658288] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[ 30.663678]
[ 30.663681] =
[ 30.663683] [ INFO: possible recursive locking detected ]
[ 30.663688] 4.1.0-rc3 #1115 Not tainted
[ 30.663693] -
[ 30.663697] suspend.sh/2319 is trying to acquire lock:
[ 30.663719] (class){..}, at: [c0096ebc]
__irq_get_desc_lock+0x48/0x88
[ 30.663722]
[ 30.663722] but task is already holding lock:
[ 30.663734] (class){..}, at: [c0096ebc]
__irq_get_desc_lock+0x48/0x88
Does this mean .set_irq_wake() cannot call irq_set_irq_wake()?
It can call it, if it's guaranteed that this wont deadlock.
To tell lockdep that you sure about that, you need to set a different
lock class for the child interrupts. irq_set_lockdep_class() is what
you want to use here.
Hm. Seems we already have corresponding call in gpiochip_irq_map:
static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hwirq)
{
struct gpio_chip *chip = d-host_data;
irq_set_chip_data(irq, chip);
irq_set_lockdep_class(irq, gpiochip_irq_lock_class);
That piece of code sets the lockdep class of the gpiochip's interrupts, not
the parent interrupt.
Found out the hard way by adding some debug code ;-)
[..]
However, I cannot reproduce the problem on sh73a0/kzm9g with
s2ram on a current tree (renesas-drivers-2015-05-19-v4.1-rc4 from
(https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git),
using
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_LOCKDEP=y
CONFIG_PROVE_LOCKING=y
Wake-up from gpio-keys works fine, no scary messages.
commit e45d1c80c0eee88e82751461e9cac49d9ed287bc
Author: Linus Walleij linus.wall...@linaro.org
Date: Tue Apr 22 14:01:46 2014 +0200
gpio: put GPIO IRQs into their own lock clas
added in Kernel v3.16
Roger, can you confirm that you've observed this issue with latest kernel,
pls?
Yes please. Thanks!
Issue is reproducible on v4.1-rc6
Unfortunately, I was able to reproduce it, but have no clue how to fix it
gracefully.
lockdep_set_class_and_subclass(..,gpio_chip-base)?
HW configuration which generates lockdep warning:
[SOC GPIO bankA.gpioX] - irq - [pcf875x.gpioY] - irq -
DevZ.enable_irq_wake(pcf_gpioY_irq);
There stacked GPIO chips, but gpiolib uses only one lockdep class for all
GPIOirqchips -
- gpiochip_irq_lock_class.
If this is a gpiolib core issue are we (dra7-evm) the only stacked GPIO users
facing
this problem?
Linus/Alexandre/Geert,
Please advise what can be done for v4.1. The warning is annoying for dra7-evm
users.
Should we temporarily revert the patch even though it is correct and add it
back when the
gpiolib core issue is fixed?
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
* Felipe Balbi ba...@ti.com [150604 13:41]: On Thu, Jun 04, 2015 at 10:32:40PM +0200, Mason wrote: On 04/06/2015 22:08, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? Disclaimer: I am a kernel noob, take everything I say with a rock of salt. As far as I can see, the global timer code doesn't handle frequency changes, whereas the TWD code does. All right, but TWD has C3STOP and that prevents it from being used as broadcast device. Tony Lindgren had the idea of implementing a timer switch during idle and that could help us strip the kernel off of C3STOP feature flag. That means we might be able to use TWD as broadcast until CPU decides to idle, at which point we need to switch to a different timer. Yeah I'm looking at adding clocksource_pm_enter/exit() to allow also changing the clocksource to a different one for idle.. Will post some patches after investigating it a bit further. Changing the clockevent for idle already works just fine based on tick_broadcast_enable() + tick_broadcast_enter/exit(). Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] clk: ti: Use of_clk_get_parent_count() instead of open coding
On 05/29, Geert Uytterhoeven wrote: Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] clk: at91: Use of_clk_get_parent_count() instead of open coding
On 05/29, Geert Uytterhoeven wrote: Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] clk: st: Use of_clk_get_parent_count() instead of open coding
On 05/29, Geert Uytterhoeven wrote: Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On 04/06/2015 22:37, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 10:32:40PM +0200, Mason wrote: On 04/06/2015 22:08, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? Disclaimer: I am a kernel noob, take everything I say with a rock of salt. As far as I can see, the global timer code doesn't handle frequency changes, whereas the TWD code does. All right, but TWD has C3STOP and that prevents it from being used as broadcast device. AFAICT, my platform doesn't stop the local timers in low-power mode, so I just dropped the CLOCK_EVT_FEAT_C3STOP flag. There's even a patch approved by Arnd somewhere in the thread, although he did recommend I should investigate to understand the problem better. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] ARM: OMAP2+: Add support for initializing dm814x clocks
* Stephen Boyd sb...@codeaurora.org [150604 11:44]:
On 06/03, Tony Lindgren wrote:
diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
new file mode 100644
index 000..bd2353c
--- /dev/null
+++ b/drivers/clk/ti/clk-814x.c
@@ -0,0 +1,36 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
Is list.h used?
+#include linux/clk-provider.h
+#include linux/clk/ti.h
+
+static struct ti_dt_clk dm814_clks[] = {
+ DT_CLK(NULL, devosc_ck, devosc_ck),
+ DT_CLK(NULL, mpu_ck, mpu_ck),
+ DT_CLK(NULL, sysclk4_ck, sysclk4_ck),
+ DT_CLK(NULL, sysclk6_ck, sysclk6_ck),
+ DT_CLK(NULL, sysclk10_ck, sysclk10_ck),
+ DT_CLK(NULL, sysclk18_ck, sysclk18_ck),
+ DT_CLK(NULL, timer_sys_ck, devosc_ck),
+ DT_CLK(NULL, cpsw_125mhz_gclk, cpsw_125mhz_gclk),
+ DT_CLK(NULL, cpsw_cpts_rft_clk, cpsw_cpts_rft_clk),
+ { .node_name = NULL },
+};
+
+static const char *enable_init_clks[] = {
+};
delete?
+
+int __init dm814x_dt_clk_init(void)
+{
+ ti_dt_clocks_register(dm814_clks);
+ omap2_clk_disable_autoidle_all();
+ omap2_clk_enable_init_clocks(enable_init_clks,
+ARRAY_SIZE(enable_init_clks));
And pass NULL and 0 here?
Sure will remove, we can add those back once the PLL parts are
working and if/when some boot time clocks are needed.
Thanks.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On Thu, Jun 04, 2015 at 10:32:40PM +0200, Mason wrote: On 04/06/2015 22:08, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? Disclaimer: I am a kernel noob, take everything I say with a rock of salt. As far as I can see, the global timer code doesn't handle frequency changes, whereas the TWD code does. All right, but TWD has C3STOP and that prevents it from being used as broadcast device. Tony Lindgren had the idea of implementing a timer switch during idle and that could help us strip the kernel off of C3STOP feature flag. That means we might be able to use TWD as broadcast until CPU decides to idle, at which point we need to switch to a different timer. Yet all these timers are clocked by PERIPHCLK, which is defined as CPUCLK / N. So if a platform enables cpufreq, CPUCLK will vary, meaning PERIPHCLK will vary. I don't see how the global timer can work in that situation. cf. also this recent thread: http://thread.gmane.org/gmane.linux.kernel.cpufreq/15770 I'll have a read, cheers. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype
Hi folks just a brief comment on this one: On Thu, 30 Apr 2015, Boris Brezillon wrote: Clock rates are stored in an unsigned long field, but -round_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change -round_rate() prototype to return 0 or an error code, and pass the requested rate as a pointer so that it can be adjusted depending on hardware capabilities. ... diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 0e4f90a..fca8b7a 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -68,8 +68,8 @@ the operations defined in clk.h: int (*is_enabled)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); - long(*round_rate)(struct clk_hw *hw, - unsigned long rate, + int (*round_rate)(struct clk_hw *hw, + unsigned long *rate, unsigned long *parent_rate); long(*determine_rate)(struct clk_hw *hw, unsigned long rate, I'd suggest that we should probably go straight to 64-bit rates. There are already plenty of clock sources that can generate rates higher than 4GiHz. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On 06/04, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 03:18:25PM -0500, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 03:08:50PM -0500, Felipe Balbi wrote: Hi, On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? arm_global_timer is marked PERCPU, so it will never be chosen as broadcast. Perhaps this is acceptable ? diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c index e6833771a716..8c0170ac367d 100644 --- a/drivers/clocksource/arm_global_timer.c +++ b/drivers/clocksource/arm_global_timer.c @@ -169,8 +169,9 @@ static int gt_clockevents_init(struct clock_event_device *clk) int cpu = smp_processor_id(); clk-name = arm_global_timer; - clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | - CLOCK_EVT_FEAT_PERCPU; + clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT; + if (is_smp() || setup_max_cpus) + clk-features |= CLOCK_EVT_FEAT_PERCPU; clk-set_mode = gt_clockevent_set_mode; clk-set_next_event = gt_clockevent_set_next_event; clk-cpumask = cpumask_of(cpu); What is this doing? Allowing the global timer to become the broadcast timer? Can you share all the clockevents that are being registered in the system and what ratings and features they have? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: configure regulators for Gumstix Pepper
From: Adam YH Lee adam.yh@gmail.com
Boot process is halting in midway because some of the necessary voltage
regulators are deemed unused and subsequently powered off, leading to
a completely unresponsive system.
Most of the device nodes had correct voltage regulator attachments.
Yet these nodes had to set stricter enforcement on them through
'regulator-boot-on' and 'regulator-always-on' to function correctly.
Signed-off-by: Ash Charles ashchar...@gmail.com
---
arch/arm/boot/dts/am335x-pepper.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 473d8ee..99f855d 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -415,6 +415,7 @@
v3v3c_reg {
regulator-name = v3v3c_reg;
+ regulator-boot-on;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
vin-supply = vbat;
@@ -439,6 +440,8 @@
regulators {
dcdc1_reg: regulator@0 {
/* VDD_1V8 system supply */
+ regulator-name = vdds_dpr;
+ regulator-always-on;
};
dcdc2_reg: regulator@1 {
@@ -447,6 +450,7 @@
regulator-min-microvolt = 925000;
regulator-max-microvolt = 1325000;
regulator-boot-on;
+ regulator-always-on;
};
dcdc3_reg: regulator@2 {
@@ -455,25 +459,34 @@
regulator-min-microvolt = 925000;
regulator-max-microvolt = 115;
regulator-boot-on;
+ regulator-always-on;
};
ldo1_reg: regulator@3 {
/* VRTC 1.8V always-on supply */
+ regulator-name = vrtc,vdds;
regulator-always-on;
};
ldo2_reg: regulator@4 {
/* 3.3V rail */
+ regulator-name = vdd_3v3aux;
+ regulator-always-on;
};
ldo3_reg: regulator@5 {
/* VDD_3V3A 3.3V rail */
+ regulator-name = vdd_3v3a;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
+ regulator-boot-on;
+ regulator-always-on;
};
ldo4_reg: regulator@6 {
/* VDD_3V3B 3.3V rail */
+ regulator-name = vdd_3v3b;
+ regulator-always-on;
};
};
};
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] [RFC] ARM: timer-sp: Use of_clk_get_parent_count() instead of open coding
On 06/04, Geert Uytterhoeven wrote:
Hi Stephen,
On Thu, Jun 4, 2015 at 1:44 AM, Stephen Boyd sb...@codeaurora.org wrote:
On 05/29, Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
#include linux/err.h
#include linux/interrupt.h
#include linux/irq.h
@@ -234,7 +235,7 @@ static void __init sp804_of_init(struct device_node
*np)
clk1 = NULL;
/* Get the 2nd clock if the timer has 3 timer clocks */
- if (of_count_phandle_with_args(np, clocks, #clock-cells) == 3) {
+ if (of_clk_get_parent_count(np) == 3) {
So maybe it means if we want to expose of_clk_get_parent_count()
we should move it to some other header file (of_clk.h?). And then
maybe we should always compile said helpers if OF=y and
HAVE_CLK=y.
That makes sense.
Currently we have lots of of_clk_*() in linux/clk-provider.h, and a few
of_clk_get*() in inux/clk.h.
And the mysterious of_clk_set_defaults() in linux/clk/clk-conf.h.
All of_clk_get*() could be moved to a new linux/of_clk.h.
Alternatively, of_clk_get_parent_count() could just move to linux/clk.h?
Hmm... of_clk_*() functions that return a struct clk * or work
with a struct clk * should stay within clk.h. But these ones in
clk-provider.h should probably move to a new of_clk.h file:
of_clk_get_parent_count
of_clk_get_parent_name
of_clk_init
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: dts: Fix frequency scaling on Gumstix Pepper.
The device tree for Gumstix Pepper has DCDC2 and DCDC3 correctly labelled but the upper limit values are wrong. The confusion is due to the hardware quirk where the DCDC2 and DCDC3 wires are flipped in Pepper. Signed-off-by: Arun Bharadwaj a...@gumstix.com --- arch/arm/boot/dts/am335x-pepper.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/am335x-pepper.dts b/arch/arm/boot/dts/am335x-pepper.dts index 99f855d..37b95f6 100644 --- a/arch/arm/boot/dts/am335x-pepper.dts +++ b/arch/arm/boot/dts/am335x-pepper.dts @@ -448,7 +448,7 @@ /* VDD_CORE voltage limits 0.95V - 1.26V with +/-4% tolerance */ regulator-name = vdd_core; regulator-min-microvolt = 925000; - regulator-max-microvolt = 1325000; + regulator-max-microvolt = 115; regulator-boot-on; regulator-always-on; }; @@ -457,7 +457,7 @@ /* VDD_MPU voltage limits 0.95V - 1.1V with +/-4% tolerance */ regulator-name = vdd_mpu; regulator-min-microvolt = 925000; - regulator-max-microvolt = 115; + regulator-max-microvolt = 1325000; regulator-boot-on; regulator-always-on; }; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: Correct audio input route set mic bias
From: Adam YH Lee adam.yh@gmail.com
Audio-in was incorrectly routed to Line In. It should be Mic3L as per
schematic.
Using mic-bias voltage at 2.0v (0x1) does not work for some reason. There
is no voltage seen on micbias (R127). Mic-bias voltage of 2.5v (0x2) works.
I see voltage of 2.475v across GND and micbias.
With these changes, I can record audio with a pair of proliferate TRRS earbuds.
Signed-off-by: Ash Charles ashchar...@gmail.com
---
arch/arm/boot/dts/am335x-pepper.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-pepper.dts
b/arch/arm/boot/dts/am335x-pepper.dts
index 0d35ab6..473d8ee 100644
--- a/arch/arm/boot/dts/am335x-pepper.dts
+++ b/arch/arm/boot/dts/am335x-pepper.dts
@@ -74,6 +74,7 @@
audio_codec: tlv320aic3106@1b {
compatible = ti,tlv320aic3106;
reg = 0x1b;
+ ai3x-micbias-vg = 0x2;
};
accel: lis331dlh@1d {
@@ -153,7 +154,7 @@
ti,audio-routing =
Headphone Jack, HPLOUT,
Headphone Jack, HPROUT,
- LINE1L, Line In;
+ MIC3L,Mic3L Switch;
};
mcasp0 {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: next-20150604 build: 2 failures 37 warnings (next-20150604)
* Mark Brown broo...@kernel.org [150604 10:03]: On Thu, Jun 04, 2015 at 05:47:05PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ../drivers/tty/serial/8250/8250_omap.c:586:20: error: redefinition of 'omap8250_irq' Current -next fails to build an ARM allmodconfig (and possibly other things) due to 9e91597f24234 and 9809889c708eb (serial: 8250_omap: provide complete custom startup shutdown callbacks) which appear to be the same commit that's been applied twice somehow. Not sure what's going on there... Sounds like I'm using an old commit in one of my pending branches, will check immediately. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: next-20150604 build: 2 failures 37 warnings (next-20150604)
* Tony Lindgren t...@atomide.com [150604 10:11]: * Mark Brown broo...@kernel.org [150604 10:03]: On Thu, Jun 04, 2015 at 05:47:05PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ../drivers/tty/serial/8250/8250_omap.c:586:20: error: redefinition of 'omap8250_irq' Current -next fails to build an ARM allmodconfig (and possibly other things) due to 9e91597f24234 and 9809889c708eb (serial: 8250_omap: provide complete custom startup shutdown callbacks) which appear to be the same commit that's been applied twice somehow. Not sure what's going on there... Sounds like I'm using an old commit in one of my pending branches, will check immediately. Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in tty-next. I gues I'll drop my omap-for-v4.2/wakeirq branch from linux next for now. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: next-20150604 build: 2 failures 37 warnings (next-20150604)
On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150604 10:11]: Sounds like I'm using an old commit in one of my pending branches, will check immediately. Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in tty-next. Thanks for investigating! signature.asc Description: Digital signature
[PATCH 0/3] ARM: dts: Changes for Gumstix Pepper dts
These 3 patches are included to fix the following issues with pepper device tree source. The patches are based against linux-omap/master. Adam YH Lee (2): ARM: dts: Correct audio input route set mic bias ARM: dts: configure regulators for Gumstix Pepper Arun Bharadwaj (1): ARM: dts: Fix frequency scaling on Gumstix Pepper. arch/arm/boot/dts/am335x-pepper.dts | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] ARM: OMAP2+: Add support for initializing dm814x clocks
On 06/03, Tony Lindgren wrote:
diff --git a/drivers/clk/ti/clk-814x.c b/drivers/clk/ti/clk-814x.c
new file mode 100644
index 000..bd2353c
--- /dev/null
+++ b/drivers/clk/ti/clk-814x.c
@@ -0,0 +1,36 @@
+/*
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
Is list.h used?
+#include linux/clk-provider.h
+#include linux/clk/ti.h
+
+static struct ti_dt_clk dm814_clks[] = {
+ DT_CLK(NULL, devosc_ck, devosc_ck),
+ DT_CLK(NULL, mpu_ck, mpu_ck),
+ DT_CLK(NULL, sysclk4_ck, sysclk4_ck),
+ DT_CLK(NULL, sysclk6_ck, sysclk6_ck),
+ DT_CLK(NULL, sysclk10_ck, sysclk10_ck),
+ DT_CLK(NULL, sysclk18_ck, sysclk18_ck),
+ DT_CLK(NULL, timer_sys_ck, devosc_ck),
+ DT_CLK(NULL, cpsw_125mhz_gclk, cpsw_125mhz_gclk),
+ DT_CLK(NULL, cpsw_cpts_rft_clk, cpsw_cpts_rft_clk),
+ { .node_name = NULL },
+};
+
+static const char *enable_init_clks[] = {
+};
delete?
+
+int __init dm814x_dt_clk_init(void)
+{
+ ti_dt_clocks_register(dm814_clks);
+ omap2_clk_disable_autoidle_all();
+ omap2_clk_enable_init_clocks(enable_init_clks,
+ ARRAY_SIZE(enable_init_clks));
And pass NULL and 0 here?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On Thu, Jun 04, 2015 at 03:18:25PM -0500, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 03:08:50PM -0500, Felipe Balbi wrote: Hi, On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? arm_global_timer is marked PERCPU, so it will never be chosen as broadcast. Perhaps this is acceptable ? diff --git a/drivers/clocksource/arm_global_timer.c b/drivers/clocksource/arm_global_timer.c index e6833771a716..8c0170ac367d 100644 --- a/drivers/clocksource/arm_global_timer.c +++ b/drivers/clocksource/arm_global_timer.c @@ -169,8 +169,9 @@ static int gt_clockevents_init(struct clock_event_device *clk) int cpu = smp_processor_id(); clk-name = arm_global_timer; - clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT | - CLOCK_EVT_FEAT_PERCPU; + clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT; + if (is_smp() || setup_max_cpus) + clk-features |= CLOCK_EVT_FEAT_PERCPU; clk-set_mode = gt_clockevent_set_mode; clk-set_next_event = gt_clockevent_set_next_event; clk-cpumask = cpumask_of(cpu); -- balbi signature.asc Description: Digital signature
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On 04/06/2015 22:08, Felipe Balbi wrote: On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? Disclaimer: I am a kernel noob, take everything I say with a rock of salt. As far as I can see, the global timer code doesn't handle frequency changes, whereas the TWD code does. Yet all these timers are clocked by PERIPHCLK, which is defined as CPUCLK / N. So if a platform enables cpufreq, CPUCLK will vary, meaning PERIPHCLK will vary. I don't see how the global timer can work in that situation. cf. also this recent thread: http://thread.gmane.org/gmane.linux.kernel.cpufreq/15770 Regards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
Vinod, On 06/02/2015 03:55 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote: On 05/29/2015 01:18 PM, Vinod Koul wrote: On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote: On Fri, May 29, 2015 at 11:33 AM, Vinod Koul vinod.k...@intel.com wrote: On Tue, May 26, 2015 at 04:25:57PM +0300, Peter Ujfalusi wrote: dma_request_slave_channel_compat() 'eats' up the returned error codes which prevents drivers using the compat call to be able to do deferred probing. The new wrapper is identical in functionality but it will return with error code in case of failure and will pass the -EPROBE_DEFER to the caller in case dma_request_slave_channel_reason() returned with it. This is okay but am worried about one more warpper, how about fixing dma_request_slave_channel_compat() Then all callers of dma_request_slave_channel_compat() have to be modified to handle ERR_PTR first. The same is true for (the existing) dma_request_slave_channel_reason() vs. dma_request_slave_channel(). Good point, looking again, I think we should rather fix dma_request_slave_channel_reason() as it was expected to return err code and add new users. Anyway users of this API do expect the reason... Hrm, they are for different use.dma_request_slave_channel()/_reason() is for drivers only working via DT or ACPI while dma_request_slave_channel_compat()/_reason() is for drivers expected to run in DT/ACPI or legacy mode as well. I added the dma_request_slave_channel_compat_reason() because OMAP/daVinci drivers are using this to request channels - they need to support DT and legacy mode. I think we should hide these things behind the API and do this behind the hood for ACPI/DT systems. Also it makes sense to use right API and mark rest as depricated So to convert the dma_request_slave_channel_compat() and not to create _reason variant? Or to have single API to request channel? The problem with that is that we need different parameters for legacy and DT for example. But it is doable to do this for both the non _compat and _compat version: 1. change all users to check IS_ERR_OR_NULL(chan) return the PTR_ERR if not NULL, or do whatever the driver was doing in case of chan == NULL. 2. change the non _compat and _compat versions to do the same as the _reason variants, #define the _reason ones to the non _reason names 3. Rename the _reason use to non _reason function in drivers 4. Remove the #defines for the _reason functions 5. Change the IS_ERR_OR_NULL(chan) to IS_ERR(chan) in all drivers The result: Both dma_request_slave_channel() and dma_request_slave_channel_compat() will return ERR_PTR in case of failure or in success they will return the pinter to chan. Is this what you were asking? It is a bit broader than what this series was doing: taking care of OMAP/daVinci drivers for deferred probing regarding to dmaengine ;) Yes but it would make sense right? I know it is a larger work but then we wouldn't want another dma_request_slave_xxx API, at some point we have stop it exapnding, perhpas now :) Yes, it make sense to get rid if the _reason() things and have the dma_request_slave_channel() and dma_request_slave_channel_compat() return with error code One thing we need to do for this is to change the error codes coming back from the _dt() and _acpi() calls when we boot in legacy mode. Right now the only error code which comes back is -ENODEV and -EPROBE_DEFER. We need to differentiate between 'real' errors and from the fact that we did not booted with DT or the ACPI is not available. IMHO if we boot with DT and the channel request fails with other than -EPROBE_DEFER we should not go and try to get the channel via legacy API. Yes I am all ears to stage this work and not do transition gardually.. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: next-20150604 build: 2 failures 37 warnings (next-20150604)
On Thu, Jun 04, 2015 at 05:47:05PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ../drivers/tty/serial/8250/8250_omap.c:586:20: error: redefinition of 'omap8250_irq' Current -next fails to build an ARM allmodconfig (and possibly other things) due to 9e91597f24234 and 9809889c708eb (serial: 8250_omap: provide complete custom startup shutdown callbacks) which appear to be the same commit that's been applied twice somehow. Not sure what's going on there... signature.asc Description: Digital signature
Re: [RFT v2 05/48] gpio: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
Hello Jiang, On Thu, Jun 4, 2015 at 6:13 AM, Jiang Liu jiang@linux.intel.com wrote: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org --- drivers/gpio/gpio-bcm-kona.c |2 +- drivers/gpio/gpio-dwapb.c |2 +- drivers/gpio/gpio-mvebu.c |2 +- drivers/gpio/gpio-mxc.c|6 +++--- drivers/gpio/gpio-mxs.c|2 +- drivers/gpio/gpio-omap.c |2 +- For gpio-omap: Acked-by: Javier Martinez Canillas jav...@dowhile0.org Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT v2 45/48] genirq, gpio: Kill the first parameter 'irq' of irq_flow_handler_t
Hello Jiang, On Thu, Jun 4, 2015 at 6:13 AM, Jiang Liu jiang@linux.intel.com wrote: Now most IRQ flow handlers make no use of the first parameter 'irq'. And for those who do make use of 'irq', we could easily get the irq number through irq_desc-irq_data-irq. So kill the first parameter 'irq' of irq_flow_handler_t. To ease review, I have split the changes into several parts, though they should be merge as one to support bisecting. Signed-off-by: Jiang Liu jiang@linux.intel.com --- drivers/gpio/gpio-altera.c |6 ++ drivers/gpio/gpio-bcm-kona.c |2 +- drivers/gpio/gpio-davinci.c|2 +- drivers/gpio/gpio-dwapb.c |2 +- drivers/gpio/gpio-ep93xx.c |4 ++-- drivers/gpio/gpio-intel-mid.c |2 +- drivers/gpio/gpio-lynxpoint.c |2 +- drivers/gpio/gpio-mpc8xxx.c|2 +- drivers/gpio/gpio-msic.c |2 +- drivers/gpio/gpio-msm-v2.c |2 +- drivers/gpio/gpio-mvebu.c |2 +- drivers/gpio/gpio-mxc.c|4 ++-- drivers/gpio/gpio-mxs.c|2 +- drivers/gpio/gpio-omap.c |2 +- For gpio-omap: Acked-by: Javier Martinez Canillas jav...@dowhile0.org Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] clk: change clk_ops' -determine_rate() prototype
Hi Stefen,
On Wed, 3 Jun 2015 16:37:28 -0700
Stephen Boyd sb...@codeaurora.org wrote:
On 05/20, Boris Brezillon wrote:
Clock rates are stored in an unsigned long field, but -determine_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change -determine_rate() prototype to return 0 or an error code, and pass
a pointer to a clk_rate_request structure containing the expected target
rate and the rate constraints imposed by clk users.
The clk_rate_request structure might be extended in the future to contain
other kind of constraints like the rounding policy, the maximum clock
inaccuracy or other things that are not yet supported by the CCF
(power consumption constraints ?).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
CC: Jonathan Corbet cor...@lwn.net
CC: Tony Lindgren t...@atomide.com
CC: Ralf Baechle r...@linux-mips.org
CC: Emilio López emi...@elopez.com.ar
CC: Maxime Ripard maxime.rip...@free-electrons.com
CC: Tero Kristo t-kri...@ti.com
CC: linux-...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-arm-ker...@lists.infradead.org
CC: linux-omap@vger.kernel.org
CC: linux-m...@linux-mips.org
---
Hi Stephen,
This patch is based on clk-next and contains the changes you suggested
in your previous review.
It was tested on sama5d4 and compile tested on several ARM platforms
(those enabled in multi_v7_defconfig).
Thanks. I think we should wait until the next -rc1 drops to apply the
patch for the next merge window. That will make it least likely to conflict
with other trees, and we can provide it on a stable branch should there
be clock providers going through other trees somewhere. Please
remind me if I forget.
No problem.
@@ -1186,15 +1191,21 @@ EXPORT_SYMBOL_GPL(__clk_determine_rate);
*/
unsigned long __clk_round_rate(struct clk *clk, unsigned long rate)
{
- unsigned long min_rate;
- unsigned long max_rate;
+
+ struct clk_rate_request req;
+ int ret;
if (!clk)
return 0;
- clk_core_get_boundaries(clk-core, min_rate, max_rate);
+ clk_core_get_boundaries(clk-core, req.min_rate, req.max_rate);
+ req.rate = rate;
+
+ ret = clk_core_round_rate_nolock(clk-core, req);
+ if (ret)
+ return ret;
This returns a negative int for unsigned long. Is that intentional?
Nope, should be replaced by 'return 0;'.
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 10/10] arm/dts: am57xx-beagle-x15.dts: add HDMI
On 03/06/15 20:16, Tony Lindgren wrote: OK, since there are no other merge conflicts that I'm aware of, it's best that you merge the whole branch. I've acked the patches, so for this one too: Ok, I can do that, but isn't this more linux-arm stuff? All the driver side code is already in the mainline. Yes but we're getting so late into merge window that I'd rather not take it for v4.2 at this point. And it's all DSS related. Please make sure you get an ack for the drivers/clk/omap change from Mike or Stephen though. Naturally I mean getting so close to the merge window above :) Thanks everyone. I've pushed this to fbdev for-next. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 5/5] [RFC] ARM: timer-sp: Use of_clk_get_parent_count() instead of open coding
Hi Stephen,
On Thu, Jun 4, 2015 at 1:44 AM, Stephen Boyd sb...@codeaurora.org wrote:
On 05/29, Geert Uytterhoeven wrote:
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
---
This is an RFC, as it depends on [RFC] clk: Provide dummy
of_clk_get_parent_count() for !OF/!CCF.
---
arch/arm/common/timer-sp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/common/timer-sp.c b/arch/arm/common/timer-sp.c
index 19211324772f387c..be87a5d480ffb655 100644
--- a/arch/arm/common/timer-sp.c
+++ b/arch/arm/common/timer-sp.c
@@ -21,6 +21,7 @@
#include linux/clk.h
#include linux/clocksource.h
#include linux/clockchips.h
+#include linux/clk-provider.h
This looks weird. This is not a clock provider.
But that's where the declaration of of_clk_get_parent_count() lives...
#include linux/err.h
#include linux/interrupt.h
#include linux/irq.h
@@ -234,7 +235,7 @@ static void __init sp804_of_init(struct device_node *np)
clk1 = NULL;
/* Get the 2nd clock if the timer has 3 timer clocks */
- if (of_count_phandle_with_args(np, clocks, #clock-cells) == 3) {
+ if (of_clk_get_parent_count(np) == 3) {
So maybe it means if we want to expose of_clk_get_parent_count()
we should move it to some other header file (of_clk.h?). And then
maybe we should always compile said helpers if OF=y and
HAVE_CLK=y.
That makes sense.
Currently we have lots of of_clk_*() in linux/clk-provider.h, and a few
of_clk_get*() in inux/clk.h.
And the mysterious of_clk_set_defaults() in linux/clk/clk-conf.h.
All of_clk_get*() could be moved to a new linux/of_clk.h.
Alternatively, of_clk_get_parent_count() could just move to linux/clk.h?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On 03/06/2015 23:54, Felipe Balbi wrote: On Wed, Jun 03, 2015 at 02:41:39PM -0700, Stephen Boyd wrote: AM43xx, even though it's a single processor A9, it still has TWD and global timer. I was doing some profiling with RT v4.0 and latency is 3.5x lower just by switching from gptimer to twd/global. The only problem is that currently, is_smp() check prevents me from using twd with AM43xx (that's why it's commented below, for testing purposes). In the hopes that we can start a, hopefully, small thread around the subject, I'm sending this HACK which I used to get TWD and global timer enabled so I could measure latencies with cyclictest. Is it so that TWD shouldn't be available on UP integrations of ARM's Cortex-A processors ? I wondered about this recently when looking at something unrelated and noticed that the check had been introduced as part of 904464b91eca8 (ARM: 7655/1: smp_twd: make twd_local_timer_of_register() no-op for nosmp). I suspect this was just the wrong fix at the time, and that the real culprit is either alloc_percpu() or request_percpu_irq() getting called too early on a machine without SMP support. Possibly the problem is already resolved independently, if you didn't run into it. no, no splats, nothing at all. See [1] [1] http://hastebin.com/helekubutu Adding Shawn Mason was also interested in doing this. See [2]. From what I could tell back then, commit 904464b91eca8 was working around the local timer APIs that no longer exist. [2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/389931/focus=392348 A lot of good information on that thread, thanks. Seems like getting twd/global timer working would also have some effect on context switching, perhaps ? Hello, In my case, I need to support two platforms: single core Cortex A9 MPCore dual core Cortex A9 MPCore However, as the MPCore moniker implies, even the single core platform is SMP capable. (I think this only means an SCU is available?) Thus, I worked around the issue by using the same SMP kernel for both platforms; which is why I didn't push any patch. Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Regards. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: On 03/06/2015 23:54, Felipe Balbi wrote: On Wed, Jun 03, 2015 at 02:41:39PM -0700, Stephen Boyd wrote: AM43xx, even though it's a single processor A9, it still has TWD and global timer. I was doing some profiling with RT v4.0 and latency is 3.5x lower just by switching from gptimer to twd/global. The only problem is that currently, is_smp() check prevents me from using twd with AM43xx (that's why it's commented below, for testing purposes). In the hopes that we can start a, hopefully, small thread around the subject, I'm sending this HACK which I used to get TWD and global timer enabled so I could measure latencies with cyclictest. Is it so that TWD shouldn't be available on UP integrations of ARM's Cortex-A processors ? I wondered about this recently when looking at something unrelated and noticed that the check had been introduced as part of 904464b91eca8 (ARM: 7655/1: smp_twd: make twd_local_timer_of_register() no-op for nosmp). I suspect this was just the wrong fix at the time, and that the real culprit is either alloc_percpu() or request_percpu_irq() getting called too early on a machine without SMP support. Possibly the problem is already resolved independently, if you didn't run into it. no, no splats, nothing at all. See [1] [1] http://hastebin.com/helekubutu Adding Shawn Mason was also interested in doing this. See [2]. From what I could tell back then, commit 904464b91eca8 was working around the local timer APIs that no longer exist. [2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/389931/focus=392348 A lot of good information on that thread, thanks. Seems like getting twd/global timer working would also have some effect on context switching, perhaps ? Hello, In my case, I need to support two platforms: single core Cortex A9 MPCore dual core Cortex A9 MPCore However, as the MPCore moniker implies, even the single core platform is SMP capable. (I think this only means an SCU is available?) Thus, I worked around the issue by using the same SMP kernel for both platforms; which is why I didn't push any patch. Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Yeah, I have a broadcast device however Linux is picking a gp timer instead of A9's global timer. Now I think I managed to get Linux to choose global, but my device won't boot anymore :-p Debugging that. I'm speculating global timer IRQs aren't firing or aren't wired up properly on this particular SoC, still to confirm. -- balbi signature.asc Description: Digital signature
Re: [RFT v2 45/48] genirq, gpio: Kill the first parameter 'irq' of irq_flow_handler_t
On Thu, Jun 4, 2015 at 6:13 AM, Jiang Liu jiang@linux.intel.com wrote: Now most IRQ flow handlers make no use of the first parameter 'irq'. And for those who do make use of 'irq', we could easily get the irq number through irq_desc-irq_data-irq. So kill the first parameter 'irq' of irq_flow_handler_t. To ease review, I have split the changes into several parts, though they should be merge as one to support bisecting. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
Hi, On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? -- balbi signature.asc Description: Digital signature
Re: [RFC/NOT FOR MERGING] HACK: add global/private timers for A9
On Thu, Jun 04, 2015 at 03:08:50PM -0500, Felipe Balbi wrote: Hi, On Thu, Jun 04, 2015 at 11:46:59AM +0200, Mason wrote: Also, check /proc/timer_list for a Broadcast device. If you don't define one, the TWD timers are set to periodic mode, with hrtimers disabled. Did you manage to turn global timer into Broadcast device ? arm_global_timer is marked PERCPU, so it will never be chosen as broadcast. -- balbi signature.asc Description: Digital signature
