Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On 01/21/2015 06:41 AM, Ohad Ben-Cohen wrote: On Tue, Jan 20, 2015 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: How about default to Linux id space and allow overriding that with a module param option if needed? I'm not sure I'm following. If the main point of contention is the base_id field, I'm also fine with removing it entirely, as I'm not aware of any actual user for it (Suman please confirm?). Yeah, well the current implementations that I am aware of only have a single bank, so all of them would be using a value of 0. I am yet to see a platform with multiple instances where the property really makes a difference. v7 has the property mandatory, so all the implementations would need to define this value even if it is 0. regards Suman Mark? Rob? Will you accept Suman's patches if the base_id field is removed? Thanks, Ohad. -- 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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains
* Marc Zyngier marc.zyng...@arm.com [150121 09:25]:
On 21/01/15 16:30, Tony Lindgren wrote:
I gave this a quick boot test on am437x-gp-evm and the
interrupts look OK with the fix also applied:
# cat /proc/interrupts
CPU0
16:657 WUGEN 68 gp_timer
18: 0 WUGEN 9 l3-dbg-irq
19: 0 WUGEN 10 l3-app-irq
20: 5 WUGEN 12 edma
22: 0 WUGEN 14 edma_error
23: 96 WUGEN 72 OMAP UART0
33: 0 44e07000.gpio 6 mmc0
158: 52 WUGEN 70 44e0b000.i2c
159: 0 WUGEN 71 4802a000.i2c
160: 35 WUGEN 64 mmc0
161: 0 WUGEN 40 4a10.ethernet
162: 7739 WUGEN 41 4a10.ethernet
163: 7608 WUGEN 42 4a10.ethernet
164: 0 WUGEN 43 4a10.ethernet
170: 0 WUGEN 100 gpmc
180: 0 WUGEN 7 tps65218
IPI0: 0 CPU wakeup interrupts
IPI1: 0 Timer broadcast interrupts
IPI2: 0 Rescheduling interrupts
IPI3: 0 Function call interrupts
IPI4: 0 Single function call interrupts
IPI5: 0 CPU stop interrupts
IPI6: 0 IRQ work interrupts
IPI7: 0 completion interrupts
Err: 0
Interesting. No TWD timer on this one?
Good question, adding Felipe to cc. It eems to be there in
the TRM in Table 2-3. L4_PER Peripheral Memory Map as
MPU_PRV_TIMERS. Also seems to actually work with the
attached patch:
# cat /proc/interrupts
CPU0
16: 0 WUGEN 67 gp_timer
17:529 GIC 29 twd
18: 0 WUGEN 9 l3-dbg-irq
19: 0 WUGEN 10 l3-app-irq
20: 5 WUGEN 12 edma
22: 0 WUGEN 14 edma_error
23:130 WUGEN 72 OMAP UART0
34: 0 44e07000.gpio 6 mmc0
159: 52 WUGEN 70 44e0b000.i2c
160: 0 WUGEN 71 4802a000.i2c
161: 35 WUGEN 64 mmc0
162: 0 WUGEN 40 4a10.ethernet
163: 8033 WUGEN 41 4a10.ethernet
164: 7769 WUGEN 42 4a10.ethernet
165: 0 WUGEN 43 4a10.ethernet
171: 0 WUGEN 100 gpmc
181: 0 WUGEN 7 tps65218
IPI0: 0 CPU wakeup interrupts
IPI1: 0 Timer broadcast interrupts
IPI2: 0 Rescheduling interrupts
IPI3: 0 Function call interrupts
IPI4: 0 Single function call interrupts
IPI5: 0 CPU stop interrupts
IPI6: 0 IRQ work interrupts
IPI7: 0 completion interrupts
Err: 0
Hmm I wonder why we have the !is_smp() check in the TWD timer?
Regards,
Tony
8 ---
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -51,6 +51,14 @@
interrupt-parent = gic;
};
+ local-timer@48240600 {
+ compatible = arm,cortex-a9-twd-timer;
+ clocks = dpll_mpu_m2_ck;
+ reg = 0x48240600 0x20;
+ interrupts = GIC_PPI 13 (GIC_CPU_MASK_RAW(3) |
IRQ_TYPE_LEVEL_HIGH);
+ interrupt-parent = gic;
+ };
+
wakeupgen: interrupt-controller@48281000 {
compatible = ti,omap4-wugen-mpu;
interrupt-controller;
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -388,7 +388,7 @@ static void __init twd_local_timer_of_register(struct
device_node *np)
{
int err;
- if (!is_smp() || !setup_max_cpus)
+ if (!setup_max_cpus)
return;
twd_ppi = irq_of_parse_and_map(np, 0);
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -237,7 +237,7 @@ DT_MACHINE_START(AM43_DT, Generic AM43 (Flattened Device
Tree))
.init_late = am43xx_init_late,
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
- .init_time = omap3_gptimer_timer_init,
+ .init_time = omap4_local_timer_init,
.dt_compat = am43_boards_compat,
.restart= omap44xx_restart,
MACHINE_END
--
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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains
On 21/01/15 16:30, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150119 01:48]: OMAP4/5 has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the WUGEN HW block, kernels with this patch applied won't have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs won't even boot. On a platform with this patch applied, the system looks like this: root@bacon-fat:~# cat /proc/interrupts CPU0 CPU1 16: 0 0 WUGEN 37 gp_timer 19: 233799 155916 GIC 27 arch_timer 23: 0 0 WUGEN 9 l3-dbg-irq 24: 1 0 WUGEN 10 l3-app-irq 27:282 0 WUGEN 13 omap-dma-engine 44: 0 0 4ae1.gpio 13 DMA You may want to update this part for the fix :) Ah, yes. Thanks for noticing this. I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Interesting. No TWD timer on this one? Also verified that suspend and resume to a serial console event works on omap4430-sdp. So please feel free to add: Acked-by: Tony Lindgren t...@atomide.com Thanks, M. -- Jazz is not dead. It just smells funny... -- 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/1] gpio: omap: Fix bad device access with setup_irq()
On Fri, Jan 16, 2015 at 11:50 PM, Tony Lindgren t...@atomide.com wrote: Similar to omap_gpio_irq_type() let's make sure that the GPIO is usable as an interrupt if the platform init code did not call gpio_request(). Otherwise we can get invalid device access after setup_irq(): WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [c05f21e4] (__irq_svc) from [c05f1974] (_raw_spin_unlock_irqrestore+0x34/0x44) [c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] (__setup_irq+0x244/0x530) [c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c) [c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4) [c0039c8c] (omap_system_dma_probe) from [c03b2200] (platform_drv_probe+0x44/0xa4) ... We can fix this the same way omap_gpio_irq_type() is handling it. Note that the long term solution is to change the gpio-omap driver to handle the banks as separate driver instances. This will allow us to rely on just runtime PM for tracking the bank specific state. Reported-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Felipe Balbi ba...@ti.com Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Kevin Hilman khil...@kernel.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Russell King - ARM Linux li...@arm.linux.org.uk Cc: Santosh Shilimkar ssant...@kernel.org Signed-off-by: Tony Lindgren t...@atomide.com Patch applied for fixes with Felipe's Tested-by. 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: [PATCH v4 12/21] DT: omap4/5: add binding for the wake-up generator
* Marc Zyngier marc.zyng...@arm.com [150119 01:48]:
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
Acked-by: Tony Lindgren t...@atomide.com
---
.../interrupt-controller/ti,omap4-wugen-mpu| 33
++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
new file mode 100644
index 000..43effa0
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/ti,omap4-wugen-mpu
@@ -0,0 +1,33 @@
+TI OMAP4 Wake-up Generator
+
+All TI OMAP4/5 (and their derivatives) an interrupt controller that
+routes interrupts to the GIC, and also serves as a wakeup source. It
+is also referred to as WUGEN-MPU, hence the name of the binding.
+
+Reguired properties:
+
+- compatible : should contain at least ti,omap4-wugen-mpu or
+ ti,omap5-wugen-mpu
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The value must be 3.
+- interrupt-parent : a phandle to the GIC these interrupts are routed
+ to.
+
+Notes:
+
+- Because this HW ultimately routes interrupts to the GIC, the
+ interrupt specifier must be that of the GIC.
+- Only SPIs can use the WUGEN as an interrupt parent. SGIs and PPIs
+ are explicitly forbiden.
+
+Example:
+
+ wakeupgen: interrupt-controller@48281000 {
+ compatible = ti,omap5-wugen-mpu, ti,omap4-wugen-mpu;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48281000 0x1000;
+ interrupt-parent = gic;
+ };
--
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 1/1] gpio: omap: Fix bad device access with setup_irq()
Hello Tony, On Fri, Jan 16, 2015 at 11:50 PM, Tony Lindgren t...@atomide.com wrote: Similar to omap_gpio_irq_type() let's make sure that the GPIO is usable as an interrupt if the platform init code did not call gpio_request(). Otherwise we can get invalid device access after setup_irq(): WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x214/0x340() 4400.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Idle): Data Access in Supervisor mode during Functional access ... [c05f21e4] (__irq_svc) from [c05f1974] (_raw_spin_unlock_irqrestore+0x34/0x44) [c05f1974] (_raw_spin_unlock_irqrestore) from [c00914a8] (__setup_irq+0x244/0x530) [c00914a8] (__setup_irq) from [c00917d4] (setup_irq+0x40/0x8c) [c00917d4] (setup_irq) from [c0039c8c] (omap_system_dma_probe+0x1d4/0x2b4) [c0039c8c] (omap_system_dma_probe) from [c03b2200] (platform_drv_probe+0x44/0xa4) ... We can fix this the same way omap_gpio_irq_type() is handling it. I see that Linus already picked this patch but fwiw: Acked-by: Javier Martinez Canillas jav...@dowhile0.org Note that the long term solution is to change the gpio-omap driver to handle the banks as separate driver instances. This will allow us to rely on just runtime PM for tracking the bank specific state. Agreed. 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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains
On 1/21/2015 10:36 AM, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150121 09:25]: On 21/01/15 16:30, Tony Lindgren wrote: I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Interesting. No TWD timer on this one? Good question, adding Felipe to cc. It eems to be there in the TRM in Table 2-3. L4_PER Peripheral Memory Map as MPU_PRV_TIMERS. Also seems to actually work with the attached patch: TWD is useless on this machine since single core and TWD as know die in low power states. All the broadcast stuff is for SMP machines. Above is expected and correct and no patching is needed. Regards, Santosh -- 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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains
* santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]: On 1/21/2015 10:36 AM, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150121 09:25]: On 21/01/15 16:30, Tony Lindgren wrote: I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Interesting. No TWD timer on this one? Good question, adding Felipe to cc. It eems to be there in the TRM in Table 2-3. L4_PER Peripheral Memory Map as MPU_PRV_TIMERS. Also seems to actually work with the attached patch: TWD is useless on this machine since single core and TWD as know die in low power states. All the broadcast stuff is for SMP machines. Hmm it seems we should still use TWD during runtime and swich over to the gptimer for idle states for wake-up events. 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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains
On 1/21/2015 12:43 PM, Tony Lindgren wrote: * santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]: On 1/21/2015 10:36 AM, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150121 09:25]: On 21/01/15 16:30, Tony Lindgren wrote: I gave this a quick boot test on am437x-gp-evm and the interrupts look OK with the fix also applied: # cat /proc/interrupts CPU0 16:657 WUGEN 68 gp_timer 18: 0 WUGEN 9 l3-dbg-irq 19: 0 WUGEN 10 l3-app-irq 20: 5 WUGEN 12 edma 22: 0 WUGEN 14 edma_error 23: 96 WUGEN 72 OMAP UART0 33: 0 44e07000.gpio 6 mmc0 158: 52 WUGEN 70 44e0b000.i2c 159: 0 WUGEN 71 4802a000.i2c 160: 35 WUGEN 64 mmc0 161: 0 WUGEN 40 4a10.ethernet 162: 7739 WUGEN 41 4a10.ethernet 163: 7608 WUGEN 42 4a10.ethernet 164: 0 WUGEN 43 4a10.ethernet 170: 0 WUGEN 100 gpmc 180: 0 WUGEN 7 tps65218 IPI0: 0 CPU wakeup interrupts IPI1: 0 Timer broadcast interrupts IPI2: 0 Rescheduling interrupts IPI3: 0 Function call interrupts IPI4: 0 Single function call interrupts IPI5: 0 CPU stop interrupts IPI6: 0 IRQ work interrupts IPI7: 0 completion interrupts Err: 0 Interesting. No TWD timer on this one? Good question, adding Felipe to cc. It eems to be there in the TRM in Table 2-3. L4_PER Peripheral Memory Map as MPU_PRV_TIMERS. Also seems to actually work with the attached patch: TWD is useless on this machine since single core and TWD as know die in low power states. All the broadcast stuff is for SMP machines. Hmm it seems we should still use TWD during runtime and swich over to the gptimer for idle states for wake-up events. Well timer wheel code don't support it so if you are serious, some one needs to do that. For me, it is not worth at all. You will have more to loose than gain with these time switching schemes since you have to keep 2 times alive, do switching, loose the idle time. All of that is to save few CPU cycles since TWD is closer compared to other SOC timer. Anyways I will let you fight it out but IIRC, I had a discussion a while back with tglx in one of the conference and the conclusion was it not worth doing. Rather TWD hardware on SOC should be made wakeup capable and then everything is good. Till you have support, using TWD on AM43XX will break CPUIDLE. Not sure if it is supported or some one cares about it. Just keep that aspect in mind. Regards, Santosh -- 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 v11 2/4] clk: Make clk API return per-user struct clk instances
On 01/21, Tomeu Vizoso wrote:
@@ -2075,10 +2210,12 @@ struct clk *clk_register(struct device *dev, struct
clk_hw *hw)
}
}
- ret = __clk_init(dev, clk);
+ hw-clk = __clk_create_clk(hw, NULL, NULL);
+ ret = __clk_init(dev, hw-clk);
if (!ret)
- return clk;
+ return hw-clk;
+ kfree(hw-clk);
fail_parent_names_copy:
while (--i = 0)
kfree(clk-parent_names[i]);
Sigh, this patch is so huge I keep finding more things. Sorry. It
looks like __clk_create_clk() can return an error pointer, which
we then send directly to __clk_init. First off, we shouldn't
kfree() that pointer if it's an error pointer. Second, we
shouldn't crash in __clk_init() in such a situation so there
needs to be some sort of check somewhere.
BTW, please try and fixup checkpatch warnings.
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index da4bda8..fac3244 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -69,20 +70,22 @@ struct clk *of_clk_get(struct device_node *np, int index)
[...]
-struct clk *of_clk_get_by_name(struct device_node *np, const char *name)
+static struct clk *__of_clk_get_by_name(struct device_node *np, const char
*name)
It would be nice if this returned an already __clk_create_clk()ed
pointer.
{
struct clk *clk = ERR_PTR(-ENOENT);
@@ -119,7 +122,33 @@ struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
[...]
+struct clk *of_clk_get_by_name(struct device_node *np, const char *name)
+{
+ struct clk *clk = __of_clk_get_by_name(np, name);
+
+ if (!IS_ERR(clk))
+ clk = __clk_create_clk(__clk_get_hw(clk), np-full_name, name);
Because we do it here where we know we're CONFIG_COMMON_CLK=y.
+
+ return clk;
+}
EXPORT_SYMBOL(of_clk_get_by_name);
+
+#else /* defined(CONFIG_OF) defined(CONFIG_COMMON_CLK) */
+
+static struct clk *__of_clk_get_by_name(struct device_node *np, const char
*name)
+{
+ return ERR_PTR(-ENOENT);
+}
#endif
/*
@@ -185,9 +229,13 @@ struct clk *clk_get(struct device *dev, const char
*con_id)
struct clk *clk;
if (dev) {
- clk = of_clk_get_by_name(dev-of_node, con_id);
- if (!IS_ERR(clk))
+ clk = __of_clk_get_by_name(dev-of_node, con_id);
+ if (!IS_ERR(clk)) {
+#if defined(CONFIG_COMMON_CLK)
+ clk = __clk_create_clk(__clk_get_hw(clk), dev_id,
con_id);
+#endif
And we do it here where we could remove the #ifdef.
return clk;
+ }
if (PTR_ERR(clk) == -EPROBE_DEFER)
return clk;
}
--
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: [GIT PULL 2/3] omap clean-up for v3.20
On Fri, Jan 16, 2015 at 03:21:21PM -0800, Tony Lindgren wrote: The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/cleanup-pt1 for you to fetch changes up to ca662ee7b8a85c54c1cb9ef34b7c6b4f67933a7e: ARM: OMAP2+: Remove unused ti81xx platform init code (2015-01-14 17:21:00 -0800) Clean-up for omaps to remove dead code found with cppcheck after we've made several SoCs to boot in device tree only mode. Rickard Strandqvist (10): ARM: OMAP2+: clkt2xxx_apll.c: Remove some unused functions ARM: OMAP2+: cm33xx.c: Remove some unused functions ARM: OMAP2+: dpll44xx.c: Remove unused function ARM: OMAP2+: omap_hwmod.c: Remove some unused functions ARM: OMAP2+: powerdomain.c: Remove some unused functions ARM: OMAP2+: voltage: Remove some unused functions ARM: OMAP2+: omap-pm-noop.c: Remove some unused functions ARM: OMAP1: irq.c: Remove unused function ARM: OMAP1: timer32k.c: Remove unused function ARM: OMAP: dma.c: Remove unused function Tero Kristo (3): ARM: OMAP2: clock: remove unused apll code ARM: OMAP2: CM: remove unused PLL functions ARM: OMAP3+: PRM: remove prm_get_reset_sources declaration from headers Tony Lindgren (1): ARM: OMAP2+: Remove unused ti81xx platform init code arch/arm/mach-omap1/irq.c | 5 - arch/arm/mach-omap1/timer32k.c | 5 - arch/arm/mach-omap2/Makefile| 1 - arch/arm/mach-omap2/cclock3xxx_data.c | 6 +- arch/arm/mach-omap2/clkt2xxx_apll.c | 142 --- arch/arm/mach-omap2/clock.h | 1 - arch/arm/mach-omap2/clock2xxx.h | 11 -- arch/arm/mach-omap2/cm2xxx.c| 10 -- arch/arm/mach-omap2/cm2xxx.h| 2 - arch/arm/mach-omap2/cm33xx.c| 21 --- arch/arm/mach-omap2/dpll44xx.c | 20 --- arch/arm/mach-omap2/omap-pm-noop.c | 196 --- arch/arm/mach-omap2/omap-pm.h | 192 -- arch/arm/mach-omap2/omap_hwmod.c| 232 arch/arm/mach-omap2/omap_hwmod.h| 16 --- arch/arm/mach-omap2/omap_phy_internal.c | 35 - arch/arm/mach-omap2/powerdomain.c | 82 --- arch/arm/mach-omap2/powerdomain.h | 5 - arch/arm/mach-omap2/prm3xxx.h | 1 - arch/arm/mach-omap2/prm44xx_54xx.h | 1 - arch/arm/mach-omap2/usb-musb.c | 12 +- arch/arm/mach-omap2/usb.h | 2 - arch/arm/mach-omap2/voltage.c | 110 --- arch/arm/mach-omap2/voltage.h | 13 -- arch/arm/plat-omap/dma.c| 8 -- 25 files changed, 3 insertions(+), 1126 deletions(-) delete mode 100644 arch/arm/mach-omap2/clkt2xxx_apll.c Nice diffstat. Merged. -Olof -- 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: [GIT PULL 1/3] omap non-urgent fixes for v3.20
On Fri, Jan 16, 2015 at 03:21:20PM -0800, Tony Lindgren wrote: The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/fixes-not-urgent-pt1 for you to fetch changes up to 13efcb188984f69e1f97b4d9e7d3663fb782946f: ARM: OMAP2+: Disable omap3 PM init for ti81xx (2015-01-14 17:37:16 -0800) Non-urgent fixes for omap variant dm816x that has been in a sorry broken half merged state for a few years now. This gets us to the point where we can boot it properly once the related SoC data is added. Note that we've already made dm816x device tree only by removing the known broken board file. Tony Lindgren (6): ARM: OMAP2+: Fix error handling for omap2_clk_enable_init_clocks ARM: OMAP2+: Fix ti81xx devtype ARM: OMAP2+: Fix ti81xx class type ARM: OMAP2+: Fix dm814 and dm816 for clocks and timer init ARM: OMAP2+: Fix reboot for 81xx ARM: OMAP2+: Disable omap3 PM init for ti81xx Merged, thanks. -Olof -- 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: [GIT PULL 3/3] omap device tree changes for v3.20
On Fri, Jan 16, 2015 at 03:21:22PM -0800, Tony Lindgren wrote: The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.20/dt-pt1 for you to fetch changes up to 7300bfff886a1340cfeb252035303e265cd556d9: ARM: dts: omap3-gta04: Add handling for tv output (2015-01-13 08:02:21 -0800) Device tree changes for omaps. Mostly to add support for new am437x-idk and update am437x-sk boards. Also enabling new devices for multiple boards. Merged, thanks. -Olof -- 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
[GIT PULL] ARM: OMAP2+: hwmod: first set of patches for v3.20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.20/omap-hwmod-a for you to fetch changes up to 1c7e36bfc3e2fb2df5e2d1989a4b6fb9055a0f9b: ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 (2015-01-20 18:12:17 -0700) - ARM: OMAP2+: hwmod: first set of patches for v3.20 First set of OMAP2+ hwmod patches for Linux v3.20. These are mostly fixes for warnings, although there's one DRA7xx patch that fixes CONFIG_DEBUG_LL for AM572x/DRA7xx SoCs that use UART3 for console, such as the BeagleBoard-X15. These patches entered Linux-next starting with the next-20150121 tag. Basic build, boot, and PM test results can be found here: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v3.20/20150121142621/ - Keerthy (1): ARM: OMAP: DRA7: hwmod: Make gpmc software supervised as the smart idle is broken Lokesh Vutla (2): ARM: OMAP2+: hwmod: print error if wait_target_ready() failed ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 Paul Walmsley (1): MAINTAINERS: add maintainer for OMAP hwmod data Tomi Valkeinen (1): ARM: AM43xx: hwmod: set DSS submodule parent hwmods MAINTAINERS| 6 ++ arch/arm/mach-omap2/omap_hwmod.c | 4 ++-- arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 2 ++ arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 5 +++-- 4 files changed, 13 insertions(+), 4 deletions(-) vmlinux object size (delta in bytes from test_v3.19-rc1 (97bf6af1f928216fd6c5a66e8a57bfa95a659672)): text data bsstotal kernel 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only 0000 multi_v7_defconfig 0000 omap2plus_defconfig 0000 omap2plus_defconfig_2430sdp_only +6400 +64 omap2plus_defconfig_am33xx_only 0000 omap2plus_defconfig_am43xx_only 0000 omap2plus_defconfig_cpupm 0000 omap2plus_defconfig_dra7xx_only +3200 +32 omap2plus_defconfig_n800_multi_omap2xxx 0000 omap2plus_defconfig_n800_only_a 0000 omap2plus_defconfig_no_pm 0000 omap2plus_defconfig_omap2_4_only 0000 omap2plus_defconfig_omap3_4_only 0000 omap2plus_defconfig_omap5_only +560 -560 rmk_omap3430_ldp_allnoconfig 0000 rmk_omap3430_ldp_oldconfig +640 -640 rmk_omap4430_sdp_allnoconfig 0000 rmk_omap4430_sdp_oldconfig -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUwDhJAAoJEMePsQ0LvSpLFWsP/38ZfGOlOOex0JDaZSm/tTK2 WP+0RICxClIKFbvi9YHMW5yrrpEEcp7BZmcWsBf6SmJJs8HTzLjulRepz25gwPCw JC0qReQHpHOXIqcIKaJKEP1z0FlXArUF0xInLVRvVObcHKVJ+yuG2vk7Fs6tdZVw K7JS9x/6ZU5gZ7DMpTVuY5cuNcXaiuTb9tmKWrcXCNTneN30rpRq4g6R8kp5hSgI PR4dCkUpEnkgPfuuLUjSNDtIwGHwulgd85O+6gr6uxOvJR3bEHfYP0jvc9XMuBnY /Qy5KvfNjjeItfcBVgZSLusnmFXKFMApPnYJfyaikH9agoy5QFpFdMgS5syLJ5lQ ZCLTqg71UC3sycxZGGgPqddzI+rfHH/0QboonW0+LIhB0VTgA64wH2CIoz0nfmSs rixWz0+5cS2DaxvXRD98+1T3F1MB6wVmJr8IZaPkHT1G9FnsKNsqGd6Qk76ItdMf 8MdFxR0qEjZGK0djOyRiAvXkk2g4o3JE/MBT557eH1oHasaHiyABHqgXxEDFrtXy /gLYUNYSHvyirFERHF0Ub4xamNNPe6WIqu68/o0yq7HxECiOmji83SpK6NfhPgPW mAZxOhHtF67f68sa+nyZV5W9CeQTb23wcmEo9esqARh0IasM7x+mzbxVcemCN9AY RoP0xFh/ncaBH8vv9E// =wq+i -END PGP SIGNATURE- -- 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 v11 3/4] clk: Add rate constraints to clocks
On 01/21, Tomeu Vizoso wrote:
Adds a way for clock consumers to set maximum and minimum rates. This
can be used for thermal drivers to set minimum rates, or by misc.
drivers to set maximum rates to assure a minimum performance level.
Changes the signature of the determine_rate callback by adding the
parameters min_rate and max_rate.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
v11: * Recalculate the rate before putting the reference to clk_core
* Don't recalculate the rate when freeing the per-user clock
in the initialization error paths
* Move __clk_create_clk to be next to __clk_free_clk for more
comfortable reading
Can we do this in the previous patch where we introduce the
function?
@@ -2143,9 +2314,16 @@ struct clk *__clk_register(struct device *dev, struct
clk_hw *hw)
else
clk-owner = NULL;
+ INIT_HLIST_HEAD(clk-clks);
+
+ hw-clk = __clk_create_clk(hw, NULL, NULL);
+
ret = __clk_init(dev, hw-clk);
- if (ret)
+ if (ret) {
+ __clk_free_clk(hw-clk);
+ hw-clk = NULL;
return ERR_PTR(ret);
+ }
return hw-clk;
}
@@ -2210,12 +2388,16 @@ struct clk *clk_register(struct device *dev, struct
clk_hw *hw)
}
}
+ INIT_HLIST_HEAD(clk-clks);
+
hw-clk = __clk_create_clk(hw, NULL, NULL);
ret = __clk_init(dev, hw-clk);
if (!ret)
return hw-clk;
- kfree(hw-clk);
+ __clk_free_clk(hw-clk);
+ hw-clk = NULL;
Shouldn't we be assigning to NULL in the previous patch (same
comment for __clk_register)?
fail_parent_names_copy:
while (--i = 0)
kfree(clk-parent_names[i]);
@@ -2420,7 +2602,14 @@ void __clk_put(struct clk *clk)
if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
return;
+ clk_prepare_lock();
+ hlist_del(clk-child_node);
+ clk_prepare_unlock();
+
+ clk_core_set_rate(clk-core, clk-core-req_rate);
+
clk_core_put(clk-core);
+
Sad that we take the lock 3 times during __clk_put(). We should
be able to do it only once if we have a lockless
clk_core_set_rate() function and put the contents of
clk_core_put() into this function. Actually we need to do that to
be thread safe with clk-core-req_rate changing. We can call the
same function in clk_set_rate_range() too so that we don't have
to deal with recursive locking there.
kfree(clk);
}
--
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 4/4] ARM: dts: Add minimal support for dm8168-evm
On 19 January 2015 at 18:29, Tony Lindgren t...@atomide.com wrote: Hmm I sort of got the idea that dm814x and dm816x were done about the same time. Are you saying dm814x was actually done after dm816x? Well, it's hard to come up with an alternate explanation of netra's FAPLLs showing up in the terminology of centaurus' clock tree (though the amount of references to them in the TRM decreased over time) without the FAPLLs being there themselves. Of course a radical new design will have much more distance between initial development and public release than a derivative design. An interesting timeline is given by looking at JTAG partcodes, since those obviously have to be assigned somewhere during development, before the first silicon is produced (omap3/4/5 and centauroids listed): b6d6 - omap34xx 1.0 b7ae - omap34xx/35xx 2.x/3.x b81e - netra b852 - omap4430 1.0 b868 - am35xx b891 - omap36xx / dm/am37xx b8f2 - centaurus b942 - omap5430 b944 - subarctic b94e - omap4460 b95c - omap4430 2.x b96b - centaurus eve (dmva3/4 / dm38x) b975 - omap4470 b98c - aegis b990 - vayu b998 - omap5432 (The distance between the two omap543x variants suggests to me the ID is assigned early in the development, with the 5432-variant added late in the design, but that's just a guess.) Yeah this davinci_emac vs cpsw stuff is messy and I noticed too that the registers are different. BTW, if you spot any piece of the documentation making it sound like port 2 is special somehow, it means port 0 instead. (The host port was port 2 in CPSW in some earlier devices, and iirc a reference to this was still somewhere in the current docs) There's also an interesting Security Subsystem, which houses the crypto accelerators (2x AES, 2x Hash, DES, PKA, RNG), an SDMA engine, 128 KB + 16 KB of local RAM, a cortex-M3, some timers for its benefit, irq routing, and an elaborate L3 firewall instance covering both external and internal access. Hmm that's a lot of accelerators.. And there are gaps in the memory map suggesting maybe there were more submodules in earlier versions. I know it differs from Netra's security subsystem since one module offset is different... hmm, now I'm curious. I'll see if I can find a moment to brush the dust off the evm816x here and make a quick inventory. The DES module and second AES module in subarctic's memory map (and PRCM) appear to be ghost modules, but I'd suspect this means they are present on Aegis. Makes sense in combo with its magstripe card reader. BTW, someone found genuine documentation of the AES/DES/Hash accelerators: http://e2e.ti.com/support/arm/sitara_arm/f/791/p/291816/1399868#1399868 [random thought] There's another interesting application of the SecSS cortex-M3: on GP devices it is (afaict) the only processor with MReqDomain=1, while this is zero for all others. This 3-bit identifier is used for security partitioning, and is something you can test on in all firewalls. It is also the connID for EDMA's integrated memory protection and proxied by EDMA transfers. The processor is also located in the ALWON power domain. This puts the secM3 in a unique position to act as device hypervisor and prevent processors and DMA engines from meddling with hardware resources they aren't supposed to meddle with. Even if security isn't a concern, this would be a good idea for the same reason memory protection is useful to separate processes. With so many initiators around, if one accidently does a bogus write and clobbers someone else's state, the resulting failure is obviously rather hard to debug. -- 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: [GIT PULL] ARM: OMAP2+: hwmod: first set of patches for v3.20
* Paul Walmsley p...@pwsan.com [150121 15:42]: Hi Tony The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.20/omap-hwmod-a for you to fetch changes up to 1c7e36bfc3e2fb2df5e2d1989a4b6fb9055a0f9b: ARM: DRA7: hwmod: Fix boot crash with DEBUG_LL enabled on UART3 (2015-01-20 18:12:17 -0700) ARM: OMAP2+: hwmod: first set of patches for v3.20 First set of OMAP2+ hwmod patches for Linux v3.20. These are mostly fixes for warnings, although there's one DRA7xx patch that fixes CONFIG_DEBUG_LL for AM572x/DRA7xx SoCs that use UART3 for console, such as the BeagleBoard-X15. These patches entered Linux-next starting with the next-20150121 tag. Basic build, boot, and PM test results can be found here: http://www.pwsan.com/omap/testlogs/omap-hwmod-a-for-v3.20/20150121142621/ Thanks pulling into omap-for-v3.20/fixes-not-urgent. 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/3] ARM: edma: Split up header file to platform_data and API file
Hi,
On Thu, Nov 27, 2014 at 2:41 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
include/linux/platform_data/ is not a correct place to keep the API
definitions for edma, it is meant to be only for the pdata for the device.
Clean up this by moving the API to include/linux/edma.h
It's a nice net improvement, but it moves some things that should be
in _neither_ location to a new place where it doesn't belong either --
and the new location is even more global. See below.
...
diff --git a/include/linux/edma.h b/include/linux/edma.h
new file mode 100644
index ..9df92198c117
--- /dev/null
+++ b/include/linux/edma.h
@@ -0,0 +1,153 @@
+/*
+ * TI EDMA definitions
+ *
+ * Copyright (C) 2006-2013 Texas Instruments.
+ *
+ * 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.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * This EDMA3 programming framework exposes two basic kinds of resource:
+ *
+ * ChannelTriggers transfers, usually from a hardware event but
+ * also manually or by chaining from DMA completions.
+ * Each channel is coupled to a Parameter RAM (PaRAM) slot.
+ *
+ * Slot Each PaRAM slot holds a DMA transfer descriptor (PaRAM
+ * set), source and destination addresses, a link to a
+ * next PaRAM slot (if any), options for the transfer, and
+ * instructions for updating those addresses. There are
+ * more than twice as many slots as event channels.
+ *
+ * Each PaRAM set describes a sequence of transfers, either for one large
+ * buffer or for several discontiguous smaller buffers. An EDMA transfer
+ * is driven only from a channel, which performs the transfers specified
+ * in its PaRAM slot until there are no more transfers. When that last
+ * transfer completes, the link field may be used to reload the channel's
+ * PaRAM slot with a new transfer descriptor.
+ *
+ * The EDMA Channel Controller (CC) maps requests from channels into physical
+ * Transfer Controller (TC) requests when the channel triggers (by hardware
+ * or software events, or by chaining). The two physical DMA channels
provided
+ * by the TCs are thus shared by many logical channels.
+ *
+ * DaVinci hardware also has a QDMA mechanism which is not currently
+ * supported through this interface. (DSP firmware uses it though.)
+ */
+
+#ifndef __LINUX_EDMA_H_
+#define __LINUX_EDMA_H_
+
+#include linux/platform_data/edma.h
+
+/* PaRAM slots are laid out like this */
+struct edmacc_param {
+ u32 opt;
+ u32 src;
+ u32 a_b_cnt;
+ u32 dst;
+ u32 src_dst_bidx;
+ u32 link_bcntrld;
+ u32 src_dst_cidx;
+ u32 ccnt;
+} __packed;
+
+/* fields in edmacc_param.opt */
+#define SAMBIT(0)
+#define DAMBIT(1)
+#define SYNCDIMBIT(2)
+#define STATIC BIT(3)
+#define EDMA_FWID (0x07 8)
+#define TCCMODEBIT(11)
+#define EDMA_TCC(t)((t) 12)
+#define TCINTENBIT(20)
+#define ITCINTEN BIT(21)
+#define TCCHEN BIT(22)
+#define ITCCHENBIT(23)
This seems like the kind of thing that should go with the edma driver
instead of being globally exported to the kernel through a
include/linux header file.
-Olof
--
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 v4 13/21] ARM: omap: convert wakeupgen to stacked domains
* santosh shilimkar santosh.shilim...@oracle.com [150121 13:31]: On 1/21/2015 12:43 PM, Tony Lindgren wrote: * santosh shilimkar santosh.shilim...@oracle.com [150121 12:16]: TWD is useless on this machine since single core and TWD as know die in low power states. All the broadcast stuff is for SMP machines. Hmm it seems we should still use TWD during runtime and swich over to the gptimer for idle states for wake-up events. Well timer wheel code don't support it so if you are serious, some one needs to do that. For me, it is not worth at all. You will have more to loose than gain with these time switching schemes since you have to keep 2 times alive, do switching, loose the idle time. All of that is to save few CPU cycles since TWD is closer compared to other SOC timer. Anyways I will let you fight it out but IIRC, I had a discussion a while back with tglx in one of the conference and the conclusion was it not worth doing. Rather TWD hardware on SOC should be made wakeup capable and then everything is good. Till you have support, using TWD on AM43XX will break CPUIDLE. Not sure if it is supported or some one cares about it. Just keep that aspect in mind. Yes sure I'm aware of this. It should be easy to profile the speed gain to see if it would make much of a difference before starting to tinker with that. The way I think it's possible to do would be to copy the TWD timer value to a wake-up capable gptimer before hitting any deeper idle state. Of course some aux timer support might be still needed :) 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] bluetooth: Add hci_h4p driver
On Wednesday 21 January 2015 12:01:31 Pavel Machek wrote: Strange, where do you see DOS style line breaks? Checkpatch here does not warn about that, and they really should not be there. If that would be the only pieces, then I would have fixed it already. That is not the big deal. The rest of checkpatch is what I am not going to fix for you. I can fix the checkpatch, but I'd like to understand how ^Ms got there, because otherwise it will happen again. IIRC lines in email according to RFC2822 specification must be delimited by CRLF. Maybe this is reason? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] bluetooth: Add hci_h4p driver
Hi!
Speaking about formatting, could you properly format your emails, that
is inserting newline after ~78 columns, to make them easier to reply
to?
or you get an email client that can handle that part.
My email client is configured ok. Your is not. You are speaking on
public mailing list, so you should follow the rules.
Strange, where do you see DOS style line breaks? Checkpatch here does
not warn about that, and they really should not be there.
If that would be the only pieces, then I would have fixed it already. That is
not the big deal. The rest of checkpatch is what I am not going to fix for
you.
I can fix the checkpatch, but I'd like to understand how ^Ms got
there, because otherwise it will happen again.
Yeah, so first patch was too good for staging, and I would be allowed
to clean it up in tree, and now you run checkpatch --strict,
complaining about very serious stuff such as blank lines before }.
The network subsystem requires the --strict option.
Please stop complaining about staging. The patch went in, it was ignored for
month and multiple kernel release and it got removed. Deal with it.
Yes. It took me one 7 months to set up development environment. You
decided you don't like staging, so you made sure it does not work for
me -- by removing the driver. Thus, I had not only cleanups to do, but
also resulting bitrot. And now, because you don't like staging, are
making sure that I'll have to deal with bitrot and device tree at the
same time.
The indentations ones need to be fixed.
Ok, done.
Also this worries me:
WARNING: DT compatible string brcm,uart,bcm2048 appears un-documented --
check ./Documentation/devicetree/bindings/
#1222: FILE: drivers/bluetooth/nokia_core.c:1129:
+ { .compatible = brcm,uart,bcm2048 },
Yes, that wories me, too. It is one of reasons I wanted this to be
merged to staging. Arguing about right bindings will take some time.
Then that needs to be figured out. It is not that I have mentioned DT for the
first time. I said that right from the beginning.
From the beginning of the second try. I'll try to figure it out with
the dt people.
I can fix the checkpatch stuff that makes sense. That does not include
uglyfying code just for checkpatch. Can you then take the patch, as
you promised, and let me argue the bindings, and the other stuff that
needs to be fixed?
If not, can we agree that the driver in staging should be reverted, as
Greg promised would be easy, and I can clean it up there?
I am refusing to allow this into staging. Get this into shape for
drivers/bluetooth/ or keep the driver external.
After all the work that gone into the driver, you could at least state
the reason. I guess I have demonstrated by now that someone cares
about the driver.
For the record, reason I want it in the staging is that I don't want
driver to bitrot while dt people do their bikeshed discussion.
Regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
On Tuesday 20 January 2015 09:34 PM, Lee Jones wrote:
On Tue, 20 Jan 2015, R, Vignesh wrote:
On 1/20/2015 5:23 PM, Lee Jones wrote:
On Wed, 07 Jan 2015, Vignesh R wrote:
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer should not be busy executing any of the
config steps except for the charge step. Previously charge step was 1 ADC
clock cycle and hence it was ignored.
TSC steps are always disabled at the end of each conversion cycle, hence
there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
Signed-off-by: Vignesh R vigne...@ti.com
---
v5:
- Remove unnecessary clearing of REG_SE
drivers/mfd/ti_am335x_tscadc.c | 13 +
include/linux/mfd/ti_am335x_tscadc.h | 1 +
2 files changed, 6 insertions(+), 8 deletions(-)
Looks fine.
For my own reference:
Acked-by: Lee Jones lee.jo...@linaro.org
Can this patch be applied on its own?
I prefer to wait until input patches are picked up.
I have no problem with that, but is there a technical reason why?
Nothing, in particular. This patch alone has no impact on the
performance of TSC/ADC unit. Patch 2/6 is necessary to observe the
changes caused by this series. Hence, please wait until those patches
are picked up.
diff --git a/drivers/mfd/ti_am335x_tscadc.c
b/drivers/mfd/ti_am335x_tscadc.c
index 467c80e1c4ae..e4e4b22eebc9 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
DEFINE_WAIT(wait);
u32 reg;
- /*
- * disable TSC steps so it does not run while the ADC is using it. If
- * write 0 while it is running (it just started or was already running)
- * then it completes all steps that were enabled and stops then.
- */
- tscadc_writel(tsadc, REG_SE, 0);
reg = tscadc_readl(tsadc, REG_ADCFSM);
if (reg SEQ_STATUS) {
tsadc-adc_waiting = true;
@@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
spin_lock_irq(tsadc-reg_lock);
finish_wait(tsadc-reg_se_wait, wait);
+ /*
+ * Sequencer should either be idle or
+ * busy applying the charge step.
+ */
reg = tscadc_readl(tsadc, REG_ADCFSM);
- WARN_ON(reg SEQ_STATUS);
+ WARN_ON((reg SEQ_STATUS) !(reg CHARGE_STEP));
tsadc-adc_waiting = false;
}
tsadc-adc_in_use = true;
@@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
{
spin_lock_irq(tsadc-reg_lock);
- tsadc-reg_se_cache |= val;
am335x_tscadc_need_adc(tsadc);
tscadc_writel(tsadc, REG_SE, val);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index 3f4e994ace2b..1fd50dcfe47c 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -128,6 +128,7 @@
/* Sequencer Status */
#define SEQ_STATUS BIT(5)
+#define CHARGE_STEP 0x11
#define ADC_CLK 300
#define TOTAL_STEPS 16
--
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-20150119]regression (mm)?
2015-01-20 15:05 GMT+01:00 Kirill A. Shutemov kirill.shute...@linux.intel.com: Russell King - ARM Linux wrote: On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: Better option would be converting 2-lvl ARM configuration to asm-generic/pgtable-nopmd.h, but I'm not sure if it's possible. Well, IMHO the folded approach in asm-generic was done the wrong way which barred ARM from ever using it. Okay, I see. Regarding the topic bug. Completely untested patch is below. Could anybody check if it helps? From 34b9182d08ef2b541829e305fcc91ef1d26b27ea Mon Sep 17 00:00:00 2001 From: Kirill A. Shutemov kirill.shute...@linux.intel.com Date: Tue, 20 Jan 2015 15:47:22 +0200 Subject: [PATCH] arm: define __PAGETABLE_PMD_FOLDED for !LPAE ARM uses custom implementation of PMD folding in 2-level page table case. Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is folded, but ARM doesn't do this. Let's fix it. Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). It also fixes problems with recently-introduced pmd accounting on ARM without LPAE. Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com Reported-by: Nishanth Menon n...@ti.com --- arch/arm/include/asm/pgtable-2level.h | 2 ++ 1 file changed, 2 insertions(+) Helps for this issue on Exynos 4412 (Trats2) and Exynos 5420 (Arndale Octa): Tested-by: Krzysztof Kozlowski k.kozlow...@samsung.com Off-topic: Using smp_processor_id() in preemptible still screams [1] [1] https://lkml.org/lkml/2015/1/20/162 Best regards, Krzysztof -- 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 v2 3/5] usb: dwc3: Add quirk for Synopsis device disconnection errata
Hi Felipe:
Thanks for reviewing these,
2015-01-19 22:50 GMT+08:00 Felipe Balbi ba...@ti.com:
Hi,
On Mon, Jan 19, 2015 at 03:56:47PM +0800, Sneeker Yeh wrote:
Synopsis Designware USB3 IP earlier than v3.00a which is configured in
silicon
with DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, would need a specific quirk to
prevent
xhci host controller from dying when device is disconnected.
Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP configuration whose state
cannot be checked from software in runtime, it has to be enabled via platform
data or device tree.
Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
Documentation/devicetree/bindings/usb/dwc3.txt | 17 +
drivers/usb/dwc3/core.c|6 ++
drivers/usb/dwc3/core.h|1 +
drivers/usb/dwc3/host.c|4
drivers/usb/dwc3/platform_data.h |1 +
5 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt
b/Documentation/devicetree/bindings/usb/dwc3.txt
index cd7f045..1b78b29 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -37,6 +37,23 @@ Optional properties:
- snps,is-utmi-l1-suspend: true when DWC3 asserts output signal
utmi_l1_suspend_n, false when asserts utmi_sleep_n
- snps,hird-threshold: HIRD threshold
+ - snps,has_suspend_on_disconnect: true when IP is configured in silicon
with
+ DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, it can inject a
+ specific quirk to prevent xhci host controller from
+ dying when usb device is disconnected from root hub.
+ Since DWC_USB3_SUSPEND_ON_DISCONNECT_EN is an IP
+ configuration whose state cannot be checked from
+ software in runtime, it has to be enabled via platform
+ data or device tree.
+
+ xhci host dying symptom here is caused by that
+ DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1
+ configuration makes IP auto-suspended after PORTCSC is
+ cleared when usb device detached, then an asynchronous
+ disconnection procedure might fail using endpoint
+ command that suspened IP won't have any response to.
+
+ this issue is fixed when IP version = 3.00a.
This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 25ddc39..fbceab1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -838,6 +838,9 @@ static int dwc3_probe(struct platform_device *pdev)
snps,tx_de_emphasis_quirk);
of_property_read_u8(node, snps,tx_de_emphasis,
tx_de_emphasis);
+
+ dwc-suspend_on_disconnect_quirk = of_property_read_bool(node,
+ snps,has_suspend_on_disconnect);
} else if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
dwc-has_lpm_erratum = pdata-has_lpm_erratum;
@@ -864,6 +867,9 @@ static int dwc3_probe(struct platform_device *pdev)
dwc-tx_de_emphasis_quirk = pdata-tx_de_emphasis_quirk;
if (pdata-tx_de_emphasis)
tx_de_emphasis = pdata-tx_de_emphasis;
+
+ dwc-suspend_on_disconnect_quirk =
+ pdata-has_suspend_on_disconnect;
}
/* default to superspeed if no maximum_speed passed */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 8090249..d7458ff 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -832,6 +832,7 @@ struct dwc3 {
unsignedtx_de_emphasis_quirk:1;
unsignedtx_de_emphasis:2;
+ unsignedsuspend_on_disconnect_quirk:1;
you're missing the comment on the structure and these should be
alphabetically sorted.
okay, I see, I'll change it like this:
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -692,6 +692,9 @@ struct dwc3_scratchpad_array {
* @resize_fifos: tells us it's ok to reconfigure our TxFIFO sizes.
* @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
* @start_config_issued: true when StartConfig command has been issued
+ * @suspend_on_disconnect_quirk: set if core was configured with
+ * DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. Note that there's
+ * now way for software to detect this in runtime.
* @three_stage_setup: set if we perform a three phase setup
* @disable_scramble_quirk: set if we enable the disable scramble quirk
* @u2exit_lfps_quirk: set if we enable u2exit lfps quirk
@@ -818,6 +821,7 @@ struct dwc3 {
Re: [PATCH v2 4/5] xhci: Platform: Set Synopsis device disconnection quirk based on platform data
hi,
2015-01-19 22:51 GMT+08:00 Felipe Balbi ba...@ti.com:
On Mon, Jan 19, 2015 at 03:56:48PM +0800, Sneeker Yeh wrote:
If an xhci platform has Synopsis device disconnection errata then enable
XHCI_DISCONNECT_QUIRK quirk flag.
Signed-off-by: Sneeker Yeh sneeker@tw.fujitsu.com
---
drivers/usb/host/xhci-plat.c |3 +++
include/linux/usb/xhci_pdriver.h |4
2 files changed, 7 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 08d402b..40beb95 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -147,6 +147,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
if ((node of_property_read_bool(node, usb3-lpm-capable)) ||
(pdata pdata-usb3_lpm_capable))
xhci-quirks |= XHCI_LPM_SUPPORT;
+
+ if (pdata pdata-delay_portcsc_clear)
+ xhci-quirks |= XHCI_DISCONNECT_QUIRK;
/*
* Set the xHCI pointer before xhci_plat_setup() (aka
hcd_driver.reset)
* is called by usb_add_hcd().
diff --git a/include/linux/usb/xhci_pdriver.h
b/include/linux/usb/xhci_pdriver.h
index 376654b..a37a3a5 100644
--- a/include/linux/usb/xhci_pdriver.h
+++ b/include/linux/usb/xhci_pdriver.h
@@ -18,10 +18,14 @@
*
* @usb3_lpm_capable:determines if this xhci platform supports USB3
* LPM capability
+ * @delay_portcsc_clear: determines if Synopsis USB3 core has errata in
+ * DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1 hardware
+ * configuration.
*
*/
struct usb_xhci_pdata {
unsignedusb3_lpm_capable:1;
+ unsigneddelay_portcsc_clear:1;
previous patch won't build before this is applied. That's a problem.
Please shuffle things around so that each and every patch builds and
works on its own.
We cannot break bisectability ;-)
Ah...sorry I seem to make a mess here,
i'll re-arrange all patches next round.
Much appreciate,
Sneeker
--
balbi
--
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 v2 2/5] usb: dwc3: add revision number DWC3_REVISION_300A
hi, 2015-01-20 4:00 GMT+08:00 Felipe Balbi ba...@ti.com: On Mon, Jan 19, 2015 at 07:45:31PM +, John Youn wrote: -Original Message- From: Felipe Balbi [mailto:ba...@ti.com] Sent: Monday, January 19, 2015 6:47 AM looking at Synopsys Solvnet for this IP, it shows that current version is 2.90a. There's no 3.00a. Paul, John, is there a 3.00a version of the DWC USB3 IP ? Yes there is, but it has not been released yet, thus it's not in Solvnet. alright, in that case, Sneeker, can you update this patch to add 2.90a and 3.00a macros ? Sure, I'll also add 2.90a in next round, Thanks, and much appreciate, Sneeker Thanks -- balbi -- 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-20150119]regression (mm)?
On 01/20/2015 04:05 PM, Kirill A. Shutemov wrote: Russell King - ARM Linux wrote: On Tue, Jan 20, 2015 at 02:16:43AM +0200, Kirill A. Shutemov wrote: Better option would be converting 2-lvl ARM configuration to asm-generic/pgtable-nopmd.h, but I'm not sure if it's possible. Well, IMHO the folded approach in asm-generic was done the wrong way which barred ARM from ever using it. Okay, I see. Regarding the topic bug. Completely untested patch is below. Could anybody check if it helps? From 34b9182d08ef2b541829e305fcc91ef1d26b27ea Mon Sep 17 00:00:00 2001 From: Kirill A. Shutemov kirill.shute...@linux.intel.com Date: Tue, 20 Jan 2015 15:47:22 +0200 Subject: [PATCH] arm: define __PAGETABLE_PMD_FOLDED for !LPAE ARM uses custom implementation of PMD folding in 2-level page table case. Generic code expects to see __PAGETABLE_PMD_FOLDED to be defined if PMD is folded, but ARM doesn't do this. Let's fix it. Defining __PAGETABLE_PMD_FOLDED will drop out unused __pmd_alloc(). It also fixes problems with recently-introduced pmd accounting on ARM without LPAE. Signed-off-by: Kirill A. Shutemov kirill.shute...@linux.intel.com Reported-by: Nishanth Menon n...@ti.com --- arch/arm/include/asm/pgtable-2level.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h index bcc5e300413f..bfd662e49a25 100644 --- a/arch/arm/include/asm/pgtable-2level.h +++ b/arch/arm/include/asm/pgtable-2level.h @@ -10,6 +10,8 @@ #ifndef _ASM_PGTABLE_2LEVEL_H #define _ASM_PGTABLE_2LEVEL_H +#define __PAGETABLE_PMD_FOLDED + /* * Hardware-wise, we have a two level page table structure, where the first * level has 4096 entries, and the second level has 256 entries. Each entry Among other boards I have my daVinci board (OMAP-L138-EVM) boots fine with this patch. Tested-by: Peter Ujfalusi peter.ujfal...@ti.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: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Tue, Jan 20, 2015 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: How about default to Linux id space and allow overriding that with a module param option if needed? I'm not sure I'm following. If the main point of contention is the base_id field, I'm also fine with removing it entirely, as I'm not aware of any actual user for it (Suman please confirm?). Mark? Rob? Will you accept Suman's patches if the base_id field is removed? Thanks, Ohad. -- 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 v11 3/4] clk: Add rate constraints to clocks
Adds a way for clock consumers to set maximum and minimum rates. This
can be used for thermal drivers to set minimum rates, or by misc.
drivers to set maximum rates to assure a minimum performance level.
Changes the signature of the determine_rate callback by adding the
parameters min_rate and max_rate.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
v11:* Recalculate the rate before putting the reference to clk_core
* Don't recalculate the rate when freeing the per-user clock
in the initialization error paths
* Move __clk_create_clk to be next to __clk_free_clk for more
comfortable reading
v10:* Refactor __clk_determine_rate to share code with
clk_round_rate.
* Remove clk_core_round_rate_nolock as it's unused now
v9: * s/floor/min and s/ceiling/max
* Add a bunch of NULL checks
* Propagate our rate range when querying our parent for the rate
* Take constraints into account in clk_round_rate
* Add __clk_determine_rate() for clk providers to ask their
parents for a rate within their range
* Make sure that what ops-round_rate returns when changing
rates is within the range
v7: * Update a few more instances in new code
v6: * Take the prepare lock before removing a per-user clk
* Init per-user clks list before adding the first clk
* Pass the constraints to determine_rate and let clk
implementations deal with constraints
* Add clk_set_rate_range
v5: * Initialize clk.ceiling_constraint to ULONG_MAX
* Warn about inconsistent constraints
v4: * Copy function docs from header
* Move WARN out of critical section
* Refresh rate after removing a per-user clk
* Rename clk_core.per_user_clks to clk_core.clks
* Store requested rate and re-apply it when constraints are updated
---
Documentation/clk.txt | 2 +
arch/arm/mach-omap2/dpll3xxx.c | 2 +
arch/arm/mach-omap2/dpll44xx.c | 2 +
arch/mips/alchemy/common/clock.c| 8 +
drivers/clk/at91/clk-programmable.c | 2 +
drivers/clk/bcm/clk-kona.c | 2 +
drivers/clk/clk-composite.c | 9 +-
drivers/clk/clk.c | 285
drivers/clk/hisilicon/clk-hi3620.c | 2 +
drivers/clk/mmp/clk-mix.c | 2 +
drivers/clk/qcom/clk-pll.c | 1 +
drivers/clk/qcom/clk-rcg.c | 10 +-
drivers/clk/qcom/clk-rcg2.c | 6 +
drivers/clk/sunxi/clk-factors.c | 2 +
drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +
include/linux/clk-private.h | 6 +
include/linux/clk-provider.h| 15 +-
include/linux/clk.h | 28
include/linux/clk/ti.h | 4 +
19 files changed, 325 insertions(+), 65 deletions(-)
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 4ff8462..0e4f90a 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -73,6 +73,8 @@ the operations defined in clk.h:
unsigned long *parent_rate);
long(*determine_rate)(struct clk_hw *hw,
unsigned long rate,
+ unsigned long min_rate,
+ unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw
**best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index);
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index c2da2a0..ac3fb11 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -473,6 +473,8 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
* in failure.
*/
long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long min_rate,
+ unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk)
{
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 0e58e5a..acacb90 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -222,6 +222,8 @@ out:
* in failure.
*/
long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long min_rate,
+ unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk)
{
diff --git a/arch/mips/alchemy/common/clock.c b/arch/mips/alchemy/common/clock.c
index 48a9dfc..4e65404 100644
---
Re: [PATCH] ti-soc-thermal: implement eocz bit to make driver useful on omap3
On Sun, Jan 18, 2015 at 09:18:21PM +0100, Pavel Machek wrote: Hi! Ok, what do you suggest? AFAICT, without MODE_CONFIG, continuous ADC mode is not available, so we have to force it periodically, so this should be correct. I will have a better look and let you know. for now, adding a single read should not hurt ( but I will double check) Any news there? I believe it is OK to keep your code the way you posted. Thanks. + if (ret) + return ret; + } + spin_lock(bgp-lock); temp = ti_bandgap_read_temp(bgp, id); spin_unlock(bgp-lock); - ret |= ti_bandgap_adc_to_mcelsius(bgp, temp, temp); + ret = ti_bandgap_adc_to_mcelsius(bgp, temp, temp); this one should be part of your clean up patch Ok, can you apply the cleanup patch and I'll prepare one on the top of it? I mean, you should resend the cleanup patch including the above '|=' removal, as you are already doing in the cleanup patch. Ok, little patch-editing can not hurt :-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
[PATCH v11 2/4] clk: Make clk API return per-user struct clk instances
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
v11:* Allow for clk_set_parent to be called with a NULL parent
v10:* Add more missing NULL checks
* Remove __clk_reparent as it's now unused
* Remove clk_core_round_rate as it's now unused
* Call nolock variants from __clk_mux_determine_rate
v9: * Add missing NULL checks
* Remove __clk_prepare and __clk_unprepare as they are unused
now
v7: * Add stub for __of_clk_get_by_name to fix builds without OF
v6: * Guard against NULL pointer
v4: * Remove unused function __clk_core_to_clk
* Use core more often as the name for struct clk_core* variables
* Make sure we don't lose information about the caller in of_clk_get_*
v3: * Rebase on top of linux-next 20141009
v2: * Remove exported functions that aren't really used outside clk.c
* Rename new internal functions to clk_core_ prefix
* Remove redundant checks for error pointers in *_get_parent
* Change __clk_create_clk to take a struct clk_hw instead
* Match the original error behavior in clk_get_sys
---
arch/arm/mach-omap2/cclock3xxx_data.c | 108 --
arch/arm/mach-omap2/clock.h | 11 +-
arch/arm/mach-omap2/clock_common_data.c | 5 +-
drivers/clk/clk.c | 628
drivers/clk/clk.h | 5 +
drivers/clk/clkdev.c| 80 +++-
include/linux/clk-private.h | 35 +-
include/linux/clk-provider.h| 12 +-
8 files changed, 583 insertions(+), 301 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 644ff32..4305105 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -82,7 +82,7 @@ DEFINE_CLK_MUX(osc_sys_ck, osc_sys_ck_parent_names, NULL, 0x0,
OMAP3430_PRM_CLKSEL, OMAP3430_SYS_CLKIN_SEL_SHIFT,
OMAP3430_SYS_CLKIN_SEL_WIDTH, 0x0, NULL);
-DEFINE_CLK_DIVIDER(sys_ck, osc_sys_ck, osc_sys_ck, 0x0,
+DEFINE_CLK_DIVIDER(sys_ck, osc_sys_ck, osc_sys_ck_core, 0x0,
OMAP3430_PRM_CLKSRC_CTRL, OMAP_SYSCLKDIV_SHIFT,
OMAP_SYSCLKDIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
@@ -132,7 +132,7 @@ static struct clk_hw_omap dpll3_ck_hw = {
DEFINE_STRUCT_CLK(dpll3_ck, dpll3_ck_parent_names, dpll3_ck_ops);
-DEFINE_CLK_DIVIDER(dpll3_m2_ck, dpll3_ck, dpll3_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll3_m2_ck, dpll3_ck, dpll3_ck_core, 0x0,
OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
OMAP3430_CORE_DPLL_CLKOUT_DIV_SHIFT,
OMAP3430_CORE_DPLL_CLKOUT_DIV_WIDTH,
@@ -149,12 +149,12 @@ static const struct clk_ops core_ck_ops = {};
DEFINE_STRUCT_CLK_HW_OMAP(core_ck, NULL);
DEFINE_STRUCT_CLK(core_ck, core_ck_parent_names, core_ck_ops);
-DEFINE_CLK_DIVIDER(l3_ick, core_ck, core_ck, 0x0,
+DEFINE_CLK_DIVIDER(l3_ick, core_ck, core_ck_core, 0x0,
OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
OMAP3430_CLKSEL_L3_SHIFT, OMAP3430_CLKSEL_L3_WIDTH,
CLK_DIVIDER_ONE_BASED, NULL);
-DEFINE_CLK_DIVIDER(l4_ick, l3_ick, l3_ick, 0x0,
+DEFINE_CLK_DIVIDER(l4_ick, l3_ick, l3_ick_core, 0x0,
OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
OMAP3430_CLKSEL_L4_SHIFT, OMAP3430_CLKSEL_L4_WIDTH,
CLK_DIVIDER_ONE_BASED, NULL);
@@ -275,9 +275,9 @@ static struct clk_hw_omap dpll1_ck_hw = {
DEFINE_STRUCT_CLK(dpll1_ck, dpll3_ck_parent_names, dpll1_ck_ops);
-DEFINE_CLK_FIXED_FACTOR(dpll1_x2_ck, dpll1_ck, dpll1_ck, 0x0, 2, 1);
+DEFINE_CLK_FIXED_FACTOR(dpll1_x2_ck, dpll1_ck, dpll1_ck_core, 0x0, 2, 1);
-DEFINE_CLK_DIVIDER(dpll1_x2m2_ck, dpll1_x2_ck, dpll1_x2_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll1_x2m2_ck, dpll1_x2_ck, dpll1_x2_ck_core, 0x0,
OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKSEL2_PLL),
OMAP3430_MPU_DPLL_CLKOUT_DIV_SHIFT,
OMAP3430_MPU_DPLL_CLKOUT_DIV_WIDTH,
@@ -292,7 +292,7 @@ static const char *mpu_ck_parent_names[] = {
DEFINE_STRUCT_CLK_HW_OMAP(mpu_ck, mpu_clkdm);
DEFINE_STRUCT_CLK(mpu_ck, mpu_ck_parent_names, core_l4_ick_ops);
-DEFINE_CLK_DIVIDER(arm_fck, mpu_ck, mpu_ck, 0x0,
+DEFINE_CLK_DIVIDER(arm_fck, mpu_ck, mpu_ck_core, 0x0,
OMAP_CM_REGADDR(MPU_MOD,
