* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Mark Brown @ 2012-10-30 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030172513.GA3993@arwen.pp.htv.fi>
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register here.
> fair enough. I see your point. Not saying I agree though, just that this
> discussion has been flying for far too long, so feel free to provide
> patches implementing what you're defending here ;-)
> Guess code will speak for itself. On way or another, we need OMAP keypad
> driver working in mainline and I don't think your arguments are strong
> enough to keep $SUBJECT from being merged, unless you can provide
> something stable/tested for v3.8 merge window.
Ship me an OMAP5 system and I might see what I can do :)
More seriously the amount of time we seem to have been spending recently
on changes which end up requiring us to go through essentially every
driver and add code to them (often several times) doesn't seem like
we're doing a good job here. pinctrl is really noticable because it's
new but it's not the only thing. As a subsystem maintainer this code
just makes me want to add new subsystem features to pull the code out of
drivers but obviously that's not something that should be being done at
the subsystem level.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/650651d2/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] irqchip: Move ARM VIC to drivers/irqchip
From: Stephen Warren @ 2012-10-30 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351608860-24617-3-git-send-email-robherring2@gmail.com>
On 10/30/2012 08:54 AM, Rob Herring wrote:
> From: Rob Herring <rob.herring@calxeda.com>
>
> Now that we have drivers/irqchip, move VIC irqchip to drivers/irqchip.
> diff --git a/arch/arm/common/vic.c b/drivers/irqchip/irq-vic.c
> similarity index 100%
> rename from arch/arm/common/vic.c
> rename to drivers/irqchip/irq-vic.c
"gic" and "vic" seems a little generic for filenames and symbol names;
what about irq-arm-vic.c and irq-arm-gic.c? Similarly...
> diff --git a/drivers/irqchip/irqchip.h b/drivers/irqchip/irqchip.h
> int gic_of_init(struct device_node *node, struct device_node *parent);
> +int vic_of_init(struct device_node *node, struct device_node *parent);
... perhaps rename those to arm_[gv]ic_of_init()?
Are/will there be multiple versions of the GIC? I guess we can always
introduce a GIC2 later if needed, and leave the current one with an
unversioned name.
^ permalink raw reply
* [PATCH V4 3/3] clocksource: time-armada-370-xp converted to clk framework
From: Gregory CLEMENT @ 2012-10-30 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351621413-3637-1-git-send-email-gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
cc: John Stultz <johnstul@us.ibm.com>
---
arch/arm/boot/dts/armada-370-db.dts | 4 ----
arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
drivers/clocksource/time-armada-370-xp.c | 11 ++++++-----
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370-db.dts b/arch/arm/boot/dts/armada-370-db.dts
index fffd5c2..4a31b03 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -34,9 +34,5 @@
clock-frequency = <200000000>;
status = "okay";
};
- timer at d0020300 {
- clock-frequency = <600000000>;
- status = "okay";
- };
};
};
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi b/arch/arm/boot/dts/armada-370-xp.dtsi
index 16cc82c..94b4b9e 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -62,6 +62,7 @@
compatible = "marvell,armada-370-xp-timer";
reg = <0xd0020300 0x30>;
interrupts = <37>, <38>, <39>, <40>;
+ clocks = <&coreclk 2>;
};
addr-decoding at d0020000 {
diff --git a/drivers/clocksource/time-armada-370-xp.c b/drivers/clocksource/time-armada-370-xp.c
index 4674f94..a4605fd 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -18,6 +18,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/kernel.h>
+#include <linux/clk.h>
#include <linux/timer.h>
#include <linux/clockchips.h>
#include <linux/interrupt.h>
@@ -167,7 +168,6 @@ void __init armada_370_xp_timer_init(void)
u32 u;
struct device_node *np;
unsigned int timer_clk;
- int ret;
np = of_find_compatible_node(NULL, NULL, "marvell,armada-370-xp-timer");
timer_base = of_iomap(np, 0);
WARN_ON(!timer_base);
@@ -179,13 +179,14 @@ void __init armada_370_xp_timer_init(void)
timer_base + TIMER_CTRL_OFF);
timer_clk = 25000000;
} else {
- u32 clk = 0;
- ret = of_property_read_u32(np, "clock-frequency", &clk);
- WARN_ON(!clk || ret < 0);
+ unsigned long rate = 0;
+ struct clk *clk = of_clk_get(np, 0);
+ WARN_ON(IS_ERR(clk));
+ rate = clk_get_rate(clk);
u = readl(timer_base + TIMER_CTRL_OFF);
writel(u & ~(TIMER0_25MHZ | TIMER1_25MHZ),
timer_base + TIMER_CTRL_OFF);
- timer_clk = clk / TIMER_DIVIDER;
+ timer_clk = rate / TIMER_DIVIDER;
}
/* We use timer 0 as clocksource, and timer 1 for
--
1.7.9.5
^ permalink raw reply related
* [PATCH V4 2/3] clk: armada-370-xp: add support for clock framework
From: Gregory CLEMENT @ 2012-10-30 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351621413-3637-1-git-send-email-gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-370.dtsi | 12 +++++++++
arch/arm/boot/dts/armada-xp.dtsi | 48 +++++++++++++++++++++++++++++++++++
arch/arm/mach-mvebu/Kconfig | 5 ++++
arch/arm/mach-mvebu/armada-370-xp.c | 8 +++++-
arch/arm/mach-mvebu/common.h | 1 +
5 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index 2069151..ac495b4 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -75,5 +75,17 @@
#interrupts-cells = <2>;
interrupts = <91>;
};
+ coreclk: mvebu-sar at d0018230 {
+ #clock-cells = <1>;
+ reg = <0xd0018230 0x08>;
+ compatible = "marvell,armada-370-core-clockctrl";
+ clock-output-names =
+ "tclk", /* 0 */
+ "pclk", /* 1 */
+ "nbclk", /* 2 */
+ "hclk", /* 3 */
+ "dramclk"; /* 4 */
+ };
+
};
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 71d6b5d..8fd924a 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -27,6 +27,35 @@
<0xd0021870 0x58>;
};
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ compatible = "marvell,sheeva-v7";
+ reg = <0>;
+ clocks = <&cpuclk 0>;
+ };
+
+ cpu at 1 {
+ compatible = "marvell,sheeva-v7";
+ reg = <1>;
+ clocks = <&cpuclk 1>;
+ };
+
+ cpu at 2 {
+ compatible = "marvell,sheeva-v7";
+ reg = <2>;
+ clocks = <&cpuclk 2>;
+ };
+
+ cpu at 3 {
+ compatible = "marvell,sheeva-v7";
+ reg = <3>;
+ clocks = <&cpuclk 3>;
+ };
+ };
+
soc {
serial at d0012200 {
compatible = "ns16550";
@@ -47,6 +76,25 @@
marvell,timer-25Mhz;
};
+ coreclk: mvebu-sar at d0018230 {
+ #clock-cells = <1>;
+ reg = <0xd0018230 0x08>;
+ compatible = "marvell,armada-xp-core-clockctrl";
+ clock-output-names =
+ "tclk", /* 0 */
+ "pclk", /* 1 */
+ "nbclk", /* 2 */
+ "hclk", /* 3 */
+ "dramclk"; /* 4 */
+ };
+
+ cpuclk: clock-complex at d0018700 {
+ #clock-cells = <1>;
+ compatible = "marvell,armada-xp-cpu-clockctrl";
+ reg = <0xd0018700 0xA0>;
+ clocks = <&coreclk 1>;
+ };
+
system-controller at d0018200 {
compatible = "marvell,armada-370-xp-system-controller";
reg = <0xd0018200 0x500>;
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 416d46e..17d246b 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -9,11 +9,16 @@ config ARCH_MVEBU
select PINCTRL
select PLAT_ORION
select SPARSE_IRQ
+ select CLKDEV_LOOKUP
+ select MVEBU_CLK_CPU
if ARCH_MVEBU
menu "Marvell SOC with device tree"
+config MVEBU_CLK_CPU
+ bool
+
config MACH_ARMADA_370_XP
bool
select ARMADA_370_XP_TIMER
diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 49d7915..2af6ce5 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -37,8 +37,14 @@ void __init armada_370_xp_map_io(void)
iotable_init(armada_370_xp_io_desc, ARRAY_SIZE(armada_370_xp_io_desc));
}
+void __init armada_370_xp_timer_and_clk_init(void)
+{
+ mvebu_clocks_init();
+ armada_370_xp_timer_init();
+}
+
struct sys_timer armada_370_xp_timer = {
- .init = armada_370_xp_timer_init,
+ .init = armada_370_xp_timer_and_clk_init,
};
static void __init armada_370_xp_dt_init(void)
diff --git a/arch/arm/mach-mvebu/common.h b/arch/arm/mach-mvebu/common.h
index 02f89ea..281fab3 100644
--- a/arch/arm/mach-mvebu/common.h
+++ b/arch/arm/mach-mvebu/common.h
@@ -16,6 +16,7 @@
#define __ARCH_MVEBU_COMMON_H
void mvebu_restart(char mode, const char *cmd);
+void mvebu_clocks_init(void);
void armada_370_xp_init_irq(void);
void armada_370_xp_handle_irq(struct pt_regs *regs);
--
1.7.9.5
^ permalink raw reply related
* [PATCH V4 1/3] clk: mvebu: add armada-370-xp specific clocks
From: Gregory CLEMENT @ 2012-10-30 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351621413-3637-1-git-send-email-gregory.clement@free-electrons.com>
Add Armada 370/XP specific clocks: core clocks and CPU clocks.
The CPU clocks are only for Armada XP for the SMP mode.
The core clocks are clocks which have their rate set during reset. The
code was written with the other SoCs of the mvebu family in
mind. Adding them should be pretty straight forward. For a new
SoC, only 3 binding have to be added:
- one to provide the tclk frequency
- one to provde the pclk frequency
- and one to provide the ratio between the pclk and the children
clocks
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
.../devicetree/bindings/clock/mvebu-core-clock.txt | 40 +++
.../devicetree/bindings/clock/mvebu-cpu-clock.txt | 21 ++
drivers/clk/Makefile | 1 +
drivers/clk/mvebu/Makefile | 2 +
drivers/clk/mvebu/clk-core.c | 318 ++++++++++++++++++++
drivers/clk/mvebu/clk-core.h | 19 ++
drivers/clk/mvebu/clk-cpu.c | 154 ++++++++++
drivers/clk/mvebu/clk-cpu.h | 19 ++
drivers/clk/mvebu/clk.c | 36 +++
9 files changed, 610 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
create mode 100644 drivers/clk/mvebu/Makefile
create mode 100644 drivers/clk/mvebu/clk-core.c
create mode 100644 drivers/clk/mvebu/clk-core.h
create mode 100644 drivers/clk/mvebu/clk-cpu.c
create mode 100644 drivers/clk/mvebu/clk-cpu.h
create mode 100644 drivers/clk/mvebu/clk.c
diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
new file mode 100644
index 0000000..eb54c62
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for core clock of Marvell EBU platforms
+
+This is the binding for the "core" clock of the mvebu SoCs, the rate
+of this clocks are fixed during reset. Their value or ratio are taken
+from the Sample at Reset(SAR) register.
+
+Required properties:
+- compatible : shall be one of the following:
+ "marvell,armada-370-core-clockctrl" - core clock for Armada 370
+ "marvell,armada-xp-core-clockctrl" - core clock for Armada XP
+- reg : Address and length of the SAR register set
+- #clock-cells : should be set to 1.
+- clock-output-names: A list of clock output names that mvebu core
+ clocks provides. The full list of all valid clock names, IDs and
+ description are below.
+ Name ID Description
+ tclk 0 Peripheral clock
+ pclk 1 CPU clock
+ nbclk 2 L2 clock
+ hclk 3 DRAM control clock
+ dramclk 4 DDR clock
+
+coreclk: mvebu-sar at d0018230 {
+ #clock-cells = <1>;
+ reg = <0xd0018230 0x08>;
+ compatible = "marvell,armada-370-core-clockctrl";
+ clock-output-names =
+ "tclk", /* 0 */
+ "pclk", /* 1 */
+ "nbclk", /* 2 */
+ "hclk", /* 3 */
+ "dramclk"; /* 4 */
+};
+
+timer at d0020300 {
+ compatible = "marvell,armada-370-xp-timer";
+ reg = <0xd0020300 0x30>;
+ interrupts = <37>, <38>, <39>, <40>;
+ clocks = <&coreclk 0>;
+};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
new file mode 100644
index 0000000..1fb5a64
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -0,0 +1,21 @@
+Device Tree Clock bindings for cpu clock of Marvell EBU platforms
+
+Required properties:
+- compatible : shall be one of the following:
+ "marvell,armada-xp-cpu-clockctrl" - cpu clocks for Armada XP
+- reg : Address and length of the clock complex register set
+- #clock-cells : should be set to 1.
+- clocks : shall be the input parent clock phandle for the clock.
+
+cpuclk: clock-complex at d0018700 {
+ #clock-cells = <1>;
+ compatible = "marvell,armada-xp-cpu-clockctrl";
+ reg = <0xd0018700 0xA0>;
+ clocks = <&coreclk 1>;
+}
+
+cpu at 0 {
+ compatible = "marvell,sheeva-v7";
+ reg = <0>;
+ clocks = <&cpuclk 0>;
+};
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 71a25b9..9c91d6c 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_PLAT_SPEAR) += spear/
obj-$(CONFIG_ARCH_U300) += clk-u300.o
obj-$(CONFIG_COMMON_CLK_VERSATILE) += versatile/
obj-$(CONFIG_ARCH_PRIMA2) += clk-prima2.o
+obj-$(CONFIG_ARCH_MVEBU) += mvebu/
ifeq ($(CONFIG_COMMON_CLK), y)
obj-$(CONFIG_ARCH_MMP) += mmp/
endif
diff --git a/drivers/clk/mvebu/Makefile b/drivers/clk/mvebu/Makefile
new file mode 100644
index 0000000..de94a87
--- /dev/null
+++ b/drivers/clk/mvebu/Makefile
@@ -0,0 +1,2 @@
+obj-y += clk.o clk-core.o
+obj-$(CONFIG_MVEBU_CLK_CPU) += clk-cpu.o
diff --git a/drivers/clk/mvebu/clk-core.c b/drivers/clk/mvebu/clk-core.c
new file mode 100644
index 0000000..d51dc1f
--- /dev/null
+++ b/drivers/clk/mvebu/clk-core.c
@@ -0,0 +1,318 @@
+/*
+ * Marvell EBU clock core handling defined at reset
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/of.h>
+
+/*
+ * Sample At Reset is a 64 bit bitfiled split in two register of 32
+ * bits
+ */
+
+#define SARL 0 /* Low part [0:31] */
+#define SARL_AXP_PCLK_FREQ_OPT 21
+#define SARL_AXP_PCLK_FREQ_OPT_MASK 0x7
+#define SARL_A370_PCLK_FREQ_OPT 11
+#define SARL_A370_PCLK_FREQ_OPT_MASK 0xF
+#define SARL_AXP_FAB_FREQ_OPT 24
+#define SARL_AXP_FAB_FREQ_OPT_MASK 0xF
+#define SARL_A370_FAB_FREQ_OPT 15
+#define SARL_A370_FAB_FREQ_OPT_MASK 0x1F
+#define SARL_A370_TCLK_FREQ_OPT 20
+#define SARL_A370_TCLK_FREQ_OPT_MASK 0x1
+#define SARH 4 /* High part [32:63] */
+#define SARH_AXP_PCLK_FREQ_OPT (52-32)
+#define SARH_AXP_PCLK_FREQ_OPT_MASK 0x1
+#define SARH_AXP_PCLK_FREQ_OPT_SHIFT 3
+#define SARH_AXP_FAB_FREQ_OPT (51-32)
+#define SARH_AXP_FAB_FREQ_OPT_MASK 0x1
+#define SARH_AXP_FAB_FREQ_OPT_SHIFT 4
+
+u32 *sar_reg;
+int sar_reg_size;
+
+enum core_clk {
+ tclk, pclk, nbclk, hclk, dramclk, clk_max
+};
+
+struct core_clk_fn {
+ u32(*get_tclk_freq) (void);
+ u32(*get_pck_freq) (void);
+ const int *(*get_fab_freq_opt) (void);
+};
+
+/*
+ * Ratio between VCO and each of the member in the following order:
+ * CPU clock, L2 clock, DRAM controler clock, DDR clcok
+ */
+
+static const int reset_core_ratio[32][4] = {
+ [0x01] = {1, 2, 2, 2},
+ [0x02] = {2, 2, 6, 3},
+ [0x03] = {2, 2, 3, 3},
+ [0x04] = {1, 2, 3, 3},
+ [0x05] = {1, 2, 4, 2},
+ [0x06] = {1, 1, 2, 2},
+ [0x07] = {2, 3, 6, 6},
+ [0x09] = {1, 2, 6, 3},
+ [0x0A] = {2, 4, 10, 5},
+ [0x0C] = {1, 2, 4, 4},
+ [0x0F] = {2, 2, 5, 5},
+ [0x13] = {1, 1, 2, 1},
+ [0x14] = {2, 3, 6, 3},
+ [0x1B] = {1, 1, 1, 1},
+};
+
+static struct clk *clks[clk_max];
+
+static struct clk_onecell_data clk_data;
+
+/* Frequency in MHz*/
+static u32 armada_370_pclk[] = { 400, 533, 667, 800, 1000, 1067, 1200 };
+
+static u32 armada_xp_pclk[] = { 1000, 1066, 1200, 1333, 1500, 1666,
+ 1800, 2000, 667, 0, 800, 1600
+};
+
+static u32 armada_370_tclk[] = { 166, 200 };
+
+static const int *__init armada_370_get_fab_freq_opt(void)
+{
+ u8 fab_freq_opt = 0;
+
+ fab_freq_opt = ((sar_reg[0] >> SARL_A370_FAB_FREQ_OPT) &
+ SARL_A370_FAB_FREQ_OPT_MASK);
+
+ if (reset_core_ratio[fab_freq_opt][0] == 0)
+ return NULL;
+ else
+ return reset_core_ratio[fab_freq_opt];
+}
+
+static u32 __init armada_370_get_pck_freq(void)
+{
+ u32 cpu_freq;
+ u8 cpu_freq_select = 0;
+
+ cpu_freq_select = ((sar_reg[0] >> SARL_A370_PCLK_FREQ_OPT) &
+ SARL_A370_PCLK_FREQ_OPT_MASK);
+ if (cpu_freq_select > ARRAY_SIZE(armada_370_pclk)) {
+ pr_err("CPU freq select unsuported %d\n", cpu_freq_select);
+ cpu_freq = 0;
+ } else
+ cpu_freq = armada_370_pclk[cpu_freq_select];
+
+ return cpu_freq * 1000 * 1000;
+}
+
+static u32 __init armada_370_get_tclk_freq(void)
+{
+ u32 tclk_freq;
+ u8 tclk_freq_select = 0;
+
+ tclk_freq_select = ((sar_reg[0] >> SARL_A370_TCLK_FREQ_OPT) &
+ SARL_A370_TCLK_FREQ_OPT_MASK);
+ if (tclk_freq_select > ARRAY_SIZE(armada_370_tclk)) {
+ pr_err("TCLK freq select unsuported %d\n", tclk_freq_select);
+ tclk_freq = 0;
+ } else
+ tclk_freq = armada_370_tclk[tclk_freq_select];
+
+ return tclk_freq * 1000 * 1000;
+}
+
+static const int *__init armada_xp_get_fab_freq_opt(void)
+{
+ u8 fab_freq_opt = 0;
+
+ fab_freq_opt = ((sar_reg[0] >> SARL_AXP_FAB_FREQ_OPT) &
+ SARL_AXP_FAB_FREQ_OPT_MASK);
+ /*
+ * The upper bit is not contiguous to the other ones and
+ * located in the high part of the SAR registers
+ */
+ fab_freq_opt |= (((sar_reg[1] >> SARH_AXP_FAB_FREQ_OPT) &
+ SARH_AXP_FAB_FREQ_OPT_MASK)
+ << SARH_AXP_FAB_FREQ_OPT_SHIFT);
+
+ if (reset_core_ratio[fab_freq_opt][0] == 0)
+ return NULL;
+ else
+ return reset_core_ratio[fab_freq_opt];
+}
+
+static u32 __init armada_xp_get_pck_freq(void)
+{
+ u32 cpu_freq;
+ u8 cpu_freq_select = 0;
+
+ cpu_freq_select = ((sar_reg[0] >> SARL_AXP_PCLK_FREQ_OPT) &
+ SARL_AXP_PCLK_FREQ_OPT_MASK);
+ /*
+ * The upper bit is not contiguous to the other ones and
+ * located in the high part of the SAR registers
+ */
+ cpu_freq_select |= (((sar_reg[1] >> SARH_AXP_PCLK_FREQ_OPT) &
+ SARH_AXP_PCLK_FREQ_OPT_MASK)
+ << SARH_AXP_PCLK_FREQ_OPT_SHIFT);
+ if (cpu_freq_select > ARRAY_SIZE(armada_xp_pclk)) {
+ pr_err("CPU freq select unsuported: %d\n", cpu_freq_select);
+ cpu_freq = 0;
+ } else
+ cpu_freq = armada_xp_pclk[cpu_freq_select];
+
+ return cpu_freq * 1000 * 1000;
+}
+
+/* For Armada XP TCLK frequency is fix: 250MHz */
+static u32 __init armada_xp_get_tclk_freq(void)
+{
+ return 250 * 1000 * 1000;
+}
+
+void __init of_core_clk_setup(struct device_node *node,
+ struct core_clk_fn clk_fn)
+{
+ struct clk *clk;
+ unsigned long rate;
+ const char *clk_name;
+ struct resource res;
+ void __iomem *sar_base;
+ int i;
+
+ if (sar_reg == NULL) {
+ if (of_address_to_resource(node, 0, &res))
+ goto err;
+
+ sar_reg_size = resource_size(&res);
+ sar_reg = kmalloc(sar_reg_size, GFP_KERNEL);
+
+ sar_base = ioremap(res.start, sar_reg_size);
+ if (sar_base == NULL)
+ goto err;
+ for (i = 0; i < sar_reg_size; i += sizeof(*sar_reg))
+ sar_reg[i] = readl(sar_base + i);
+
+ iounmap(sar_base);
+ }
+
+ /* clock 0 is tclk */
+ of_property_read_string_index(node, "clock-output-names", tclk,
+ &clk_name);
+ rate = clk_fn.get_tclk_freq();
+ if (rate != 0)
+ clk = clk_register_fixed_rate(NULL, clk_name, NULL,
+ CLK_IS_ROOT, rate);
+ else {
+ pr_err("Invalid freq for %s\n", clk_name);
+ return;
+ }
+
+ if (WARN_ON(IS_ERR(clk)))
+ return;
+ clks[tclk] = clk;
+
+ /* clock 1 is pclk */
+ of_property_read_string_index(node, "clock-output-names", pclk,
+ &clk_name);
+ rate = clk_fn.get_pck_freq();
+ if (rate != 0)
+ clk = clk_register_fixed_rate(NULL, clk_name, NULL,
+ CLK_IS_ROOT, rate);
+ else {
+ pr_err("Invalid freq for %s\n", clk_name);
+ return;
+ }
+ if (WARN_ON(IS_ERR(clk)))
+ return;
+ clks[pclk] = clk;
+
+ /*
+ * the clocks 2 to 4 are nbclk, hclk and dramclk and are all
+ * derivated from the clock 1: pclk
+ */
+
+ for (i = nbclk; i <= dramclk; i++) {
+ const int *ratio = clk_fn.get_fab_freq_opt();
+ const char *parent_clk_name;
+
+ of_property_read_string_index(node, "clock-output-names",
+ i, &clk_name);
+ of_property_read_string_index(node, "clock-output-names",
+ pclk, &parent_clk_name);
+
+ if (ratio != NULL)
+ clk = clk_register_fixed_factor(NULL, clk_name,
+ parent_clk_name, 0,
+ ratio[0],
+ ratio[i - nbclk + 1]);
+ else {
+ pr_err("Invalid clk ratio for %s\n", clk_name);
+ return;
+ }
+
+ if (WARN_ON(IS_ERR(clk)))
+ return;
+ clks[i] = clk;
+ }
+ clk_data.clk_num = ARRAY_SIZE(clks);
+ clk_data.clks = clks;
+ of_clk_add_provider(node, of_clk_src_onecell_get, &clk_data);
+ return;
+err:
+ pr_err("%s:SAR base adresse not set in DT\n", __func__);
+ return;
+
+}
+
+static struct core_clk_fn armada_370_clk_fn = {
+ .get_tclk_freq = armada_370_get_tclk_freq,
+ .get_pck_freq = armada_370_get_pck_freq,
+ .get_fab_freq_opt = armada_370_get_fab_freq_opt,
+};
+
+static struct core_clk_fn armada_xp_clk_fn = {
+ .get_tclk_freq = armada_xp_get_tclk_freq,
+ .get_pck_freq = armada_xp_get_pck_freq,
+ .get_fab_freq_opt = armada_xp_get_fab_freq_opt,
+};
+
+static const __initconst struct of_device_id clk_match[] = {
+ {
+ .compatible = "marvell,armada-370-core-clockctrl",
+ .data = &armada_370_clk_fn,
+ },
+ {
+ .compatible = "marvell,armada-xp-core-clockctrl",
+ .data = &armada_xp_clk_fn,
+ },
+ {
+ /* sentinel */
+ }
+};
+
+void __init mvebu_core_clocks_init(void)
+{
+ struct device_node *np;
+
+ for_each_matching_node(np, clk_match) {
+ const struct of_device_id *match = of_match_node(clk_match, np);
+ struct core_clk_fn *clk_fn = (struct core_clk_fn *)match->data;
+ of_core_clk_setup(np, *clk_fn);
+ }
+
+ return;
+}
diff --git a/drivers/clk/mvebu/clk-core.h b/drivers/clk/mvebu/clk-core.h
new file mode 100644
index 0000000..a04f80b
--- /dev/null
+++ b/drivers/clk/mvebu/clk-core.h
@@ -0,0 +1,19 @@
+/*
+ * * Marvell EBU clock core handling defined at reset
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MVEBU_CLK_CORE_H
+#define __MVEBU_CLK_CORE_H
+
+void __init of_core_clk_setup(struct device_node *node);
+void __init mvebu_core_clocks_init(void);
+
+#endif
diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
new file mode 100644
index 0000000..19ebc59
--- /dev/null
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -0,0 +1,154 @@
+/*
+ * Marvell MVEBU CPU clock handling.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/clkdev.h>
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/delay.h>
+
+#define SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET 0x0
+#define SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET 0xC
+#define SYS_CTRL_CLK_DIVIDER_MASK 0x3F
+
+#define MAX_CPU 4
+struct cpu_clk {
+ struct clk_hw hw;
+ int cpu;
+ const char *clk_name;
+ const char *parent_name;
+ void __iomem *reg_base;
+};
+
+static struct clk **clks;
+
+static struct clk_onecell_data clk_data;
+
+#define to_cpu_clk(p) container_of(p, struct cpu_clk, hw)
+
+static unsigned long clk_cpu_recalc_rate(struct clk_hw *hwclk,
+ unsigned long parent_rate)
+{
+ struct cpu_clk *cpuclk = to_cpu_clk(hwclk);
+ u32 reg, div;
+
+ reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET);
+ div = (reg >> (cpuclk->cpu * 8)) & SYS_CTRL_CLK_DIVIDER_MASK;
+ return parent_rate / div;
+}
+
+static long clk_cpu_round_rate(struct clk_hw *hwclk, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ /* Valid ratio are 1:1, 1:2 and 1:3 */
+ u32 div;
+
+ div = *parent_rate / rate;
+ if (div == 0)
+ div = 1;
+ else if (div > 3)
+ div = 3;
+
+ return *parent_rate / div;
+}
+
+static int clk_cpu_set_rate(struct clk_hw *hwclk, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct cpu_clk *cpuclk = to_cpu_clk(hwclk);
+ u32 reg, div;
+ u32 reload_mask;
+
+ div = parent_rate / rate;
+ reg = (readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET)
+ & (~(SYS_CTRL_CLK_DIVIDER_MASK << (cpuclk->cpu * 8))))
+ | (div << (cpuclk->cpu * 8));
+ writel(reg, cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_VALUE_OFFSET);
+ /* Set clock divider reload smooth bit mask */
+ reload_mask = 1 << (20 + cpuclk->cpu);
+
+ reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET)
+ | reload_mask;
+ writel(reg, cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+
+ /* Now trigger the clock update */
+ reg = readl(cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET)
+ | 1 << 24;
+ writel(reg, cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+
+ /* Wait for clocks to settle down then clear reload request */
+ udelay(1000);
+ reg &= ~(reload_mask | 1 << 24);
+ writel(reg, cpuclk->reg_base + SYS_CTRL_CLK_DIVIDER_CTRL_OFFSET);
+ udelay(1000);
+
+ return 0;
+}
+
+static const struct clk_ops cpu_ops = {
+ .recalc_rate = clk_cpu_recalc_rate,
+ .round_rate = clk_cpu_round_rate,
+ .set_rate = clk_cpu_set_rate,
+};
+
+void __init of_cpu_clk_setup(struct device_node *node)
+{
+ struct cpu_clk *cpuclk;
+ void __iomem *clock_complex_base = of_iomap(node, 0);
+ int cpu;
+ if (clock_complex_base == NULL) {
+ pr_err("%s: clock-complex base register not set\n",
+ __func__);
+ return;
+ }
+
+ cpuclk = kzalloc(MAX_CPU * sizeof(*cpuclk), GFP_KERNEL);
+ clks = kzalloc(MAX_CPU * sizeof(*clks), GFP_KERNEL);
+
+ if (WARN_ON(!cpuclk))
+ return;
+ for (cpu = 0; cpu < MAX_CPU; cpu++) {
+ struct clk_init_data init;
+ struct clk *clk;
+ struct clk *parent_clk;
+ char *clk_name = kzalloc(5, GFP_KERNEL);
+
+ sprintf(clk_name, "cpu%d", cpu);
+ parent_clk = of_clk_get(node, 0);
+
+ cpuclk[cpu].parent_name = __clk_get_name(parent_clk);
+ cpuclk[cpu].clk_name = clk_name;
+ cpuclk[cpu].cpu = cpu;
+ cpuclk[cpu].reg_base = clock_complex_base;
+ cpuclk[cpu].hw.init = &init;
+
+ init.name = cpuclk[cpu].clk_name;
+ init.ops = &cpu_ops;
+ init.flags = 0;
+ init.parent_names = &cpuclk[cpu].parent_name;
+ init.num_parents = 1;
+
+ clk = clk_register(NULL, &cpuclk[cpu].hw);
+ if (WARN_ON(IS_ERR(clk)))
+ goto bail_out;
+ clks[cpu] = clk;
+ }
+ clk_data.clk_num = MAX_CPU;
+ clk_data.clks = clks;
+ of_clk_add_provider(node, of_clk_src_onecell_get, &clk_data);
+
+ return;
+bail_out:
+ kfree(clks);
+ kfree(cpuclk);
+}
diff --git a/drivers/clk/mvebu/clk-cpu.h b/drivers/clk/mvebu/clk-cpu.h
new file mode 100644
index 0000000..5d28356
--- /dev/null
+++ b/drivers/clk/mvebu/clk-cpu.h
@@ -0,0 +1,19 @@
+/*
+ * Marvell MVEBU CPU clock handling.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#ifndef __MVEBU_CLK_CPU_H
+#define __MVEBU_CLK_CPU_H
+
+void __init of_cpu_clk_setup(struct device_node *node);
+void __init mvebu_cpu_clocks_init(void);
+
+#endif
diff --git a/drivers/clk/mvebu/clk.c b/drivers/clk/mvebu/clk.c
new file mode 100644
index 0000000..0864df7
--- /dev/null
+++ b/drivers/clk/mvebu/clk.c
@@ -0,0 +1,36 @@
+/*
+ * Marvell EBU SoC clock handling.
+ *
+ * Copyright (C) 2012 Marvell
+ *
+ * Gregory CLEMENT <gregory.clement@free-electrons.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/kernel.h>
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/of_address.h>
+#include <linux/of.h>
+#include "clk-cpu.h"
+#include "clk-core.h"
+
+static const __initconst struct of_device_id clk_match[] = {
+#ifdef CONFIG_MVEBU_CLK_CPU
+ {
+ .compatible = "marvell,armada-xp-cpu-clockctrl",
+ .data = of_cpu_clk_setup,
+ },
+#endif
+ {
+ /* sentinel */
+ }
+};
+
+void __init mvebu_clocks_init(void)
+{
+ mvebu_core_clocks_init();
+ of_clk_init(clk_match);
+}
--
1.7.9.5
^ permalink raw reply related
* [PATCH V4 0/3] Add clock framework for armada 370/XP
From: Gregory CLEMENT @ 2012-10-30 18:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello Mike,
I hope this 4th version will meet your expectations. Beside the
corrections you have asked I also changed the way I get resources for
the clocks. Instead of referring to a node name, now I refer to a
compatible name which should be a better use of the device tree.
Rather than taking this series in your git tree, would it possible to
give your ack to the patches and let Jason Cooper take the patch set
in his git tree. We have other series for mvebu which depend on this
one (SMP, HWIOCC and SATA for now and more to come), and it will be
easier for us to have everything in the same place.
The purpose of this patch set is to add support for clock framework
for Armada 370 and Armada XP SoCs. All the support is done under the
directory drivers/clk/mvebu/ as the support for other mvebu SoCs was
in mind during the writing of the code.
Two kinds of clocks are added:
- The CPU clocks are only for Armada XP (which is multi-core)
- The core clocks are clocks which have their rate fixed during
reset.
Many thanks to Thomas Petazzoni and Sebastian Hesselbarth for their
review and feedback. The device tree bindings were really improved
with the advices of Sebastian.
Changelog:
V3 -> V4
- Rebased on top of 3.7-rc3
- Replaced the whitespace by tab in the Documentation files
- Fixed the comment style according to the CodingStyle documentation
- Fixed incorrect indentation
- Removed redundant header in clk-cpu.c
- Replaced improper whitespace by tabs in armada-xp.dtsi
- In the device tree, the resources for the clocks do not rely anymore
on the node name mvebu-sar but now only depend on the compatible
name. (Issue reported by Sebastian Hesselbarth)
V2 -> V3:
- Rebased on top of v3.7-rc1
- Fixed a typo in device trees
- Fixed warning from checkpatch
V1 -> V2:
- Improved the spelling and the wording of the documentation and the
1st commit log
- Removed the "end_of_list" name which are unused here.
- Fix the cpu clock by using of_clk_src_onecell_get in the same way it
was used for the core clocks
Regards,
Gregory CLEMENT (3):
clk: mvebu: add armada-370-xp specific clocks
clk: armada-370-xp: add support for clock framework
clocksource: time-armada-370-xp converted to clk framework
.../devicetree/bindings/clock/mvebu-core-clock.txt | 40 +++
.../devicetree/bindings/clock/mvebu-cpu-clock.txt | 21 ++
arch/arm/boot/dts/armada-370-db.dts | 4 -
arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
arch/arm/boot/dts/armada-370.dtsi | 12 +
arch/arm/boot/dts/armada-xp.dtsi | 48 +++
arch/arm/mach-mvebu/Kconfig | 5 +
arch/arm/mach-mvebu/armada-370-xp.c | 8 +-
arch/arm/mach-mvebu/common.h | 1 +
drivers/clk/Makefile | 1 +
drivers/clk/mvebu/Makefile | 2 +
drivers/clk/mvebu/clk-core.c | 318 ++++++++++++++++++++
drivers/clk/mvebu/clk-core.h | 19 ++
drivers/clk/mvebu/clk-cpu.c | 154 ++++++++++
drivers/clk/mvebu/clk-cpu.h | 19 ++
drivers/clk/mvebu/clk.c | 36 +++
drivers/clocksource/time-armada-370-xp.c | 11 +-
17 files changed, 690 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
create mode 100644 drivers/clk/mvebu/Makefile
create mode 100644 drivers/clk/mvebu/clk-core.c
create mode 100644 drivers/clk/mvebu/clk-core.h
create mode 100644 drivers/clk/mvebu/clk-cpu.c
create mode 100644 drivers/clk/mvebu/clk-cpu.h
create mode 100644 drivers/clk/mvebu/clk.c
--
1.7.9.5
^ permalink raw reply
* [PATCH v3 06/10] net/macb: clean up ring buffer logic
From: Håvard Skinnemoen @ 2012-10-30 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B707D@saturn3.aculab.com>
On Tue, Oct 30, 2012 at 4:12 AM, David Laight <David.Laight@aculab.com> wrote:
>> Instead of masking head and tail every time we increment them, just let them
>> wrap through UINT_MAX and mask them when subscripting. Add simple accessor
>> functions to do the subscripting properly to minimize the chances of messing
>> this up.
> ...
>> +static unsigned int macb_tx_ring_avail(struct macb *bp)
>> +{
>> + return TX_RING_SIZE - (bp->tx_head - bp->tx_tail);
>> +}
>
> That one doesn't look quite right to me.
> Surely it should be masking with 'TX_RING_SIZE - 1'
Why is that? head and tail can never be more than TX_RING_SIZE apart,
so it shouldn't make any difference.
Havard
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Dmitry Torokhov @ 2012-10-30 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030172513.GA3993@arwen.pp.htv.fi>
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> >
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register here.
>
> fair enough. I see your point. Not saying I agree though, just that this
> discussion has been flying for far too long, so feel free to provide
> patches implementing what you're defending here ;-)
>
> Guess code will speak for itself. On way or another, we need OMAP keypad
> driver working in mainline
Are you saying that introducing pincrtl infrastructure actually _broke_
the driver in mainline?
Thanks.
--
Dmitry
^ permalink raw reply
* [RFC PATCH] dt: describe base reset signal binding
From: Stephen Warren @ 2012-10-30 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121029183233.18780.11964@nucleus>
On 10/29/2012 12:32 PM, Mike Turquette wrote:
> Quoting Stephen Warren (2012-10-23 14:45:56)
>> What do people think of this? Does it sound like a good idea to go ahead
>> with a reset subsystem? Should we simply add a new API to the common clock
>> subsystem instead (and assume that reset and clock domains match 1:1).
>> Should this be implemented as part of the generic power management domains;
>> see include/linux/pm_domain.h instead?
>>
>
> Hi Stephen,
>
> I'm not sure a "reset subsystem" is necessary, but I also do not like
> using clocks as the keys for IP reset.
I'm not sure what you're suggesting as an alternative to a reset
subsystem (or API if you want something that sounds smaller!) :-)
> I think it is more common to map IPs to struct device, no?
It is indeed probably common that there's a 1:1 mapping between IP
blocks and struct device. However, I'm sure there are plenty of
counter-examples; IP blocks with multiple reset domains (hence struct
devices that encompass multiple reset domains, or reset domains that
encompass multiple struct devices), just as there are many examples of
non-1:1 mappings between struct device and struct clk.
Even ignoring that, we'd still need to API say device_reset(struct
device *dev) or device_reset(struct device *dev, const char *conid)
wouldn't we? That's really all I meant by a reset subsystem.
An alternative here would be to simply move Tegra's
tegra_periph_reset_{de,}assert() function prototypes into a header in
include/linux rather than mach-tegra/include/mach. However, I imagine at
least some other SoC needs a similar API, so a common API might be useful?
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Tony Lindgren @ 2012-10-30 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030172707.GB3993@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [121030 10:34]:
> Hi,
>
> On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> > * Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> > > >
> > > > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > > > already submitted to the list recently. So MMC support will come along with
> > > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
> >
> > This is a bogus dependency, the MMC driver needs to also work
> > without DMA.
>
> heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
> 1869 host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
> 1870 if (!host->rx_chan) {
> 1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
> 1872 ret = -ENXIO;
> 1873 goto err_irq;
> 1874 }
> 1875
> 1876 host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
> 1877 if (!host->tx_chan) {
> 1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
> 1879 ret = -ENXIO;
> 1880 goto err_irq;
> 1881 }
>
> in fact, if DMAENGINE isn't enabled, this won't even compile due to
> omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
Regards,
Tony
^ permalink raw reply
* [PATCH v3 10/10] net/macb: add pinctrl consumer support
From: Joachim Eastwood @ 2012-10-30 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3269426bdd44debc00d027651f8248db9d40f3dc.1351591858.git.nicolas.ferre@atmel.com>
On 30 October 2012 11:18, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>
> If no pinctrl available just report a warning as some architecture may not
> need to do anything.
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> [nicolas.ferre at atmel.com: adapt the error path]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: netdev at vger.kernel.org
> ---
> drivers/net/ethernet/cadence/macb.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index 4d51877..eae3d74 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -26,6 +26,9 @@
> #include <linux/of.h>
> #include <linux/of_device.h>
> #include <linux/of_net.h>
> +#include <linux/of_gpio.h>
> +#include <linux/gpio.h>
Why are these two headers added?
I don't see anything from them used in the code added.
Wouldn't the pinctrl header by itself be sufficient?
> +#include <linux/pinctrl/consumer.h>
>
> #include "macb.h"
>
> @@ -1472,6 +1475,7 @@ static int __init macb_probe(struct platform_device *pdev)
> struct phy_device *phydev;
> u32 config;
> int err = -ENXIO;
> + struct pinctrl *pinctrl;
>
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!regs) {
> @@ -1479,6 +1483,15 @@ static int __init macb_probe(struct platform_device *pdev)
> goto err_out;
> }
>
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(pinctrl)) {
> + err = PTR_ERR(pinctrl);
> + if (err == -EPROBE_DEFER)
> + goto err_out;
> +
> + dev_warn(&pdev->dev, "No pinctrl provided\n");
> + }
> +
> err = -ENOMEM;
> dev = alloc_etherdev(sizeof(*bp));
> if (!dev)
> --
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH v3 00/10] net/macb: driver enhancement concerning GEM support, ring logic and cleanup
From: Joachim Eastwood @ 2012-10-30 17:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351591858.git.nicolas.ferre@atmel.com>
On 30 October 2012 11:17, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> This is an enhancement work that began several years ago. I try to catchup with
> some performance improvement that has been implemented then by Havard.
> The ring index logic and the TX error path modification are the biggest changes
> but some cleanup/debugging have been added along the way.
> The GEM revision will benefit from the Gigabit support.
> Newer pinctrl infrastructure support is added but it is optional.
>
> The series has been tested on several Atmel AT91 SoC with the two MACB/GEM
> flavors.
Gave the patch series a quick spin on RM9200 as well and the
at91_ether driver still works. Not many patches here that touch the
shared code though.
So FWIW;
Tested-by: Joachim Eastwood <manabian@gmail.com>
Note: Needed the patch you sent out (net/at91_ether: fix the use of
macb structure) to fix the build error on the struct rename.
regards
Joachim Eastwood
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Felipe Balbi @ 2012-10-30 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030162727.GG11908@atomide.com>
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
> * Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> > >
> > > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > > already submitted to the list recently. So MMC support will come along with
> > > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
>
> This is a bogus dependency, the MMC driver needs to also work
> without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
1869 host->rx_chan = dma_request_channel(mask, omap_dma_filter_fn, &rx_req);
1870 if (!host->rx_chan) {
1871 dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host->tx_chan = dma_request_channel(mask, omap_dma_filter_fn, &tx_req);
1877 if (!host->tx_chan) {
1878 dev_err(mmc_dev(host->mmc), "unable to obtain TX DMA engine channel %u\n", tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/7f91c9c3/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2 0/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
From: Sebastien Guiriec @ 2012-10-30 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351596296-13825-1-git-send-email-peter.ujfalusi@ti.com>
Hi Peter,
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:
> Hello,
>
> Changes since v1:
> - If the device does not have DMA resource do not try to recreate the resources
>
> Intro mail from v1:
>
> This series resolves the issue we currently have with the resource handling when
> booting with DT.
> In short: at the moment the omap_device_alloc() decides if it needs to update the
> OF filled resources based on the number of resources on the device and in the
> hwmod database.
> This prevents us from removing hwmod data for platforms (OMAP5) which does not
> support non DT boot anymore.
At list removing 160 lines for out of tree data for OMAP5 audio part. So
going in the good direction. But should much more after cleaning up all
IP. Now we need to add DMA binding to remove the data.
>
> With this series we can make sure that the DT provided resources are used and we
> only append the DMA resources to the device from hwmod.
> I have added extra check to prepare us when the DMA resource can be filled via
> OF. In this case we do not update the resources at all.
>
> Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure
> going to help us to clean up the OMAP5 hwmod database.
>
> Regards,
> Peter
> ---
> Peter Ujfalusi (2):
> ARM: OMAP: hwmod: Add possibility to count hwmod resources based on
> type
> ARM: OMAP: omap_device: Correct resource handling for DT boot
>
> arch/arm/mach-omap2/omap_hwmod.c | 27 +++++----
> arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
> arch/arm/plat-omap/omap_device.c | 87 ++++++++++++++++++----------
> 3 files changed, 72 insertions(+), 44 deletions(-)
>
Tested-by: Sebastien Guiriec <s-guiriec@ti.com>
^ permalink raw reply
* [PATCHv2] Input: omap4-keypad: Add pinctrl support
From: Felipe Balbi @ 2012-10-30 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030155821.GU4511@opensource.wolfsonmicro.com>
Hi,
On Tue, Oct 30, 2012 at 03:58:21PM +0000, Mark Brown wrote:
> > > > and this is one of the issues we're all trying to solve today so we have
> > > > single zImage approach for the ARM port.
>
> > > I don't see the relevance of single zImage here; device tree is supposed
> > > to solve that one.
>
> > DT is part of the deal. DT alone will solve nothing.
>
> If DT isn't relevant I'm not sure what you're saying about single
I didn't say DT is irrelevant. I said it's not the *only* thing.
> zImage? The only relevance I can see for that is the data and
> configuration bloating the kernel, something that DT is supposed to
> address - this is the main use case where DT has benefits.
>
> > > Well, nothing's going to stop that happening if people are determined
> > > enough - one could equally see that there'll be flags getting passed to
> > > control the ordering of calls if things are open coded. I would expect
> > > that with a power domain style approach any data would be being passed
> > > directly and bypassing the driver completely.
>
> > situations like that would be a lot more rare in open coded case, don't
> > you think ? Also a lot more local, since they will show up on a driver
> > source code which is used in a small set of use cases, instead of being
> > part of the pm domain implementation for the entire platform.
>
> I don't see how open coding helps prevent people doing silly things, it
> seems like it'd have at most neutral impact (and of course it does
> require going round all the drivers every time someone comes up with a
> new idea for doing things which is a bit tedious).
>
> > > Essentially all the patches I'm seeing adding pinctrl are totally
> > > mindless, most of them are just doing the initial setup on boot and not
> > > doing any active management at runtime at all.
>
> > have you considered that might be just a first step ? I have mentioned
> > this before. We first add the bare minimum and work on PM optimizations
> > later. You can be sure most likely those mindless patches you're seeing
> > are probably building blocks for upcoming patches adding sleep/idle
> > modes.
>
> The sleep/idle modes are just a basic extension of the same idea, I'd
> not anticipate much difference there (and indeed anything where pinmux
> power saving makes a meaningful impact will I suspect need to be using
> runtime PM to allow SoC wide power savings anyway).
>
> > > A big part of my point here is that it's not at all clear to me that it
> > > is the driver which knows what's going on. For SoC-specific IPs you can
> > > be confident about how the SoC integration looks but for IPs that get
> > > reused widely this becomes less true.
>
> > I don't think so. As long as we keep the meaning of the 'default'
> > pinctrl state to mean that this is the working state for the IP,
> > underlying pinctrl-$arch implementation should know how to set muxing up
> > properly, no ?
>
> But then this comes round to the mindless code that ought to be factored
> out :) Only the more interesting cases that do something unusual really
> register here.
fair enough. I see your point. Not saying I agree though, just that this
discussion has been flying for far too long, so feel free to provide
patches implementing what you're defending here ;-)
Guess code will speak for itself. On way or another, we need OMAP keypad
driver working in mainline and I don't think your arguments are strong
enough to keep $SUBJECT from being merged, unless you can provide
something stable/tested for v3.8 merge window.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121030/3ad44ef0/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] irqchip: Move ARM GIC to drivers/irqchip
From: Rob Herring @ 2012-10-30 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508FFADC.3080506@gmail.com>
On 10/30/2012 11:05 AM, Rob Herring wrote:
> On 10/30/2012 10:01 AM, Thomas Petazzoni wrote:
>> Rob,
>>
>> On Tue, 30 Oct 2012 09:54:18 -0500, Rob Herring wrote:
>>> From: Rob Herring <rob.herring@calxeda.com>
>>>
>>> Now that we have drivers/irqchip, move GIC irqchip to drivers/irqchip. This
>>> is necessary to share the GIC with arm and arm64.
>>>
>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> ---
>>> arch/arm/common/Kconfig | 8 --------
>>> arch/arm/common/Makefile | 1 -
>>> drivers/irqchip/Kconfig | 8 ++++++++
>>> drivers/irqchip/Makefile | 1 +
>>> arch/arm/common/gic.c => drivers/irqchip/irq-gic.c | 0
>>> drivers/irqchip/irqchip.c | 10 ++++++++++
>>> drivers/irqchip/irqchip.h | 1 +
>>> 7 files changed, 20 insertions(+), 9 deletions(-)
>>
>> What about arch/arm/include/asm/hardware/gic.h ?
>>
>> Contrary to the current version of the bcm2835 IRQ controller driver
>> and the armada-370-xp IRQ controller driver, the GIC and VIC drivers
>> not only expose a <foo>_of_init() function, but also other functions
>> that are directly used by several non-DT capable ARM sub-architectures.
>>
>> Of course, it works by leaving gic.h where it is now, but it sounds
>> strange to have the driver in drivers/irqchip/ and the header file in
>> arch/arm/include/asm/hardware/, especially if the goal is to be able to
>> use those drivers in arm64.
>
> Right. I'll have to move it. I wasn't really thinking about arm64 until
> this morning.
Looking at this some more, arm64 doesn't need most of what's in gic.h.
The register defines should be moved into the .c file. The remaining
function declarations either are not needed (i.e. gic_init) or should
should be done like the handle_irq function pointer init. We don't want
to have platform code calling gic_cascade_irq or gic_raise_softirq
directly. Perhaps we need to support this generically in irqchip code.
So I'll leave them in the current header and arm64 can add the necessary
support it needs.
Rob
^ permalink raw reply
* [PATCH 1/5] ARM: at91: atmel-ssc: add platform device id table
From: Nicolas Ferre @ 2012-10-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030160722.GW4511@opensource.wolfsonmicro.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 10/30/2012 05:07 PM, Mark Brown :
> On Mon, Oct 22, 2012 at 06:17:55PM +0800, Bo Shen wrote:
>> Using platform device id to check whether the Atmel SOC support
>> dma for data transfer
>>
>> If match "at91rm9200_ssc" which does not support DMA transfer If
>> match "at91sam9g45_ssc" which support DMA transfer
>
> Any comments on this from that Atmel folks? If I don't see
> something I'll probably just apply.
Indeed, comment sent.
Thanks for the "heads-up" Mark.
Best regards,
- --
Nicolas Ferre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJQkAr2AAoJEAf03oE53VmQviMIAJrjBBi3ePMgP+jwRQuKw54A
bZOHRmaqpGPh6cLAvXeUEkv2VflLcoYxIKiV1PZsNYctUHz/rrYX4y5bMwkJqJb1
jWR1LDibKWny74pXiilrf4pgtabqhIQN8v64DjIg4vF8I6pzBBtlA3sBBQtRlJzB
yQulBHP63vNDHlZm+AayeuWkF16Gh+FfDtYSNDy8w8lNjJLwQo2mNvI6WurSTI85
mqidOzW5k0wrYo/6012vAzIV3BC+1Ck0A2gXhkS8yhuThS1xT+u4c3iTAMJE2FzZ
PM4+JLf0o5fgtOkj0UzFuVea6BxNQ/qjwyV6y+cJ/QBS7DY7N9rmD+vrr8dpgMs=
=wvcs
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 2/5] ARM: at91: atmel-ssc: add device tree support
From: Nicolas Ferre @ 2012-10-30 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350901079-18307-2-git-send-email-voice.shen@atmel.com>
On 10/22/2012 12:17 PM, Bo Shen :
> Add Atmel SSC for device tree support.
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
> .../devicetree/bindings/misc/atmel-ssc.txt | 15 ++++++
> arch/arm/boot/dts/at91sam9260.dtsi | 8 ++++
> arch/arm/boot/dts/at91sam9263.dtsi | 16 +++++++
> arch/arm/boot/dts/at91sam9g45.dtsi | 16 +++++++
> arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++++
> arch/arm/mach-at91/at91rm9200.c | 3 ++
> arch/arm/mach-at91/at91sam9260.c | 1 +
> arch/arm/mach-at91/at91sam9261.c | 3 ++
> arch/arm/mach-at91/at91sam9263.c | 2 +
> arch/arm/mach-at91/at91sam9g45.c | 2 +
> arch/arm/mach-at91/at91sam9rl.c | 2 +
> arch/arm/mach-at91/at91sam9x5.c | 1 +
> drivers/misc/atmel-ssc.c | 48 ++++++++++++++++++--
> 13 files changed, 122 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/misc/atmel-ssc.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> new file mode 100644
> index 0000000..ff5ea22
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
> @@ -0,0 +1,15 @@
> +* Atmel SSC driver.
> +
> +Required properties:
> +- compatible: "atmel,at91rm9200_ssc" or "atmel,at91sam9g45_ssc"
> + - atmel,at91rm9200_ssc: support pdc transfer
> + - atmel,at91sam9g45_ssc: support dma transfer
No underscore in device tree properties, please.
> +- reg: Should contain SSC registers location and length
> +- interrupts: Should contain SSC interrupt
> +
> +Example:
> +ssc0: ssc at fffbc000 {
> + compatible = "atmel,at91rm9200-ssc";
Oh, the '_' moved into a '-': better.
> + reg = <0xfffbc000 0x4000>;
> + interrupts = <14 4 5>;
> +};
> diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi
> index d410581..aaa42d8 100644
> --- a/arch/arm/boot/dts/at91sam9260.dtsi
> +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> @@ -29,6 +29,7 @@
> tcb0 = &tcb0;
> tcb1 = &tcb1;
> i2c0 = &i2c0;
> + ssc0 = &ssc0;
> };
> cpus {
> cpu at 0 {
> @@ -212,6 +213,13 @@
> status = "disabled";
> };
>
> + ssc0: ssc at fffbc000 {
> + compatible = "atmel,at91rm9200-ssc";
> + reg = <0xfffbc000 0x4000>;
> + interrupts = <14 4 5>;
> + status = "disable";
> + };
> +
> adc0: adc at fffe0000 {
> compatible = "atmel,at91sam9260-adc";
> reg = <0xfffe0000 0x100>;
> diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi
> index 3e6e5c1..3b721ee 100644
> --- a/arch/arm/boot/dts/at91sam9263.dtsi
> +++ b/arch/arm/boot/dts/at91sam9263.dtsi
> @@ -25,6 +25,8 @@
> gpio4 = &pioE;
> tcb0 = &tcb0;
> i2c0 = &i2c0;
> + ssc0 = &ssc0;
> + ssc1 = &ssc1;
> };
> cpus {
> cpu at 0 {
> @@ -173,6 +175,20 @@
> status = "disabled";
> };
>
> + ssc0: ssc at fff98000 {
> + compatible = "atmel,at91rm9200-ssc";
> + reg = <0xfff98000 0x4000>;
> + interrupts = <16 4 5>;
> + status = "disable";
> + };
> +
> + ssc1: ssc at fff9c000 {
> + compatible = "atmel,at91rm9200-ssc";
> + reg = <0xfff9c000 0x4000>;
> + interrupts = <17 4 5>;
> + status = "disable";
> + };
> +
> macb0: ethernet at fffbc000 {
> compatible = "cdns,at32ap7000-macb", "cdns,macb";
> reg = <0xfffbc000 0x100>;
> diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi
> index 3add030..cd9af7c 100644
> --- a/arch/arm/boot/dts/at91sam9g45.dtsi
> +++ b/arch/arm/boot/dts/at91sam9g45.dtsi
> @@ -31,6 +31,8 @@
> tcb1 = &tcb1;
> i2c0 = &i2c0;
> i2c1 = &i2c1;
> + ssc0 = &ssc0;
> + ssc1 = &ssc1;
> };
> cpus {
> cpu at 0 {
> @@ -226,6 +228,20 @@
> status = "disabled";
> };
>
> + ssc0: ssc at fff9c000 {
> + compatible = "atmel,at91sam9g45-ssc";
> + reg = <0xfff9c000 0x4000>;
> + interrupts = <16 4 5>;
> + status = "disable";
> + };
> +
> + ssc0: ssc at fffa0000 {
> + compatible = "atmel,at91sam9g45-ssc";
> + reg = <0xfffa0000 0x4000>;
> + interrupts = <17 4 5>;
> + status = "disable";
> + };
> +
> adc0: adc at fffb0000 {
> compatible = "atmel,at91sam9260-adc";
> reg = <0xfffb0000 0x100>;
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 03fc136..69667d0 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -30,6 +30,7 @@
> i2c0 = &i2c0;
> i2c1 = &i2c1;
> i2c2 = &i2c2;
> + ssc0 = &ssc0;
> };
> cpus {
> cpu at 0 {
> @@ -87,6 +88,13 @@
> interrupts = <1 4 7>;
> };
>
> + ssc0: ssc at f0010000 {
> + compatible = "atmel,at91sam9g45-ssc";
> + reg = <0xf0010000 0x4000>;
> + interrupts = <28 4 5>;
> + status = "disable";
> + };
> +
> tcb0: timer at f8008000 {
> compatible = "atmel,at91sam9x5-tcb";
> reg = <0xf8008000 0x100>;
> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c
> index 85d53c5..6d65feb 100644
> --- a/arch/arm/mach-at91/at91rm9200.c
> +++ b/arch/arm/mach-at91/at91rm9200.c
> @@ -187,6 +187,9 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffd0000.ssc", &ssc0_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffd4000.ssc", &ssc1_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffd8000.ssc", &ssc2_clk),
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk),
> /* fake hclk clock */
> CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk),
> diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c
> index 2c8aab0..54d4aea 100644
> --- a/arch/arm/mach-at91/at91sam9260.c
> +++ b/arch/arm/mach-at91/at91sam9260.c
> @@ -211,6 +211,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk),
> CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffbc000.ssc", &ssc_clk),
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk),
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk),
> /* more usart lookup table for DT entries */
> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
> index 4e8c56e..5c7a482 100644
> --- a/arch/arm/mach-at91/at91sam9261.c
> +++ b/arch/arm/mach-at91/at91sam9261.c
> @@ -177,6 +177,9 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffbc000.ssc", &ssc0_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffc0000.ssc", &ssc1_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffc4000.ssc", &ssc2_clk),
> CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0),
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk),
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk),
> diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c
> index 95a5471..1f523de 100644
> --- a/arch/arm/mach-at91/at91sam9263.c
> +++ b/arch/arm/mach-at91/at91sam9263.c
> @@ -188,6 +188,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_ID("hclk", &macb_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fff98000.ssc", &ssc0_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc1_clk),
> CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk),
> CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk),
> CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk),
> diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c
> index f4f96a6..a4282d3 100644
> --- a/arch/arm/mach-at91/at91sam9g45.c
> +++ b/arch/arm/mach-at91/at91sam9g45.c
> @@ -241,6 +241,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc0_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffa0000.ssc", &ssc1_clk),
> CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk),
> CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk),
> CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk),
> diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c
> index 4110b54..b683fdc 100644
> --- a/arch/arm/mach-at91/at91sam9rl.c
> +++ b/arch/arm/mach-at91/at91sam9rl.c
> @@ -186,6 +186,8 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk),
> CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffc0000.ssc", &ssc0_clk),
> + CLKDEV_CON_DEV_ID("pclk", "fffc4000.ssc", &ssc1_clk),
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk),
> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk),
> CLKDEV_CON_ID("pioA", &pioA_clk),
> diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c
> index e503538..18fbbb2 100644
> --- a/arch/arm/mach-at91/at91sam9x5.c
> +++ b/arch/arm/mach-at91/at91sam9x5.c
> @@ -231,6 +231,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_DEV_ID("t0_clk", "f800c000.timer", &tcb0_clk),
> CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller", &dma0_clk),
> CLKDEV_CON_DEV_ID("dma_clk", "ffffee00.dma-controller", &dma1_clk),
> + CLKDEV_CON_DEV_ID("pclk", "f0010000.ssc", &ssc_clk),
> CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk),
> CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk),
> CLKDEV_CON_DEV_ID(NULL, "f8018000.i2c", &twi2_clk),
> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
> index f40abd8..929d29a 100644
> --- a/drivers/misc/atmel-ssc.c
> +++ b/drivers/misc/atmel-ssc.c
> @@ -18,6 +18,8 @@
> #include <linux/slab.h>
> #include <linux/module.h>
>
> +#include <linux/of.h>
> +
> /* Serialize access to ssc_list and user count */
> static DEFINE_SPINLOCK(user_lock);
> static LIST_HEAD(ssc_list);
> @@ -29,7 +31,13 @@ struct ssc_device *ssc_request(unsigned int ssc_num)
>
> spin_lock(&user_lock);
> list_for_each_entry(ssc, &ssc_list, list) {
> - if (ssc->pdev->id == ssc_num) {
> + if (ssc->pdev->dev.of_node) {
> + if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc")
> + == ssc_num) {
> + ssc_valid = 1;
> + break;
> + }
> + } else if (ssc->pdev->id == ssc_num) {
> ssc_valid = 1;
> break;
> }
> @@ -88,10 +96,41 @@ static const struct platform_device_id atmel_ssc_devtypes[] = {
> }
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id atmel_ssc_dt_ids[] = {
> + {
> + .compatible = "atmel,at91rm9200-ssc",
> + .data = &at91rm9200_config,
> + }, {
> + .compatible = "atmel,at91sam9g45-ssc",
> + .data = &at91sam9g45_config,
> + }, {
> + /* sentinel */
> + }
> +};
> +MODULE_DEVICE_TABLE(of, atmel_ssc_dt_ids);
> +#endif
> +
> +static inline const struct atmel_ssc_platform_data * __init
> + atmel_ssc_get_driver_data(struct platform_device *pdev)
> +{
> + if (pdev->dev.of_node) {
> + const struct of_device_id *match;
> + match = of_match_node(atmel_ssc_dt_ids, pdev->dev.of_node);
> + if (match == NULL)
> + return NULL;
> + return match->data;
> + }
> +
> + return (struct atmel_ssc_platform_data *)
> + platform_get_device_id(pdev)->driver_data;
> +}
> +
> static int ssc_probe(struct platform_device *pdev)
> {
> struct resource *regs;
> struct ssc_device *ssc;
> + const struct atmel_ssc_platform_data *plat_dat;
>
> ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL);
> if (!ssc) {
> @@ -100,8 +139,10 @@ static int ssc_probe(struct platform_device *pdev)
> }
>
> ssc->pdev = pdev;
> - ssc->pdata = (struct atmel_ssc_platform_data *)
> - platform_get_device_id(pdev)->driver_data;
> +
> + plat_dat = atmel_ssc_get_driver_data(pdev);
> + if (!plat_dat)
> + return -ENODEV;
>
> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!regs) {
> @@ -160,6 +201,7 @@ static struct platform_driver ssc_driver = {
> .driver = {
> .name = "ssc",
> .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(atmel_ssc_dt_ids),
> },
> .id_table = atmel_ssc_devtypes,
> .probe = ssc_probe,
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] mmc: at91-mci: remove driver
From: Nicolas Ferre @ 2012-10-30 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030154309.GD19021@game.jcrosoft.org>
On 10/30/2012 04:43 PM, Jean-Christophe PLAGNIOL-VILLARD :
> On 11:38 Tue 30 Oct , Chris Ball wrote:
>> Hi,
>>
>> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 11:09 Tue 30 Oct , Chris Ball wrote:
>>>> Hi,
>>>>
>>>> On Tue, Oct 30 2012, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>>>>> Thanks! Pushed to mmc-next for 3.8.
>>>>>
>>>>> if you don't mind I prefer to take it via at91
>>>>>
>>>>> I've a patch series that cleanup the platform_data it's difficult to merge
>>>>> with this one
>>>>
>>>> Hm, I don't understand why it should be difficult to merge. Is it
>>>> because this patch modifies arch/arm/mach-at91/include/mach/board.h?
>>>>
>>>> If so, sounds like we should just take that change out of this patch
>>>> and have it go into your platform data cleanup patch, and then I can
>>>> merge the drivers/mmc change independently? Let me know what you think.
>>> I'm modifing and moiving the board.h so this file will not exist anymore
>>>
>>> and the platform data are not anymore in arch/arm/mach-at91/include/mach/board.h
>>
>> Can we take the modification of board.h out of this patch, then,
>> leaving just the drivers/mmc/ changes?
> If you really insist but for changelog history and bisectable I'll prefer to
> do not do so
Why don't we leave the code already submitted in the mmc tree. It seems
that the conflict can be pretty easily handled in advance as it ends up
being a file removal...
So, I would not bother Chris with our own business and would just manage
the conflict later, in linux-next (maybe sending a little note to Stephen).
My $0.02.
Bye,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] spi/pl022: Activate resourses before deactivate them in suspend
From: Ulf Hansson @ 2012-10-30 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210281659520.9245-100000@netrider.rowland.org>
On 28 October 2012 22:09, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Sun, 28 Oct 2012, Ulf Hansson wrote:
>
>> On 28 October 2012 20:52, Linus Walleij <linus.walleij@linaro.org> wrote:
>> > On Sat, Oct 27, 2012 at 11:46 PM, Mark Brown
>> > <broonie@opensource.wolfsonmicro.com> wrote:
>> >> On Fri, Oct 05, 2012 at 09:43:32AM +0200, Ulf Hansson wrote:
>> >>
>> >>> To be able to deactivate resourses in suspend, the resourses must
>> >>> first be surely active. This is done with a pm_runtime_get_sync.
>> >>> Once the resourses are restored to active state again in resume,
>> >>> the runtime pm usage count can be decreased with a pm_runtime_put.
>> >>
>> >> The PM core will ensure devices are runtime resumed before we enter
>> >> suspend precisely due to this sort of issue.
>> >
>> > I asked the very same question to Ulf (in speech, sorry
>> > so you couldn't see it...)
>> >
>> > So I guess we are talking about drivers/base/main.c
>> >
>> > in device_prepare()
>> > pm_runtime_get_noresume() is called
>>
>> This will increase the "usage_counter" for the device. It will not
>> "runtime_resume" the device, though it will prevent it from being
>> "runtime_suspended".
>
> Indeed. The PM core does _not_ insure that devices are runtime resumed
> before going into system suspend. Some subsystems may do this (the PCI
> subsystem does, for example -- see
> drivers/pci/pci-driver.c:pci_pm_prepare()), but the PM core doesn't.
>
> Alan Stern
>
Thanks for clarifying this Alan. Although, I am having second thoughts
around this patch even if it does what I expect it to do.
I think that the pm_runtime_get_sync (and the corrsponding "put")
should maybe be done in the suspend|resume functions of the amba bus
(drivers/amba/bus.c) instead.
The reason is because the amba bus is responsible for the apb_pclk -
clk, which also should be handled during suspend and this is not the
case right now. Unless we think each amba device driver should handle
this clock during suspend|resume...
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs
From: Karicheri, Muralidharan @ 2012-10-30 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-1-git-send-email-m-karicheri2@ti.com>
Mike, Sekhar,
Could you please take some time to review this patch set? Last one was reviewed by Sekhar and I have re-worked the patch to address his comments.
Murali
>> -----Original Message-----
>> From: Karicheri, Muralidharan
>> Sent: Thursday, October 25, 2012 12:12 PM
>> To: mturquette at linaro.org; arnd at arndb.de; akpm at linux-foundation.org;
>> shawn.guo at linaro.org; rob.herring at calxeda.com; linus.walleij at linaro.org;
>> viresh.linux at gmail.com; linux-kernel at vger.kernel.org; Nori, Sekhar; Hilman, Kevin;
>> linux at arm.linux.org.uk; sshtylyov at mvista.com; davinci-linux-open-
>> source at linux.davincidsp.com; linux-arm-kernel at lists.infradead.org
>> Cc: linux-keystone at list.ti.com - Linux developers for Keystone family of devices (May
>> contain non-TIers); Karicheri, Muralidharan
>> Subject: [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs
>>
>> This is v3 of the patch series for implementing clock tree for DaVinci SoCs using common
>> clk framework.
>>
>> supported platforms: DM644x
>>
>> This code base can be accessed at
>>
>> https://gitorious.org/~m-karicheri/linux-davinci/linux-davinci-clk/commits/common-clk-
>> v3
>>
>> The patch series is split in two parts:-
>> patches prefixed with "clk" are for clk drivers
>> patches prefixed with "ARM" are for davinci machine specific code.
>>
>> revision history:
>> -----------------
>> updates in v3:
>> - Major changes done based on review of v2 to move the clock data and
>> initialization code to drivers/clk/davinci. There is a soc specific
>> code (for example dm644x-clock.c) for doing clock initialization.
>> - Files renamed based on the review comments.
>> - Only DM644x is supported. Other devices will be added as the code
>> matures so that unnecessary rework can be avoided.
>> - Incorporated comments from Nori Sekhar and Linus (comments coding
>> style)
>> - Added clk-div clock to represent DaVinci pll divider clocks
>> - Removed clk-keystone-pll.c (will be added later)
>>
>> updates in v2:
>> - updates to davinci_clk to use union for clk driver platform data
>> - Fixed Linus Walleij' comment on code comment
>> - added code clean up that takes out the ifdef used in previous patches
>>
>> updates in v1:
>> - Added DM365 and DM355
>> - updates to davinci_clk struct to accomodate clk-fixed-factor data
>>
>> initial version:-
>>
>> Currently arch/arm/mach-davinci/clock.c and arch/arm/mach-davinci/psc.c implements
>> clock drivers for DaVinci. This patch makes these code obsolete and migrate the SoC code
>> to use the common clk based drivers. This adds two clk drivers specific to DaVinci and
>> Keystone (found in c6x arch such as C6678) devices. Some of the existing clk drivers such
>> as clk-fixed-rate, clk-divider, and clk-mux are re-used in addition to the DaVinci specific
>> drivers to initialize the clock tree for the SoCs. Please refer chapter 6 of
>> http://www.ti.com/lit/ug/sprue14c/sprue14c.pdf for details of the PLL hardware in
>> DM6446 and chapter 7 for defails of the PSC hardware.
>>
>> There are two Main PLLs in DM644x. PLL1 and PLL2. Each of these generate different
>> clocks in the DM device through PLL dividers. Figure above shows this for PLL1. Similar
>> hardware exists for PLL2 and the related output clocks. The hardware is similar in most of
>> the DM SoCs. Some of the recent Keystone devices
>> (c6678 under c6x architecture) include a slight variant of the PLL that implemented
>> different registers for the multipliers and dividers. All of these devices include PLL dividers
>> (PLLDIVx) and Power Sleep controllers (PSC). The SoCs defines various Power Domains
>> and Clock domains and there are PSC modules that controls power and clocks to various
>> hardware IPs of the SoC.
>>
>> Following drivers are used for various clock hardware blocks:-
>>
>> CLKIN and OSCIN - clk-fixed-rate (existing driver) MUX - clk-mux (existing driver)
>> PLLDIVx - davinci/clk-div (new driver) PLL mult/div - clk-pll (new driver) PSC - clk-psc.c
>> (new driver)
>>
>> Please note that initially only platforms listed above are supported. The idea is to review
>> the initial patch set and get a feedback on the overall structure of the code organization.
>> The other SoCs will be added in subsequent patch revisions.
>>
>> The driver code implements the features needed to support the platforms listed above. It
>> is expected that these drivers get updated in subsequent patch revisions to support
>> additional SoCs. I have boot tested this on DM6446 EVM. Also verified reboot command
>> works and the clock rates are set as before.
>> The patches depends on the following patches that I had sent for review earlier:
>>
>> davinci spi driver preparation @
>> https://patchwork.kernel.org/patch/1389321/
>> davinci watchdog driver preparation @
>> https://lkml.org/lkml/2012/9/7/634
>> davinci nand driver preparation @
>> https://lkml.org/lkml/2012/9/7/635
>> davinci i2c driver preparation @
>> https://patchwork.kernel.org/patch/1388841/
>> davinci gpio driver preparation @
>> https://lkml.org/lkml/2012/8/31/341
>>
>> [RFC - PATCH] base:pm: prepare driver for common clock framework
>>
>> ISSUES to discuss
>> -----------------
>> Following are to be discussed as part of this patch review.
>>
>> 1. arch/arm/pm.c. This is configuring PLL controller registers for suspend and
>> resume. It appears that we need to move this code to clk-pll.c?? But
>> I can't find APIs for suspend and resume in the common clk framework. How
>> is this expected to work? Currently i have kept the code ASIS.
>>
>> 2. There are usecount=1 in the old clock implementation for dsp, vicp and timer2
>> clocks. CLK_IGNORE_UNUSED flag is used currently to implement the same as
>> disabling these unused clocks causes issues in boot up,
>>
>> HELP NEEDED!!:
>> --------------
>> I am doing this work as a background activity and hence the progress will be slow. Please
>> volunteer to help me in this effort by offering to test or migrating other devices to this
>> framework.
>>
>> Murali Karicheri (11):
>> clk: davinci - add main PLL clock driver
>> clk: davinci - add PSC clock driver
>> clk: davinci - common clk utilities to init clk driver
>> clk: davinci - add pll divider clock driver
>> clk: davinci - add dm644x clock initialization
>> clk: davinci - add build infrastructure for DaVinci clock drivers
>> ARM: davinci - restructure header files for common clock migration
>> ARM: davinci - migrating to use common clock init code
>> ARM: davinci - dm644x: update SoC code to remove the clock data
>> ARM: davinci - migrate to common clock
>> ARM: davinci - common clock migration: clean up the old code
>>
>> arch/arm/Kconfig | 1 +
>> arch/arm/mach-davinci/Kconfig | 2 +
>> arch/arm/mach-davinci/Makefile | 15 +-
>> arch/arm/mach-davinci/clock.c | 669 ---------------------------
>> arch/arm/mach-davinci/clock.h | 135 ------
>> arch/arm/mach-davinci/common.c | 10 -
>> arch/arm/mach-davinci/cpufreq.c | 2 -
>> arch/arm/mach-davinci/davinci.h | 3 +
>> arch/arm/mach-davinci/devices.c | 1 -
>> arch/arm/mach-davinci/dm644x.c | 302 +-----------
>> arch/arm/mach-davinci/include/mach/clock.h | 21 -
>> arch/arm/mach-davinci/include/mach/common.h | 10 +-
>> arch/arm/mach-davinci/include/mach/pll.h | 46 ++
>> arch/arm/mach-davinci/include/mach/psc.h | 209 ---------
>> arch/arm/mach-davinci/include/mach/time.h | 2 +-
>> arch/arm/mach-davinci/pm.c | 3 +-
>> arch/arm/mach-davinci/psc.c | 112 -----
>> arch/arm/mach-davinci/sleep.S | 3 +-
>> arch/arm/mach-davinci/time.c | 6 +-
>> drivers/clk/Kconfig | 2 +
>> drivers/clk/Makefile | 1 +
>> drivers/clk/davinci/Kconfig | 44 ++
>> drivers/clk/davinci/Makefile | 5 +
>> drivers/clk/davinci/clk-div.c | 124 +++++
>> drivers/clk/davinci/clk-div.h | 42 ++
>> drivers/clk/davinci/clk-pll.c | 146 ++++++
>> drivers/clk/davinci/clk-pll.h | 57 +++
>> drivers/clk/davinci/clk-psc.c | 207 +++++++++
>> drivers/clk/davinci/clk-psc.h | 46 ++
>> drivers/clk/davinci/clock.c | 112 +++++
>> drivers/clk/davinci/clock.h | 80 ++++
>> drivers/clk/davinci/dm644x-clock.c | 304 ++++++++++++
>> drivers/clk/davinci/pll.h | 83 ++++
>> drivers/clk/davinci/psc.h | 215 +++++++++
>> 34 files changed, 1530 insertions(+), 1490 deletions(-) delete mode 100644
>> arch/arm/mach-davinci/clock.c delete mode 100644 arch/arm/mach-davinci/clock.h
>> delete mode 100644 arch/arm/mach-davinci/include/mach/clock.h
>> create mode 100644 arch/arm/mach-davinci/include/mach/pll.h
>> delete mode 100644 arch/arm/mach-davinci/psc.c create mode 100644
>> drivers/clk/davinci/Kconfig create mode 100644 drivers/clk/davinci/Makefile create
>> mode 100644 drivers/clk/davinci/clk-div.c create mode 100644 drivers/clk/davinci/clk-
>> div.h create mode 100644 drivers/clk/davinci/clk-pll.c create mode 100644
>> drivers/clk/davinci/clk-pll.h create mode 100644 drivers/clk/davinci/clk-psc.c create
>> mode 100644 drivers/clk/davinci/clk-psc.h create mode 100644
>> drivers/clk/davinci/clock.c create mode 100644 drivers/clk/davinci/clock.h create mode
>> 100644 drivers/clk/davinci/dm644x-clock.c
>> create mode 100644 drivers/clk/davinci/pll.h create mode 100644
>> drivers/clk/davinci/psc.h
>>
>> --
>> 1.7.9.5
^ permalink raw reply
* [PATCH 1/2] arm: bcm2835: move to the multiplatform support
From: Stephen Warren @ 2012-10-30 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121030092046.7d20407b@skate>
On 10/30/2012 02:20 AM, Thomas Petazzoni wrote:
> Stephen,
>
> Thanks for taking the time to look at this patch.
>
> On Mon, 29 Oct 2012 20:31:27 -0600, Stephen Warren wrote:
>
>> Since CONFIG_VFP is enabled in bcm2835_defconfig (or in general, could
>> be enabled in anyone's .config), I guess that means I can't apply the
>> patch yet, because the VFP fix you mention above doesn't seem to have
>> been applied anywhere, so applying it would cause bcm2835_defconfig to
>> be unbootable. To apply this, I'd need to merge in a branch containing
>> the VFP fix first.
>
> I'm pretty sure the VFP fix will land somewhere at some point, we can
> wait this moment to merge this multiplatform bcm2835 support patch.
>
>> What branch is this patch series based on? Neither "git am" not "git am
>> -3" will apply the series; apparently my repo doesn't have the blobs to
>> perform the 3-way merge -3 invokes even though I have a remote for
>> linux-next which should pick up most blob sources.
>
> This is my fault, sorry. I based this patch on a branch that contains
> the VFP fix + the irqchip changes I've been proposing. I can resend a
> new version based on 3.7-rc3, or arm-soc/for-next, at your preference.
(Once the dependencies are in arm-soc somewhere...) It'd be best to base
it on v3.7-rcN, either with/without the VFP and debug_ll_io_init()
patches merged (since I'll apply the patch only on top of those two
patches anyway.
Thanks.
^ permalink raw reply
* [PATCH v2 1/5] clk: samsung: add common clock framework support for Samsung platforms
From: Mike Turquette @ 2012-10-30 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349629855-4962-2-git-send-email-thomas.abraham@linaro.org>
Hi Thomas,
Quoting Thomas Abraham (2012-10-07 10:10:51)
> +/* determine the output clock speed of the pll */
> +static unsigned long samsung_pll_clock_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct samsung_pll_clock *clk_pll = to_clk_pll(hw);
> +
> + if (clk_pll->get_rate)
> + return to_clk_pll(hw)->get_rate(parent_rate);
Why the extra indirection? Does your samsung_pll_clock abstract several
different PLL implementations (with separate clock ops)? If so, why not
make a unique struct for each PLL type?
> +
> + return 0;
> +}
> +
> +/* round operation not supported */
> +static long samsung_pll_clock_round_rate(struct clk_hw *hw, unsigned long drate,
> + unsigned long *prate)
> +{
> + return samsung_pll_clock_recalc_rate(hw, *prate);
Why is round_rate not supported? How is returning the recalculated rate
the right thing here?
> +/*
> + * Allow platform specific implementations to attach set_rate and get_rate
> + * callbacks for the pll type clock. Typical calling sequence..
> + *
> + * struct clk *clk = clk_get(NULL, "pll-clk-name");
> + * samsung_pll_clk_set_cb(clk, pll_set_rate, pll_get_rate);
> + */
> +void __init samsung_pll_clk_set_cb(struct clk *clk,
> + int (*set_rate)(unsigned long rate),
> + unsigned long (*get_rate)(unsigned long rate))
> +{
> + struct samsung_pll_clock *clk_pll;
> + struct clk_hw *hw = __clk_get_hw(clk);
> +
> + clk_pll = to_clk_pll(hw);
> + clk_pll->set_rate = set_rate;
> + clk_pll->get_rate = get_rate;
> +}
This answers my questions above having different PLL types. Why not
just make seprate clk_hw structs for each PLL type instead of the extra
layer of abstraction + runtime assignment of clk ops?
Regards,
Mike
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-10-30 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121026180039.GM11908@atomide.com>
* Tony Lindgren <tony@atomide.com> [121026 11:02]:
> * Ohad Ben-Cohen <ohad@wizery.com> [121026 02:56]:
> > Hi Laurent,
> >
> > On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart
> > <laurent.pinchart@ideasonboard.com> wrote:
> > > That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2,
> > > adding DT support, moving to the common clock framework (when that will be
> > > available for the OMAP3), supporting missing V4L2 features, ... All this in my
> > > spare time of course, otherwise it wouldn't be fun, would it ? ;-)
> >
> > Hmm, seems like a short to-do list ;)
>
> Sounds Laurent will take care of it :)
>
> > > I would also like to move the tidspbridge to the DMA API, but I think we'll
> > > need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an
> > > intermediate step would allow splitting patches in reviewable chunks. I know
> > > it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a
> > > temporary nuisance to make the leap easier.
> >
> > Since tidspbridge is in staging I guess it's not a problem, though it
> > sounds to me like using the correct API in the first place is going to
> > make less churn.
>
> Not related to these patches, but also sounds like we may need to drop
> some staging/tidspbridge code to be able to move forward with the
> ARM common zImage plans. See the "[GIT PULL] omap plat header removal
> for v3.8 merge window, part1" thread for more info.
OK so are people happy with the patches in this series?
Please everybody ack if no more comments so we can move on
towards getting CONFIG_MULTIPLATFORM to work for omaps.
Regards,
Tony
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Tony Lindgren @ 2012-10-30 16:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508FE8BA.1080404@ti.com>
* Vaibhav Hiremath <hvaibhav@ti.com> [121030 07:50]:
> >
> > MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
> > already submitted to the list recently. So MMC support will come along with
> > EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
Regards,
Tony
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox