[PATCH 0/3] OMAP2+: hwmod: Add support to parse clock info from DT
With all of OMAP clock data now moving to DT, its possible to pass the main or functional clock and all optional clocks information for a device from DT instead of having these as part of hwmod static data in the kernel. This patch series is based on 'v3' of omap4 clock movement to DT patches [1] and is boot tested on a omap4 panda es. The series does leave all the interface clocks as part of hwmod (and main and optional clocks for devices which are missing DT drivers). [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100117 Rajendra Nayak (3): ARM: OMAP2+: Add support to parse 'main_clk' info from DT ARM: OMAP2+: Add support to parse optional clk info from DT ARM: OMAP4: dts: Add main and optional clock data into DT arch/arm/boot/dts/omap4.dtsi | 100 + arch/arm/mach-omap2/omap_hwmod.c | 100 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 112 3 files changed, 185 insertions(+), 127 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP2+: Add support to parse 'main_clk' info from DT
With clocks for OMAP moving to DT, its now possible to pass the 'main_clk'
data for each device from DT instead of having it in hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 34 +-
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5cc5123..12fa589 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -728,14 +728,18 @@ static int _del_initiator_dep(struct omap_hwmod *oh,
struct omap_hwmod *init_oh)
* functional clock pointer) if a main_clk is present. Returns 0 on
* success or -EINVAL on error.
*/
-static int _init_main_clk(struct omap_hwmod *oh)
+static int _init_main_clk(struct omap_hwmod *oh, struct device_node *np)
{
int ret = 0;
- if (!oh-main_clk)
+ if (!oh-main_clk !of_get_property(np, clocks, NULL))
return 0;
- oh-_clk = clk_get(NULL, oh-main_clk);
+ if (oh-main_clk)
+ oh-_clk = clk_get(NULL, oh-main_clk);
+ else
+ oh-_clk = of_clk_get_by_name(np, fck);
+
if (IS_ERR(oh-_clk)) {
pr_warning(omap_hwmod: %s: cannot clk_get main_clk %s\n,
oh-name, oh-main_clk);
@@ -1561,7 +1565,8 @@ static int _init_clkdm(struct omap_hwmod *oh)
* Resolves all clock names embedded in the hwmod. Returns 0 on
* success, or a negative error code on failure.
*/
-static int _init_clocks(struct omap_hwmod *oh, void *data)
+static int _init_clocks(struct omap_hwmod *oh, void *data,
+ struct device_node *np)
{
int ret = 0;
@@ -1573,7 +1578,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data)
if (soc_ops.init_clkdm)
ret |= soc_ops.init_clkdm(oh);
- ret |= _init_main_clk(oh);
+ ret |= _init_main_clk(oh, np);
ret |= _init_interface_clks(oh);
ret |= _init_opt_clks(oh);
@@ -2361,11 +2366,11 @@ static struct device_node *of_dev_hwmod_lookup(struct
device_node *np,
* are part of the device's address space can be ioremapped properly.
* No return value.
*/
-static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
+static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data,
+struct device_node *np)
{
struct omap_hwmod_addr_space *mem;
void __iomem *va_start = NULL;
- struct device_node *np;
if (!oh)
return;
@@ -2381,12 +2386,10 @@ static void __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data)
oh-name);
/* Extract the IO space from device tree blob */
- if (!of_have_populated_dt())
+ if (!np)
return;
- np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, ocp), oh);
- if (np)
- va_start = of_iomap(np, 0);
+ va_start = of_iomap(np, 0);
} else {
va_start = ioremap(mem-pa_start, mem-pa_end - mem-pa_start);
}
@@ -2418,14 +2421,19 @@ static void __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data)
static int __init _init(struct omap_hwmod *oh, void *data)
{
int r;
+ struct device_node *np = NULL;
if (oh-_state != _HWMOD_STATE_REGISTERED)
return 0;
+ /* If booting with DT, parse the DT node for IO space/clocks etc */
+ if (of_have_populated_dt())
+ np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, ocp), oh);
+
if (oh-class-sysc)
- _init_mpu_rt_base(oh, NULL);
+ _init_mpu_rt_base(oh, NULL, np);
- r = _init_clocks(oh, NULL);
+ r = _init_clocks(oh, NULL, np);
if (r 0) {
WARN(1, omap_hwmod: %s: couldn't init clocks\n, oh-name);
return -EINVAL;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] ARM: OMAP4: dts: Add main and optional clock data into DT
With support to parse clock data from DT, move all main and optional
clock information from hwmod to DT.
We still retain clocks in hwmod for devices which do not have a DT node.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 100 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 112
2 files changed, 100 insertions(+), 112 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 8e142f9..4dddf64 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -106,6 +106,8 @@
compatible = ti,omap-counter32k;
reg = 0x4a304000 0x20;
ti,hwmods = counter_32k;
+ clocks = sys_32k_ck;
+ clock-names = fck;
};
omap4_pmx_core: pinmux@4a100040 {
@@ -135,6 +137,8 @@
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
+ clocks = l3_div_ck;
+ clock-names = fck;
};
gpio1: gpio@4a31 {
@@ -147,6 +151,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_wkup_clk_mux_ck, gpio1_dbclk;
+ clock-names = fck, dbclk;
};
gpio2: gpio@48055000 {
@@ -158,6 +164,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio2_dbclk;
+ clock-names = fck, dbclk;
};
gpio3: gpio@48057000 {
@@ -169,6 +177,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio3_dbclk;
+ clock-names = fck, dbclk;
};
gpio4: gpio@48059000 {
@@ -180,6 +190,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio4_dbclk;
+ clock-names = fck, dbclk;
};
gpio5: gpio@4805b000 {
@@ -191,6 +203,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio5_dbclk;
+ clock-names = fck, dbclk;
};
gpio6: gpio@4805d000 {
@@ -202,6 +216,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio6_dbclk;
+ clock-names = fck, dbclk;
};
gpmc: gpmc@5000 {
@@ -221,6 +237,8 @@
interrupts = 0 72 0x4;
ti,hwmods = uart1;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
uart2: serial@4806c000 {
@@ -229,6 +247,8 @@
interrupts = 0 73 0x4;
ti,hwmods = uart2;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
uart3: serial@4802 {
@@ -237,6 +257,8 @@
interrupts = 0 74 0x4;
ti,hwmods = uart3;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
uart4: serial@4806e000 {
@@ -245,6 +267,8 @@
interrupts = 0 70 0x4;
ti,hwmods = uart4;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
i2c1: i2c@4807 {
@@ -254,6 +278,8 @@
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c1;
+ clocks = func_96m_fclk;
+ clock-names = fck;
};
i2c2: i2c@48072000 {
@@ -263,6 +289,8 @@
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c2;
+ clocks = func_96m_fclk;
+ clock-names = fck;
};
[PATCH 2/3] ARM: OMAP2+: Add support to parse optional clk info from DT
With clocks for OMAP moving to DT, its now possible to pass all optional clock
data for each device from DT instead of having it in hwmod.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 66 --
1 file changed, 64 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 12fa589..e5c804b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -805,6 +805,65 @@ static int _init_interface_clks(struct omap_hwmod *oh)
return ret;
}
+static const char **_parse_opt_clks_dt(struct omap_hwmod *oh,
+ struct device_node *np,
+ int *opt_clks_cnt)
+{
+ int i, clks_cnt;
+ const char *clk_name;
+ const char **opt_clk_names;
+
+ clks_cnt = of_property_count_strings(np, clock-names);
+ if (!clks_cnt)
+ return NULL;
+
+ opt_clk_names = kzalloc(sizeof(char *)*clks_cnt, GFP_KERNEL);
+ if (!opt_clk_names)
+ return NULL;
+
+ for (i = 0; i clks_cnt; i++) {
+ of_property_read_string_index(np, clock-names, i, clk_name);
+ if (!strcmp(clk_name, fck))
+ continue;
+ opt_clks_cnt++;
+ opt_clk_names[i] = clk_name;
+ }
+ return opt_clk_names;
+}
+
+static int _init_opt_clks_dt(struct omap_hwmod *oh, struct device_node *np)
+{
+ struct clk *c;
+ int i, opt_clks_cnt = 0;
+ int ret = 0;
+ const char **opt_clk_names;
+
+ opt_clk_names = _parse_opt_clks_dt(oh, np, opt_clks_cnt);
+ if (!opt_clk_names)
+ return -EINVAL;
+
+ oh-opt_clks = kzalloc(sizeof(struct omap_hwmod_opt_clk *)
+ * opt_clks_cnt, GFP_KERNEL);
+ if (!oh-opt_clks)
+ return -ENOMEM;
+
+ oh-opt_clks_cnt = opt_clks_cnt;
+
+ for (i = 0; i oh-opt_clks_cnt; i++) {
+ c = of_clk_get_by_name(np, opt_clk_names[i]);
+ if (IS_ERR(c)) {
+ pr_warn(omap_hwmod: %s: cannot clk_get opt_clk %s\n,
+ oh-name, opt_clk_names[i]);
+ ret = -EINVAL;
+ }
+ oh-opt_clks[i]._clk = c;
+ oh-opt_clks[i].role = opt_clk_names[i];
+ oh-opt_clks_cnt++;
+ clk_prepare(oh-opt_clks[i]._clk);
+ }
+ return ret;
+}
+
/**
* _init_opt_clk - get a struct clk * for the the hwmod's optional clocks
* @oh: struct omap_hwmod *
@@ -812,13 +871,16 @@ static int _init_interface_clks(struct omap_hwmod *oh)
* Called from _init_clocks(). Populates the @oh omap_hwmod_opt_clk
* clock pointers. Returns 0 on success or -EINVAL on error.
*/
-static int _init_opt_clks(struct omap_hwmod *oh)
+static int _init_opt_clks(struct omap_hwmod *oh, struct device_node *np)
{
struct omap_hwmod_opt_clk *oc;
struct clk *c;
int i;
int ret = 0;
+ if (of_get_property(np, clocks, NULL))
+ return _init_opt_clks_dt(oh, np);
+
for (i = oh-opt_clks_cnt, oc = oh-opt_clks; i 0; i--, oc++) {
c = clk_get(NULL, oc-clk);
if (IS_ERR(c)) {
@@ -1580,7 +1642,7 @@ static int _init_clocks(struct omap_hwmod *oh, void *data,
ret |= _init_main_clk(oh, np);
ret |= _init_interface_clks(oh);
- ret |= _init_opt_clks(oh);
+ ret |= _init_opt_clks(oh, np);
if (!ret)
oh-_state = _HWMOD_STATE_CLKS_INITED;
--
1.7.9.5
--
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: OMAP2430 SDP boot broken after Linus' rmk merge
On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system. I understand completely... Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem. I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). OK, will dig deeper here at the next opportunity. Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo? - Paul ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] ARM: Do not run dummy_flush_tlb_a15_erratum() on non-Cortex-A15
On Tue, 23 Jul 2013, Fabio Estevam wrote: From: Fabio Estevam fabio.este...@freescale.com Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)) causes the following undefined instruction error on a mx53 (Cortex-A8): Internal error: Oops - undefined instruction: 0 [#1] SMP ARM CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-9-g9b0f371 #881 task: df46cc00 ti: df48e000 task.ti: df48e000 PC is at check_and_switch_context+0x17c/0x4d0 LR is at check_and_switch_context+0xdc/0x4d0 This problem happens because check_and_switch_context() calls dummy_flush_tlb_a15_erratum() without checking if we are really running on a Cortex-A15 or not. To avoid this issue, always check if we are running on a Cortex-A15 or not (via erratum_a15_798181()) inside dummy_flush_tlb_a15_erratum(), so that we do not need to keep doing the same check in all occurrences of dummy_flush_tlb_a15_erratum(). Signed-off-by: Fabio Estevam fabio.este...@freescale.com Nice work. This fixes the v3.11-rc boot regression on most OMAP3/AM33xx devices. Tested-by: Paul Walmsley p...@pwsan.com # for OMAP2,3,4,AM33xx - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Hi Rajendra, On Tue, 23 Jul 2013, Rajendra Nayak wrote: On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system. I understand completely... Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem. I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). OK, will dig deeper here at the next opportunity. Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo? Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed. I don't have a 4430SDP, so you might consider touching base with rmk for that one. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv4 08/33] ARM: dts: omap4 clock data
This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
different clock tree which is taken into account in the data.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap443x-clocks.dtsi | 17 +
arch/arm/boot/dts/omap443x.dtsi|8 +
arch/arm/boot/dts/omap4460.dtsi|8 +
arch/arm/boot/dts/omap446x-clocks.dtsi | 27 +
arch/arm/boot/dts/omap44xx-clocks.dtsi | 1654
5 files changed, 1714 insertions(+)
create mode 100644 arch/arm/boot/dts/omap443x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/omap446x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/omap44xx-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi
b/arch/arm/boot/dts/omap443x-clocks.dtsi
new file mode 100644
index 000..2bd82b2
--- /dev/null
+++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
@@ -0,0 +1,17 @@
+/*
+ * Device Tree Source for OMAP443x clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+bandgap_fclk: bandgap_fclk@4a307888 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = sys_32k_ck;
+ bit-shift = 8;
+ reg = 0x4a307888 0x4;
+};
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index bcf455e..dfd648c 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -30,4 +30,12 @@
0x4a00232C 0x4;
compatible = ti,omap4430-bandgap;
};
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ /include/ omap44xx-clocks.dtsi
+ /include/ omap443x-clocks.dtsi
+ };
};
diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi
index c2f0f39..d9d00b2 100644
--- a/arch/arm/boot/dts/omap4460.dtsi
+++ b/arch/arm/boot/dts/omap4460.dtsi
@@ -38,4 +38,12 @@
interrupts = 0 126 IRQ_TYPE_LEVEL_HIGH; /* talert */
gpios = gpio3 22 0; /* tshut */
};
+
+ clocks {
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ /include/ omap44xx-clocks.dtsi
+ /include/ omap446x-clocks.dtsi
+ };
};
diff --git a/arch/arm/boot/dts/omap446x-clocks.dtsi
b/arch/arm/boot/dts/omap446x-clocks.dtsi
new file mode 100644
index 000..86d0805
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x-clocks.dtsi
@@ -0,0 +1,27 @@
+/*
+ * Device Tree Source for OMAP446x clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+div_ts_ck: div_ts_ck@4a307888 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = l4_wkup_clk_mux_ck;
+ bit-shift = 24;
+ reg = 0x4a307888 0x4;
+ table = 8 0 , 16 1 , 32 2 ;
+ bit-mask = 0x3;
+};
+
+bandgap_ts_fclk: bandgap_ts_fclk@4a307888 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = div_ts_ck;
+ bit-shift = 8;
+ reg = 0x4a307888 0x4;
+};
diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi
b/arch/arm/boot/dts/omap44xx-clocks.dtsi
new file mode 100644
index 000..ed6bc9b
--- /dev/null
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
@@ -0,0 +1,1654 @@
+/*
+ * Device Tree Source for OMAP4 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+extalt_clkin_ck: extalt_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 5900;
+};
+
+pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+pad_clks_ck: pad_clks_ck@4a004108 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = pad_clks_src_ck;
+ bit-shift = 8;
+ reg = 0x4a004108 0x4;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+slimbus_clk: slimbus_clk@4a004108 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+
[PATCHv4 09/33] CLK: omap: add omap4 clock init file
clk-44xx.c now contains the clock init functionality for omap4, including
DT clock registration and adding of static clkdev entries.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/clk-44xx.c | 118 +++
1 file changed, 118 insertions(+)
create mode 100644 drivers/clk/omap/clk-44xx.c
diff --git a/drivers/clk/omap/clk-44xx.c b/drivers/clk/omap/clk-44xx.c
new file mode 100644
index 000..cc12134
--- /dev/null
+++ b/drivers/clk/omap/clk-44xx.c
@@ -0,0 +1,118 @@
+/*
+ * OMAP4 Clock data
+ *
+ * Copyright (C) 2009-2012 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
+ *
+ * Paul Walmsley (p...@pwsan.com)
+ * Rajendra Nayak (rna...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Mike Turquette (mturque...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX Some of the ES1 clocks have been removed/changed; once support
+ * is added for discriminating clocks by ES level, these should be added back
+ * in.
+ *
+ * XXX All of the remaining MODULEMODE clock nodes should be removed
+ * once the drivers are updated to use pm_runtime or to use the appropriate
+ * upstream clock node for rate/parent selection.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
+#include linux/clk-private.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk/omap.h
+
+/*
+ * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
+ * 3.6.3.2.3 CM1_ABE Clock Generator states that the DPLL_ABE_X2_CLK
+ * must be set to 196.608 MHz and hence, the DPLL locked frequency is
+ * half of this value.
+ */
+#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+
+/*
+ * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
+ * 3.6.3.9.5 DPLL_USB Preferred Settings shows that the preferred
+ * locked frequency for the USB DPLL is 960MHz.
+ */
+#define OMAP4_DPLL_USB_DEFFREQ 96000
+
+static struct omap_dt_clk omap44xx_clks[] = {
+ DT_CLK(smp_twd, NULL, mpu_periphclk),
+ DT_CLK(omapdss_dss, ick, dss_fck),
+ DT_CLK(usbhs_omap, fs_fck, usb_host_fs_fck),
+ DT_CLK(usbhs_omap, hs_fck, usb_host_hs_fck),
+ DT_CLK(usbhs_omap, usbtll_ick, usb_tll_hs_ick),
+ DT_CLK(usbhs_tll, usbtll_ick, usb_tll_hs_ick),
+ DT_CLK(NULL,timer_32k_ck, sys_32k_ck),
+ /* TODO: Remove omap_timer.X aliases once DT migration is complete */
+ DT_CLK(omap_timer.1, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.2, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.3, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.4, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.9, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.10, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.11, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.5, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(omap_timer.6, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(omap_timer.7, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(omap_timer.8, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4a318000.timer,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48032000.timer,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48034000.timer,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48036000.timer,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(4803e000.timer,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48086000.timer,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48088000.timer,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(40138000.timer,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4013a000.timer,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4013c000.timer,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4013e000.timer,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(NULL,cpufreq_ck, dpll_mpu_ck),
+};
+
+int __init omap4xxx_clk_init(void)
+{
+ int rc;
+ struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck, *usb_dpll;
+
+ /* FIXME register clocks from DT first */
+ dt_omap_clk_init();
+
+ omap_dt_clocks_register(omap44xx_clks, ARRAY_SIZE(omap44xx_clks));
+
+ omap2_clk_disable_autoidle_all();
+
+ /*
+* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
+* state when turning the ABE clock domain. Workaround this by
+* locking the ABE DPLL on boot.
+* Lock the ABE DPLL in any case to avoid issues with audio.
+*/
+ abe_dpll_ref = clk_get_sys(NULL, abe_dpll_refclk_mux_ck);
+ sys_32k_ck = clk_get_sys(NULL, sys_32k_ck);
+ rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+ abe_dpll = clk_get_sys(NULL, dpll_abe_ck);
+ if (!rc)
+ rc = clk_set_rate(abe_dpll, OMAP4_DPLL_ABE_DEFFREQ);
+ if (rc)
[PATCHv4 02/33] clk: omap: introduce clock driver
Parses OMAP clock data from DT and registers those clocks with the clock
framework. dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver. Based on initial work done by
Mike Turquette.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c| 39 +++
include/linux/clk/omap.h | 24
4 files changed, 65 insertions(+)
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 include/linux/clk/omap.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..d3c3733 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= zynq/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..4bf1929
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,39 @@
+/*
+ * OMAP PRCM clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Tero Kristo t-kri...@ti.com
+ * Mike Turquette mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include linux/clk-provider.h
+#include linux/clk/omap.h
+#include linux/kernel.h
+#include linux/of_device.h
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
+static const struct of_device_id clk_match[] = {
+ {.compatible = fixed-clock, .data = of_fixed_clk_setup, },
+ {.compatible = mux-clock, .data = of_mux_clk_setup, },
+ {.compatible = fixed-factor-clock,
+ .data = of_fixed_factor_clk_setup, },
+ {.compatible = divider-clock, .data = of_divider_clk_setup, },
+ {.compatible = gate-clock, .data = of_gate_clk_setup, },
+ {},
+};
+
+/* FIXME - need to initialize early; skip real driver registration probe */
+int __init dt_omap_clk_init(void)
+{
+ of_clk_init(clk_match);
+ return 0;
+}
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 000..647f02f
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
--
1.7.9.5
--
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
[PATCHv4 06/33] CLK: omap: add autoidle support
OMAP clk driver now routes some of the basic clocks through own
registration routine to allow autoidle support. This routine just
checks a couple of device node properties and adds autoidle support
if required, and just passes the registration forward to basic clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c |6 ++
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/autoidle.c | 130 +++
drivers/clk/omap/clk.c |4 +-
include/linux/clk/omap.h|4 ++
5 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/omap/autoidle.c
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..669d4c4 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
list_for_each_entry(c, clk_hw_omap_clocks, node)
if (c-ops c-ops-allow_idle)
c-ops-allow_idle(c);
+
+ of_omap_clk_allow_autoidle_all();
+
return 0;
}
@@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
list_for_each_entry(c, clk_hw_omap_clocks, node)
if (c-ops c-ops-deny_idle)
c-ops-deny_idle(c);
+
+ of_omap_clk_deny_autoidle_all();
+
return 0;
}
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 4cad480..ca56700 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o
+obj-y += clk.o dpll.o autoidle.o
diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
new file mode 100644
index 000..6424cb2
--- /dev/null
+++ b/drivers/clk/omap/autoidle.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP clock autoidle support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+
+#ifdef CONFIG_OF
+struct clk_omap_autoidle {
+ void __iomem*reg;
+ u8 shift;
+ u8 flags;
+ const char *name;
+ struct list_headnode;
+};
+
+#define AUTOIDLE_LOW 0x1
+
+static LIST_HEAD(autoidle_clks);
+
+static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk-reg);
+
+ if (clk-flags AUTOIDLE_LOW)
+ val = ~(1 clk-shift);
+ else
+ val |= (1 clk-shift);
+
+ writel(val, clk-reg);
+}
+
+static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk-reg);
+
+ if (clk-flags AUTOIDLE_LOW)
+ val |= (1 clk-shift);
+ else
+ val = ~(1 clk-shift);
+
+ writel(val, clk-reg);
+}
+
+void of_omap_clk_allow_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, autoidle_clks, node)
+ omap_allow_autoidle(c);
+}
+
+void of_omap_clk_deny_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, autoidle_clks, node)
+ omap_deny_autoidle(c);
+}
+
+static __init void of_omap_autoidle_setup(struct device_node *node)
+{
+ u32 shift;
+ void __iomem *reg;
+ struct clk_omap_autoidle *clk;
+
+ if (of_property_read_u32(node, ti,autoidle-shift, shift))
+ return;
+
+ reg = of_iomap(node, 0);
+
+ clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
+
+ if (!clk) {
+ pr_err(%s: kzalloc failed\n, __func__);
+ return;
+ }
+
+ clk-shift = shift;
+ clk-name = node-name;
+ clk-reg = reg;
+
+ if (of_property_read_bool(node, ti,autoidle-low))
+ clk-flags |= AUTOIDLE_LOW;
+
+ list_add(clk-node, autoidle_clks);
+}
+
+void __init of_omap_divider_setup(struct device_node *node)
+{
+ of_divider_clk_setup(node);
+ of_omap_autoidle_setup(node);
+}
+EXPORT_SYMBOL_GPL(of_omap_divider_setup);
+CLK_OF_DECLARE(omap_autoidle_clock, divider-clock, of_omap_divider_setup);
+
+void __init of_omap_fixed_factor_setup(struct device_node *node)
+{
+ of_fixed_factor_clk_setup(node);
+
[PATCHv4 00/33] ARM: OMAP: clock conversion to DT
Hi, Changes compared to previous version: - Clock init files moved from mach-omap2/ to drivers/clk/omap/ - AM33xx support added [patches 15-20] - OMAP3 support added [patches 21-29] - DRA7 APLL support added (thanks Keerthy) [patches 30-33] Test branch on top of 3.11-rc1 available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.11-rc1-omap-dt-clks Testing done: - boot + suspend tested on OMAP3 beagle C4 (omap3530) - boot + suspend tested on OMAP4 panda ES (omap4460) - boot tested on beagle bone (am335x) A boot test was also executed for DRA7 and OMAP5 on a separate branch (mainline does not have OMAP5 / DRA7 support so far.) TODO: - Add AM35xx support (OMAP3 derivative, AM35xx only clock nodes missing) Overall diffstat added just for fun: arch/arm/boot/dts/am33xx-clocks.dtsi | 663 arch/arm/boot/dts/am33xx.dtsi |7 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 2113 arch/arm/boot/dts/omap3.dtsi |7 + arch/arm/boot/dts/omap3430es1-clocks.dtsi | 166 + arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi| 240 ++ arch/arm/boot/dts/omap34xx.dtsi|9 + .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi| 214 ++ arch/arm/boot/dts/omap36xx-clocks.dtsi | 97 + .../boot/dts/omap36xx-omap3430es2plus-clocks.dtsi | 185 + arch/arm/boot/dts/omap36xx.dtsi| 10 + arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1594 + arch/arm/boot/dts/omap443x-clocks.dtsi | 17 + arch/arm/boot/dts/omap443x.dtsi|8 + arch/arm/boot/dts/omap4460.dtsi|8 + arch/arm/boot/dts/omap446x-clocks.dtsi | 27 + arch/arm/boot/dts/omap44xx-clocks.dtsi | 1654 + arch/arm/boot/dts/omap54xx-clocks.dtsi | 1416 arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/cclock33xx_data.c | 1059 -- arch/arm/mach-omap2/cclock3xxx_data.c | 3641 arch/arm/mach-omap2/cclock44xx_data.c | 1730 -- arch/arm/mach-omap2/clock.c|6 + arch/arm/mach-omap2/clock.h| 163 +- arch/arm/mach-omap2/clock3xxx.h|7 +- arch/arm/mach-omap2/io.c |7 +- arch/arm/mach-omap2/omap_hwmod.c |5 +- drivers/clk/Makefile |1 + drivers/clk/clk-divider.c |6 +- drivers/clk/clk-fixed-factor.c |6 +- drivers/clk/clk-gate.c |8 +- drivers/clk/clk-mux.c |6 +- drivers/clk/clkdev.c | 32 + drivers/clk/omap/Makefile |4 + drivers/clk/omap/apll.c| 213 ++ drivers/clk/omap/autoidle.c| 130 + drivers/clk/omap/clk-33xx.c| 85 + drivers/clk/omap/clk-3xxx.c| 171 + drivers/clk/omap/clk-44xx.c| 118 + drivers/clk/omap/clk-54xx.c| 58 + drivers/clk/omap/clk-7xx.c | 67 + drivers/clk/omap/clk.c | 84 + drivers/clk/omap/dpll.c| 387 +++ drivers/clk/omap/gate.c| 166 + drivers/clk/omap/interface.c | 110 + include/linux/clk/omap.h | 223 ++ 46 files changed, 10327 insertions(+), 6606 deletions(-) -Tero -- 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
[PATCHv4 07/33] CLK: omap: add support for OMAP gate clock
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/gate.c | 88 +
include/linux/clk/omap.h |1 +
4 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/gate.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index ca56700..3d3ca30f 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o autoidle.o
+obj-y += clk.o dpll.o autoidle.o gate.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index c149097..8c89714 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
{.compatible = divider-clock, .data = of_omap_divider_setup, },
{.compatible = gate-clock, .data = of_gate_clk_setup, },
{.compatible = ti,omap4-dpll-clock, .data = of_omap4_dpll_setup, },
+ {.compatible = ti,gate-clock, .data = of_omap_gate_clk_setup, },
{},
};
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
new file mode 100644
index 000..7186bb2
--- /dev/null
+++ b/drivers/clk/omap/gate.c
@@ -0,0 +1,88 @@
+/*
+ * OMAP gate clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/omap.h
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_gate_clk_ops = {
+ .init = omap2_init_clk_clkdm,
+ .enable = omap2_clkops_enable_clkdm,
+ .disable= omap2_clkops_disable_clkdm,
+};
+
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names;
+ int i;
+
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return;
+ }
+
+ clk_hw-hw.init = init;
+
+ of_property_read_string(node, clock-output-names, clk_name);
+ of_property_read_string(node, ti,clkdm-name, clk_hw-clkdm_name);
+
+ init.name = clk_name;
+ init.ops = omap_gate_clk_ops;
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents 1) {
+ pr_err(%s: omap trace_clk %s must have parent(s)\n,
+ __func__, node-name);
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+ for (i = 0; i num_parents; i++)
+ parent_names[i] = of_clk_get_parent_name(node, i);
+
+ init.num_parents = num_parents;
+ init.parent_names = parent_names;
+
+ clk = clk_register(NULL, clk_hw-hw);
+
+ if (!IS_ERR(clk)) {
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ return;
+ }
+
+cleanup:
+ kfree(clk_hw);
+}
+EXPORT_SYMBOL(of_omap_gate_clk_setup);
+CLK_OF_DECLARE(omap_gate_clk, ti,omap-gate-clock, of_omap_gate_clk_setup);
+#endif
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 904bdad..58ebb80 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -194,6 +194,7 @@ extern void omap_dt_clocks_register(struct omap_dt_clk
*oclks, int cnt);
void of_omap4_dpll_setup(struct device_node *node);
void of_omap_fixed_factor_setup(struct device_node *node);
void of_omap_divider_setup(struct device_node *node);
+void of_omap_gate_clk_setup(struct device_node *node);
void of_omap_clk_allow_autoidle_all(void);
void of_omap_clk_deny_autoidle_all(void);
--
1.7.9.5
--
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
[PATCHv4 01/33] CLK: clkdev: add support for looking up clocks from DT
clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
is found, an entry is added to the clk_lookup list also for subsequent
searches.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Russell King li...@arm.linux.org.uk
---
drivers/clk/clkdev.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..e39f082 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node *np, const
char *name)
EXPORT_SYMBOL(of_clk_get_by_name);
#endif
+/**
+ * clkdev_add_nolock - add lookup entry for a clock
+ * @cl: pointer to new clock lookup entry
+ *
+ * Non-locking version, used internally by clk_find() to add DT based
+ * clock lookup entries.
+ */
+static void clkdev_add_nolock(struct clk_lookup *cl)
+{
+ list_add_tail(cl-node, clocks);
+}
+
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy matching here:
@@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
{
struct clk_lookup *p, *cl = NULL;
int match, best_found = 0, best_possible = 0;
+ struct device_node *node;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
if (dev_id)
best_possible += 2;
@@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
break;
}
}
+
+ if (cl)
+ return cl;
+
+ /* If clock was not found, attempt to look-up from DT */
+ node = of_find_node_by_name(NULL, con_id);
+
+ clkspec.np = node;
+
+ clk = of_clk_get_from_provider(clkspec);
+
+ if (!IS_ERR(clk)) {
+ /* We found a clock, add node to clkdev */
+ cl = clkdev_alloc(clk, con_id, dev_id);
+ clkdev_add_nolock(cl);
+ }
+
return cl;
}
--
1.7.9.5
--
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
[PATCHv4 03/33] CLK: OMAP4: Add DPLL clock support
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/dpll.c | 295 +
3 files changed, 297 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/dpll.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 8195931..4cad480 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o
+obj-y += clk.o dpll.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 4bf1929..1dafdaa 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -28,6 +28,7 @@ static const struct of_device_id clk_match[] = {
.data = of_fixed_factor_clk_setup, },
{.compatible = divider-clock, .data = of_divider_clk_setup, },
{.compatible = gate-clock, .data = of_gate_clk_setup, },
+ {.compatible = ti,omap4-dpll-clock, .data = of_omap4_dpll_setup, },
{},
};
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
new file mode 100644
index 000..66e82be
--- /dev/null
+++ b/drivers/clk/omap/dpll.c
@@ -0,0 +1,295 @@
+/*
+ * OMAP DPLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/omap.h
+
+static const struct clk_ops dpll_m4xen_ck_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .recalc_rate= omap4_dpll_regm4xen_recalc,
+ .round_rate = omap4_dpll_regm4xen_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_core_ck_ops = {
+ .recalc_rate= omap3_dpll_recalc,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_ck_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .recalc_rate= omap3_dpll_recalc,
+ .round_rate = omap2_dpll_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .get_parent = omap2_init_dpll_parent,
+ .init = omap2_init_clk_clkdm,
+};
+
+static const struct clk_ops dpll_x2_ck_ops = {
+ .recalc_rate= omap3_clkoutx2_recalc,
+};
+
+struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
+ const char **parent_names, int num_parents, unsigned long flags,
+ struct dpll_data *dpll_data, const char *clkdm_name,
+ const struct clk_ops *ops)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+
+ /* allocate the divider */
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ clk_hw-dpll_data = dpll_data;
+ clk_hw-ops = clkhwops_omap3_dpll;
+ clk_hw-clkdm_name = clkdm_name;
+ clk_hw-hw.init = init;
+
+ init.name = name;
+ init.ops = ops;
+ init.flags = flags;
+ init.parent_names = parent_names;
+ init.num_parents = num_parents;
+
+ /* register the clock */
+ clk = clk_register(dev, clk_hw-hw);
+
+ if (IS_ERR(clk))
+ kfree(clk_hw);
+ else
+ omap2_init_clk_hw_omap_clocks(clk);
+
+ return clk;
+}
+
+struct clk *omap_clk_register_dpll_x2(struct device *dev, const char *name,
+ const char *parent_name, void __iomem *reg,
+ const struct clk_ops *ops)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+
+ if (!parent_name) {
+ pr_err(%s: dpll_x2 must have parent\n, __func__);
+ return ERR_PTR(-EINVAL);
+ }
+
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return
[PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
Some of the clock.h contents are needed by the new OMAP clock driver,
including dpll_data and clk_hw_omap. Thus, move these to the generic
omap header file which can be accessed by the driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.h | 151 +
include/linux/clk/omap.h| 157 ++-
2 files changed, 157 insertions(+), 151 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..d1a3125 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -21,6 +21,7 @@
#include linux/clkdev.h
#include linux/clk-provider.h
+#include linux/clk/omap.h
struct omap_clk {
u16 cpu;
@@ -178,83 +179,6 @@ struct clksel {
const struct clksel_rate *rates;
};
-/**
- * struct dpll_data - DPLL registers and integration data
- * @mult_div1_reg: register containing the DPLL M and N bitfields
- * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
- * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
- * @clk_bypass: struct clk pointer to the clock's bypass clock input
- * @clk_ref: struct clk pointer to the clock's reference clock input
- * @control_reg: register containing the DPLL mode bitfield
- * @enable_mask: mask of the DPLL mode bitfield in @control_reg
- * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
- * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
- * @last_rounded_m4xen: cache of the last M4X result of
- * omap4_dpll_regm4xen_round_rate()
- * @last_rounded_lpmode: cache of the last lpmode result of
- * omap4_dpll_lpmode_recalc()
- * @max_multiplier: maximum valid non-bypass multiplier value (actual)
- * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
- * @min_divider: minimum valid non-bypass divider value (actual)
- * @max_divider: maximum valid non-bypass divider value (actual)
- * @modes: possible values of @enable_mask
- * @autoidle_reg: register containing the DPLL autoidle mode bitfield
- * @idlest_reg: register containing the DPLL idle status bitfield
- * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
- * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
- * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
- * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
- * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
- * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
- * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
- * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
- * @flags: DPLL type/features (see below)
- *
- * Possible values for @flags:
- * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs)
- *
- * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
- *
- * XXX Some DPLLs have multiple bypass inputs, so it's not technically
- * correct to only have one @clk_bypass pointer.
- *
- * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
- * @last_rounded_n) should be separated from the runtime-fixed fields
- * and placed into a different structure, so that the runtime-fixed data
- * can be placed into read-only space.
- */
-struct dpll_data {
- void __iomem*mult_div1_reg;
- u32 mult_mask;
- u32 div1_mask;
- struct clk *clk_bypass;
- struct clk *clk_ref;
- void __iomem*control_reg;
- u32 enable_mask;
- unsigned long last_rounded_rate;
- u16 last_rounded_m;
- u8 last_rounded_m4xen;
- u8 last_rounded_lpmode;
- u16 max_multiplier;
- u8 last_rounded_n;
- u8 min_divider;
- u16 max_divider;
- u8 modes;
- void __iomem*autoidle_reg;
- void __iomem*idlest_reg;
- u32 autoidle_mask;
- u32 freqsel_mask;
- u32 idlest_mask;
- u32 dco_mask;
- u32 sddiv_mask;
- u32 lpmode_mask;
- u32 m4xen_mask;
- u8 auto_recal_bit;
- u8 recal_en_bit;
- u8 recal_st_bit;
- u8 flags;
-};
-
/*
* struct clk.flags possibilities
*
@@ -274,56 +198,6 @@ struct dpll_data {
#define INVERT_ENABLE (1 4)/* 0 enables, 1 disables */
#define CLOCK_CLKOUTX2 (1 5)
[PATCHv4 14/33] CLK: omap: add dra7 clock init file
clk-7xx.c now contains the clock init functionality for dra7, including
DT clock registration and adding of static clkdev entries.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk-7xx.c | 67
2 files changed, 68 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/clk-7xx.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 74385f2..b8dbfda 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,2 +1,2 @@
obj-y += clk.o dpll.o autoidle.o gate.o \
- clk-44xx.o clk-54xx.o
+ clk-44xx.o clk-54xx.o clk-7xx.o
diff --git a/drivers/clk/omap/clk-7xx.c b/drivers/clk/omap/clk-7xx.c
new file mode 100644
index 000..ddb39dd
--- /dev/null
+++ b/drivers/clk/omap/clk-7xx.c
@@ -0,0 +1,67 @@
+/*
+ * DRA7 Clock init
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo (t-kri...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
+#include linux/clk-private.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk/omap.h
+
+#define DRA7_DPLL_ABE_DEFFREQ 361267200
+#define DRA7_DPLL_GMAC_DEFFREQ 10
+
+
+static struct omap_dt_clk dra7xx_clks[] = {
+ DT_CLK(NULL, timer_32k_ck, sys_32k_ck),
+ DT_CLK(4ae18000.timer, timer_sys_ck, sys_clkin2),
+ DT_CLK(48032000.timer, timer_sys_ck, sys_clkin2),
+ DT_CLK(48034000.timer, timer_sys_ck, sys_clkin2),
+ DT_CLK(48036000.timer, timer_sys_ck, sys_clkin2),
+ DT_CLK(4803e000.timer, timer_sys_ck, sys_clkin2),
+ DT_CLK(48086000.timer, timer_sys_ck, sys_clkin2),
+ DT_CLK(48088000.timer, timer_sys_ck, sys_clkin2),
+ DT_CLK(4882.timer, timer_sys_ck, timer_sys_clk_div),
+ DT_CLK(48822000.timer, timer_sys_ck, timer_sys_clk_div),
+ DT_CLK(48824000.timer, timer_sys_ck, timer_sys_clk_div),
+ DT_CLK(48826000.timer, timer_sys_ck, timer_sys_clk_div),
+ DT_CLK(NULL, sys_clkin, sys_clkin1),
+};
+
+int __init dra7xx_clk_init(void)
+{
+ int rc;
+ struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+
+ dt_omap_clk_init();
+
+ omap_dt_clocks_register(dra7xx_clks, ARRAY_SIZE(dra7xx_clks));
+
+ omap2_clk_disable_autoidle_all();
+
+ abe_dpll_mux = clk_get_sys(NULL, abe_dpll_sys_clk_mux);
+ sys_clkin2 = clk_get_sys(NULL, sys_clkin2);
+ dpll_ck = clk_get_sys(NULL, dpll_abe_ck);
+
+ rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
+ if (!rc)
+ rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure ABE DPLL!\n, __func__);
+
+ dpll_ck = clk_get_sys(NULL, dpll_gmac_ck);
+ rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure GMAC DPLL!\n, __func__);
+
+ return rc;
+}
--
1.7.9.5
--
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
[PATCHv4 21/33] CLK: OMAP: DPLL: add omap3 dpll support
OMAP3 has slightly different DPLLs from those compared to OMAP4. Modified
code for the same.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/dpll.c | 96 +--
1 file changed, 85 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
index d8a958a..ecb1fbd 100644
--- a/drivers/clk/omap/dpll.c
+++ b/drivers/clk/omap/dpll.c
@@ -26,6 +26,11 @@
#include linux/of_address.h
#include linux/clk/omap.h
+enum {
+ SUBTYPE_OMAP3_DPLL,
+ SUBTYPE_OMAP4_DPLL,
+};
+
static const struct clk_ops dpll_m4xen_ck_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
@@ -40,6 +45,13 @@ static const struct clk_ops dpll_core_ck_ops = {
.get_parent = omap2_init_dpll_parent,
};
+static const struct clk_ops omap3_dpll_core_ck_ops = {
+ .init = omap2_init_clk_clkdm,
+ .get_parent = omap2_init_dpll_parent,
+ .recalc_rate= omap3_dpll_recalc,
+ .round_rate = omap2_dpll_round_rate,
+};
+
static const struct clk_ops dpll_ck_ops = {
.enable = omap3_noncore_dpll_enable,
.disable= omap3_noncore_dpll_disable,
@@ -50,6 +62,26 @@ static const struct clk_ops dpll_ck_ops = {
.init = omap2_init_clk_clkdm,
};
+static const struct clk_ops omap3_dpll_ck_ops = {
+ .init = omap2_init_clk_clkdm,
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .get_parent = omap2_init_dpll_parent,
+ .recalc_rate= omap3_dpll_recalc,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .round_rate = omap2_dpll_round_rate,
+};
+
+static const struct clk_ops omap3_dpll_per_ck_ops = {
+ .init = omap2_init_clk_clkdm,
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .get_parent = omap2_init_dpll_parent,
+ .recalc_rate= omap3_dpll_recalc,
+ .set_rate = omap3_dpll4_set_rate,
+ .round_rate = omap2_dpll_round_rate,
+};
+
static const struct clk_ops dpll_x2_ck_ops = {
.recalc_rate= omap3_clkoutx2_recalc,
};
@@ -144,7 +176,9 @@ struct clk *omap_clk_register_dpll_x2(struct device *dev,
const char *name,
* of_omap_dpll_setup() - Setup function for OMAP DPLL clocks
*/
static void __init of_omap_dpll_setup(struct device_node *node,
- const struct clk_ops *ops)
+ const struct clk_ops *ops, u32 freqsel,
+ u32 modes, u8 mul_div_shift,
+ int subtype)
{
struct clk *clk;
const char *clk_name = node-name;
@@ -157,8 +191,8 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
u32 idlest_mask = 0x1;
u32 enable_mask = 0x7;
u32 autoidle_mask = 0x7;
- u32 mult_mask = 0x7ff 8;
- u32 div1_mask = 0x7f;
+ u32 mult_mask = 0x7ff (8 + mul_div_shift);
+ u32 div1_mask = 0x7f mul_div_shift;
u32 max_multiplier = 2047;
u32 max_divider = 128;
u32 min_divider = 1;
@@ -193,7 +227,7 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
clkspec.np = of_parse_phandle(node, ti,clk-ref, 0);
dd-clk_ref = of_clk_get_from_provider(clkspec);
- if (!dd-clk_ref) {
+ if (IS_ERR(dd-clk_ref)) {
pr_err(%s: ti,clk-ref for %s not found\n, __func__,
clk_name);
goto cleanup;
@@ -201,7 +235,7 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
clkspec.np = of_parse_phandle(node, ti,clk-bypass, 0);
dd-clk_bypass = of_clk_get_from_provider(clkspec);
- if (!dd-clk_bypass) {
+ if (IS_ERR(dd-clk_bypass)) {
pr_err(%s: ti,clk-bypass for %s not found\n, __func__,
clk_name);
goto cleanup;
@@ -225,14 +259,31 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
dd-enable_mask = enable_mask;
dd-autoidle_mask = autoidle_mask;
- dd-modes = 0xa0;
+ if (!of_property_read_u32(node, ti,recal-en-bit, val))
+ dd-recal_en_bit = val;
+
+ if (!of_property_read_u32(node, ti,recal-st-bit, val))
+ dd-recal_st_bit = val;
+
+ if (!of_property_read_u32(node, ti,auto-recal-bit, val))
+ dd-auto_recal_bit = val;
+
+ of_property_read_u32(node, ti,modes, modes);
+
+ dd-modes = modes;
+
+ dd-freqsel_mask = freqsel;
if (of_property_read_bool(node, ti,dpll-j-type)) {
dd-sddiv_mask = 0xff00;
- mult_mask = 0xfff 8;
- div1_mask = 0xff;
+ mult_mask = 0xfff (8 + mul_div_shift);
[PATCHv4 17/33] CLK: DT: add support for set-rate-parent flag
Adding set-rate-parent to clock node now allows a node to forward
clk_set_rate request to its parent clock.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk-divider.c |6 +-
drivers/clk/clk-fixed-factor.c |6 +-
drivers/clk/clk-gate.c |8 ++--
drivers/clk/clk-mux.c |6 +-
4 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index ff24ec2..01d967f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -388,6 +388,7 @@ void of_divider_clk_setup(struct device_node *node)
u32 mask = 0;
u32 shift = 0;
struct clk_div_table *table;
+ u32 flags = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -418,12 +419,15 @@ void of_divider_clk_setup(struct device_node *node)
if (of_property_read_bool(node, hiword-mask))
clk_divider_flags |= CLK_DIVIDER_HIWORD_MASK;
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
table = of_clk_get_div_table(node);
if (IS_ERR(table))
return;
clk = _register_divider(NULL, clk_name,
- parent_name, 0,
+ parent_name, flags,
reg, (u8) shift, mask,
clk_divider_flags, table,
NULL);
diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
index 9ff7d51..30aa121 100644
--- a/drivers/clk/clk-fixed-factor.c
+++ b/drivers/clk/clk-fixed-factor.c
@@ -107,6 +107,7 @@ void __init of_fixed_factor_clk_setup(struct device_node
*node)
const char *clk_name = node-name;
const char *parent_name;
u32 div, mult;
+ u32 flags = 0;
if (of_property_read_u32(node, clock-div, div)) {
pr_err(%s Fixed factor clock %s must have a clock-div
property\n,
@@ -123,7 +124,10 @@ void __init of_fixed_factor_clk_setup(struct device_node
*node)
of_property_read_string(node, clock-output-names, clk_name);
parent_name = of_clk_get_parent_name(node, 0);
- clk = clk_register_fixed_factor(NULL, clk_name, parent_name, 0,
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
+ clk = clk_register_fixed_factor(NULL, clk_name, parent_name, flags,
mult, div);
if (!IS_ERR(clk))
of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index cd595ec..0be25b9 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -176,6 +176,7 @@ void of_gate_clk_setup(struct device_node *node)
const char *parent_name;
u8 clk_gate_flags = 0;
u32 bit_idx = 0;
+ u32 flags = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -195,8 +196,11 @@ void of_gate_clk_setup(struct device_node *node)
if (of_property_read_bool(node, hiword-mask))
clk_gate_flags |= CLK_GATE_HIWORD_MASK;
- clk = clk_register_gate(NULL, clk_name, parent_name, 0, reg, (u8)
bit_idx,
- clk_gate_flags, NULL);
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
+ clk = clk_register_gate(NULL, clk_name, parent_name, flags, reg,
+ (u8) bit_idx, clk_gate_flags, NULL);
if (!IS_ERR(clk))
of_clk_add_provider(node, of_clk_src_simple_get, clk);
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 4751bce..890ddbf 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -184,6 +184,7 @@ void of_mux_clk_setup(struct device_node *node)
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
+ u32 flags = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -219,8 +220,11 @@ void of_mux_clk_setup(struct device_node *node)
if (of_property_read_bool(node, hiword-mask))
clk_mux_flags |= CLK_MUX_HIWORD_MASK;
+ if (of_property_read_bool(node, set-rate-parent))
+ flags |= CLK_SET_RATE_PARENT;
+
clk = clk_register_mux_table(NULL, clk_name, parent_names, num_parents,
- 0, reg, (u8) shift, mask, clk_mux_flags,
+ flags, reg, (u8) shift, mask, clk_mux_flags,
NULL, NULL);
if (!IS_ERR(clk))
--
1.7.9.5
--
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
[PATCHv4 18/33] ARM: dts: am33xx clock data
This patch creates a unique node for each clock in the AM33xx power,
reset and clock manager (PRCM).
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/am33xx-clocks.dtsi | 663 ++
arch/arm/boot/dts/am33xx.dtsi|7 +
2 files changed, 670 insertions(+)
create mode 100644 arch/arm/boot/dts/am33xx-clocks.dtsi
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
new file mode 100644
index 000..1b19443
--- /dev/null
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -0,0 +1,663 @@
+/*
+ * Device Tree Source for AM33xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+clk_32768_ck: clk_32768_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+clk_rc32k_ck: clk_rc32k_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32000;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1920;
+};
+
+virt_2400_ck: virt_2400_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2400;
+};
+
+virt_2500_ck: virt_2500_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2500;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2600;
+};
+
+sys_clkin_ck: sys_clkin_ck@44e10040 {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = virt_1920_ck, virt_2400_ck, virt_2500_ck,
virt_2600_ck;
+ bit-shift = 22;
+ reg = 0x44e10040 0x4;
+ bit-mask = 0x3;
+};
+
+tclkin_ck: tclkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+dpll_core_ck: dpll_core_ck@44e00490 {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-clock;
+ clocks = sys_clkin_ck;
+ reg = 0x44e00490 0x4, 0x44e0045c 0x4, 0x0 0x4, 0x44e00468 0x4;
+ ti,clk-ref = sys_clkin_ck;
+ ti,clk-bypass = sys_clkin_ck;
+ ti,dpll-core;
+};
+
+dpll_core_x2_ck: dpll_core_x2_ck {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-clock;
+ clocks = dpll_core_ck;
+ ti,dpll-clk-x2;
+};
+
+dpll_core_m4_ck: dpll_core_m4_ck@44e00480 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_core_x2_ck;
+ reg = 0x44e00480 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
+dpll_core_m5_ck: dpll_core_m5_ck@44e00484 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_core_x2_ck;
+ reg = 0x44e00484 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
+dpll_core_m6_ck: dpll_core_m6_ck@44e004d8 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_core_x2_ck;
+ reg = 0x44e004d8 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
+dpll_mpu_ck: dpll_mpu_ck@44e00488 {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-clock;
+ clocks = sys_clkin_ck;
+ reg = 0x44e00488 0x4, 0x44e00420 0x4, 0x0 0x4, 0x44e0042c 0x4;
+ ti,clk-ref = sys_clkin_ck;
+ ti,clk-bypass = sys_clkin_ck;
+};
+
+dpll_mpu_m2_ck: dpll_mpu_m2_ck@44e004a8 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_mpu_ck;
+ reg = 0x44e004a8 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
+dpll_ddr_ck: dpll_ddr_ck@44e00494 {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-clock;
+ clocks = sys_clkin_ck;
+ reg = 0x44e00494 0x4, 0x44e00434 0x4, 0x0 0x4, 0x44e00440 0x4;
+ ti,clk-ref = sys_clkin_ck;
+ ti,clk-bypass = sys_clkin_ck;
+ ti,dpll-no-gate;
+};
+
+dpll_ddr_m2_ck: dpll_ddr_m2_ck@44e004a0 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_ddr_ck;
+ reg = 0x44e004a0 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+};
+
+dpll_ddr_m2_div2_ck: dpll_ddr_m2_div2_ck {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = dpll_ddr_m2_ck;
+ clock-mult = 1;
+ clock-div = 2;
+};
+
+dpll_disp_ck: dpll_disp_ck@44e00498 {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-clock;
+ clocks = sys_clkin_ck;
+ reg = 0x44e00498 0x4, 0x44e00448 0x4, 0x0 0x4, 0x44e00454 0x4;
+ ti,clk-ref = sys_clkin_ck;
+ ti,clk-bypass = sys_clkin_ck;
+ ti,dpll-no-gate;
+};
+
+dpll_disp_m2_ck: dpll_disp_m2_ck@44e004a4 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_disp_ck;
+ reg = 0x44e004a4 0x4;
+
[PATCHv4 22/33] CLK: OMAP: update gate clock setup for OMAP3
OMAP3 gate clocks are handled through the clk driver now. Basic gate
clock can't be used as the OMAP3 gate clocks have some special features,
namely the idle status linkage which is on separate register.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/gate.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
index 7186bb2..b560ff4 100644
--- a/drivers/clk/omap/gate.c
+++ b/drivers/clk/omap/gate.c
@@ -28,12 +28,19 @@
#ifdef CONFIG_OF
-static const struct clk_ops omap_gate_clk_ops = {
+static const struct clk_ops omap_gate_clkdm_clk_ops = {
.init = omap2_init_clk_clkdm,
.enable = omap2_clkops_enable_clkdm,
.disable= omap2_clkops_disable_clkdm,
};
+static const struct clk_ops omap_gate_clk_ops = {
+ .init = omap2_init_clk_clkdm,
+ .enable = omap2_dflt_clk_enable,
+ .disable= omap2_dflt_clk_disable,
+ .is_enabled = omap2_dflt_clk_is_enabled,
+};
+
void __init of_omap_gate_clk_setup(struct device_node *node)
{
struct clk *clk;
@@ -43,6 +50,7 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
int num_parents;
const char **parent_names;
int i;
+ u32 val;
clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
if (!clk_hw) {
@@ -56,7 +64,22 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
of_property_read_string(node, ti,clkdm-name, clk_hw-clkdm_name);
init.name = clk_name;
- init.ops = omap_gate_clk_ops;
+ init.flags = 0;
+
+ if (of_property_read_u32_index(node, reg, 0, val)) {
+ /* No register, clkdm control only */
+ init.ops = omap_gate_clkdm_clk_ops;
+ } else {
+ init.ops = omap_gate_clk_ops;
+ clk_hw-enable_reg = of_iomap(node, 0);
+ of_property_read_u32(node, ti,enable-bit, val);
+ clk_hw-enable_bit = val;
+
+ if (of_property_read_bool(node, ti,dss-clk))
+ clk_hw-ops = clkhwops_omap3430es2_dss_usbhost_wait;
+ else
+ clk_hw-ops = clkhwops_wait;
+ }
num_parents = of_clk_get_parent_count(node);
if (num_parents 1) {
--
1.7.9.5
--
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
[PATCHv4 12/33] CLK: omap: add omap5 clock init file
clk-54xx.c now contains the clock init functionality for omap5, including
DT clock registration and adding of static clkdev entries.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk-54xx.c | 58 +++
2 files changed, 59 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/clk-54xx.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 9ad10be..74385f2 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,2 +1,2 @@
obj-y += clk.o dpll.o autoidle.o gate.o \
- clk-44xx.o
+ clk-44xx.o clk-54xx.o
diff --git a/drivers/clk/omap/clk-54xx.c b/drivers/clk/omap/clk-54xx.c
new file mode 100644
index 000..ade0481
--- /dev/null
+++ b/drivers/clk/omap/clk-54xx.c
@@ -0,0 +1,58 @@
+/*
+ * OMAP5 Clock init
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo (t-kri...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
+#include linux/clk-private.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk/omap.h
+
+#define OMAP5_DPLL_ABE_DEFFREQ 98304000
+
+static struct omap_dt_clk omap54xx_clks[] = {
+ DT_CLK(NULL, timer_32k_ck, sys_32k_ck),
+ DT_CLK(omap_timer.1, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.2, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.3, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.4, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.9, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.10, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.11, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.5, sys_ck, dss_syc_gfclk_div),
+ DT_CLK(omap_timer.6, sys_ck, dss_syc_gfclk_div),
+ DT_CLK(omap_timer.7, sys_ck, dss_syc_gfclk_div),
+ DT_CLK(omap_timer.8, sys_ck, dss_syc_gfclk_div),
+};
+
+int __init omap5xxx_clk_init(void)
+{
+ int rc;
+ struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck;
+
+ dt_omap_clk_init();
+
+ omap_dt_clocks_register(omap54xx_clks, ARRAY_SIZE(omap54xx_clks));
+
+ omap2_clk_disable_autoidle_all();
+
+ abe_dpll_ref = clk_get_sys(NULL, abe_dpll_clk_mux);
+ sys_32k_ck = clk_get_sys(NULL, sys_32k_ck);
+ rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+ abe_dpll = clk_get_sys(NULL, dpll_abe_ck);
+ if (!rc)
+ rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure ABE DPLL!\n, __func__);
+
+ return 0;
+}
--
1.7.9.5
--
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
[PATCHv4 11/33] ARM: dts: omap5 clock data
This patch creates a unique node for each clock in the OMAP5 power,
reset and clock manager (PRCM).
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 1416
1 file changed, 1416 insertions(+)
create mode 100644 arch/arm/boot/dts/omap54xx-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
new file mode 100644
index 000..391edee
--- /dev/null
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -0,0 +1,1416 @@
+/*
+ * Device Tree Source for OMAP5 clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+pad_clks_ck: pad_clks_ck@4a004108 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = pad_clks_src_ck;
+ bit-shift = 8;
+ reg = 0x4a004108 0x4;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+slimbus_src_clk: slimbus_src_clk {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+slimbus_clk: slimbus_clk@4a004108 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = slimbus_src_clk;
+ bit-shift = 10;
+ reg = 0x4a004108 0x4;
+};
+
+sys_32k_ck: sys_32k_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+virt_1200_ck: virt_1200_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+virt_1300_ck: virt_1300_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1300;
+};
+
+virt_1680_ck: virt_1680_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1680;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1920;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2600;
+};
+
+virt_2700_ck: virt_2700_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2700;
+};
+
+virt_3840_ck: virt_3840_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 3840;
+};
+
+sys_clkin: sys_clkin@4ae06110 {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = virt_1200_ck, virt_1300_ck, virt_1680_ck,
virt_1920_ck, virt_2600_ck, virt_2700_ck,
virt_3840_ck;
+ reg = 0x4ae06110 0x4;
+ bit-mask = 0x7;
+ index-starts-at-one;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+abe_dpll_bypass_clk_mux: abe_dpll_bypass_clk_mux@4ae06108 {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = sys_clkin, sys_32k_ck;
+ reg = 0x4ae06108 0x4;
+ bit-mask = 0x1;
+};
+
+abe_dpll_clk_mux: abe_dpll_clk_mux@4ae0610c {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = sys_clkin, sys_32k_ck;
+ reg = 0x4ae0610c 0x4;
+ bit-mask = 0x1;
+};
+
+dpll_abe_ck: dpll_abe_ck@4a0041e0 {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-clock;
+ clocks = abe_dpll_clk_mux, abe_dpll_bypass_clk_mux;
+ reg = 0x4a0041e0 0x4, 0x4a0041e4 0x4, 0x4a0041e8 0x4, 0x4a0041ec
0x4;
+ ti,clk-ref = abe_dpll_clk_mux;
+ ti,clk-bypass = abe_dpll_bypass_clk_mux;
+ ti,dpll-regm4xen;
+};
+
+dpll_abe_x2_ck: dpll_abe_x2_ck {
+ #clock-cells = 0;
+ compatible = ti,omap4-dpll-clock;
+ clocks = dpll_abe_ck;
+ ti,dpll-clk-x2;
+};
+
+dpll_abe_m2x2_ck: dpll_abe_m2x2_ck@4a0041f0 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_abe_x2_ck;
+ ti,autoidle-shift = 8;
+ reg = 0x4a0041f0 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+ ti,autoidle-low;
+};
+
+abe_24m_fclk: abe_24m_fclk {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = dpll_abe_m2x2_ck;
+ clock-mult = 1;
+ clock-div = 8;
+};
+
+abe_clk: abe_clk@4a004108 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_abe_m2x2_ck;
+ reg = 0x4a004108 0x4;
+ bit-mask = 0x3;
+ index-power-of-two;
+};
+
+abe_iclk:
[PATCHv4 16/33] CLK: OMAP: DPLL: do not of_iomap NULL autoidle register
AM33xx series SoCs do not have autoidle support, and for these the autoidle register is marked as NULL. Check against a NULL pointer and do not attempt to of_iomap in this case, as this just creates a bogus pointer and causes a kernel crash during boot. Signed-off-by: Tero Kristo t-kri...@ti.com --- drivers/clk/omap/dpll.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c index 1d24feada..d8a958a 100644 --- a/drivers/clk/omap/dpll.c +++ b/drivers/clk/omap/dpll.c @@ -162,6 +162,7 @@ static void __init of_omap_dpll_setup(struct device_node *node, u32 max_multiplier = 2047; u32 max_divider = 128; u32 min_divider = 1; + u32 val; int i; dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL); @@ -210,7 +211,14 @@ static void __init of_omap_dpll_setup(struct device_node *node, dd-control_reg = of_iomap(node, 0); dd-idlest_reg = of_iomap(node, 1); - dd-autoidle_reg = of_iomap(node, 2); + /* +* AM33xx DPLLs have no autoidle support, and the autoidle reg +* for these is NULL. Do not attempt to of_iomap in this case, +* as this just creates a bogus pointer and crashes the kernel. +*/ + of_property_read_u32_index(node, reg, 2 * 2, val); + if (val) + dd-autoidle_reg = of_iomap(node, 2); dd-mult_div1_reg = of_iomap(node, 3); dd-idlest_mask = idlest_mask; -- 1.7.9.5 -- 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
[PATCHv4 15/33] CLK: OMAP: DPLL: add support for DT property ti,dpll-no-gate
AM335x has DPLL clocks that should never be attempted to be gated. Adding
ti,dpll-no-gate property for them handles this situation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/dpll.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
index 66e82be..1d24feada 100644
--- a/drivers/clk/omap/dpll.c
+++ b/drivers/clk/omap/dpll.c
@@ -54,6 +54,13 @@ static const struct clk_ops dpll_x2_ck_ops = {
.recalc_rate= omap3_clkoutx2_recalc,
};
+static const struct clk_ops dpll_no_gate_ck_ops = {
+ .recalc_rate= omap3_dpll_recalc,
+ .get_parent = omap2_init_dpll_parent,
+ .round_rate = omap2_dpll_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+};
+
struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
const char **parent_names, int num_parents, unsigned long flags,
struct dpll_data *dpll_data, const char *clkdm_name,
@@ -288,6 +295,9 @@ __init void of_omap4_dpll_setup(struct device_node *node)
return;
}
+ if (of_property_read_bool(node, ti,dpll-no-gate))
+ ops = dpll_no_gate_ck_ops;
+
of_omap_dpll_setup(node, ops);
}
EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
--
1.7.9.5
--
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
[PATCHv4 26/33] CLK: omap: gate: add support for OMAP36xx dpllx_mx_ck:s
OMAP3630 dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
dpll4_m5_ck dpll4_m6_ck dividers gets loaded with reset
value after their respective PWRDN bits are set. Any dummy write
(Any other value different from the Read value) to the
corresponding CM_CLKSEL register will refresh the dividers.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/gate.c | 57 ++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
index b560ff4..50c7f2e 100644
--- a/drivers/clk/omap/gate.c
+++ b/drivers/clk/omap/gate.c
@@ -28,6 +28,10 @@
#ifdef CONFIG_OF
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+static int omap36xx_gate_clk_enable_with_hsdiv_restore(struct clk_hw *clk);
+
static const struct clk_ops omap_gate_clkdm_clk_ops = {
.init = omap2_init_clk_clkdm,
.enable = omap2_clkops_enable_clkdm,
@@ -41,6 +45,54 @@ static const struct clk_ops omap_gate_clk_ops = {
.is_enabled = omap2_dflt_clk_is_enabled,
};
+static const struct clk_ops omap_gate_clk_hsdiv_restore_ops = {
+ .init = omap2_init_clk_clkdm,
+ .enable = omap36xx_gate_clk_enable_with_hsdiv_restore,
+ .disable= omap2_dflt_clk_disable,
+ .is_enabled = omap2_dflt_clk_is_enabled,
+};
+
+/**
+ * omap36xx_gate_clk_enable_with_hsdiv_restore - enable clocks suffering
+ * from HSDivider PWRDN problem Implements Errata ID: i556.
+ * @clk: DPLL output struct clk
+ *
+ * 3630 only: dpll3_m3_ck, dpll4_m2_ck, dpll4_m3_ck, dpll4_m4_ck,
+ * dpll4_m5_ck dpll4_m6_ck dividers gets loaded with reset
+ * valueafter their respective PWRDN bits are set. Any dummy write
+ * (Any other value different from the Read value) to the
+ * corresponding CM_CLKSEL register will refresh the dividers.
+ */
+static int omap36xx_gate_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
+{
+ struct clk_divider *parent;
+ struct clk_hw *parent_hw;
+ u32 dummy_v, orig_v;
+ int ret;
+
+ /* Clear PWRDN bit of HSDIVIDER */
+ ret = omap2_dflt_clk_enable(clk);
+
+ /* Parent is the x2 node, get parent of parent for the m2 div */
+ parent_hw = __clk_get_hw(__clk_get_parent(__clk_get_parent(clk-clk)));
+ parent = to_clk_divider(parent_hw);
+
+ /* Restore the dividers */
+ if (!ret) {
+ orig_v = __raw_readl(parent-reg);
+ dummy_v = orig_v;
+
+ /* Write any other value different from the Read value */
+ dummy_v ^= (1 parent-shift);
+ __raw_writel(dummy_v, parent-reg);
+
+ /* Write the original divider */
+ __raw_writel(orig_v, parent-reg);
+ }
+
+ return ret;
+}
+
void __init of_omap_gate_clk_setup(struct device_node *node)
{
struct clk *clk;
@@ -70,7 +122,10 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
/* No register, clkdm control only */
init.ops = omap_gate_clkdm_clk_ops;
} else {
- init.ops = omap_gate_clk_ops;
+ if (of_property_read_bool(node, ti,hsdiv-restore))
+ init.ops = omap_gate_clk_hsdiv_restore_ops;
+ else
+ init.ops = omap_gate_clk_ops;
clk_hw-enable_reg = of_iomap(node, 0);
of_property_read_u32(node, ti,enable-bit, val);
clk_hw-enable_bit = val;
--
1.7.9.5
--
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
[PATCHv4 13/33] ARM: dts: dra7 clock data
This patch creates a unique node for each clock in the DRA7 power,
reset and clock manager (PRCM).
TODO: apll_pcie clock node is still a dummy in this version, and
proper support for the APLL should be added.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 2081 ++
1 file changed, 2081 insertions(+)
create mode 100644 arch/arm/boot/dts/dra7xx-clocks.dtsi
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
new file mode 100644
index 000..8477ff9
--- /dev/null
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -0,0 +1,2081 @@
+/*
+ * Device Tree Source for DRA7xx clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+atl_clkin0_ck: atl_clkin0_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+atl_clkin1_ck: atl_clkin1_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+atl_clkin2_ck: atl_clkin2_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+atlclkin3_ck: atlclkin3_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+hdmi_clkin_ck: hdmi_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+mlb_clkin_ck: mlb_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+mlbp_clkin_ck: mlbp_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+pciesref_acs_clk_ck: pciesref_acs_clk_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1;
+};
+
+ref_clkin0_ck: ref_clkin0_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+ref_clkin1_ck: ref_clkin1_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+ref_clkin2_ck: ref_clkin2_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+ref_clkin3_ck: ref_clkin3_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+rmii_clk_ck: rmii_clk_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+sdvenc_clkin_ck: sdvenc_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+sys_32k_ck: sys_32k_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+virt_1200_ck: virt_1200_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+virt_1300_ck: virt_1300_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1300;
+};
+
+virt_1680_ck: virt_1680_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1680;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1920;
+};
+
+virt_2000_ck: virt_2000_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2000;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2600;
+};
+
+virt_2700_ck: virt_2700_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2700;
+};
+
+virt_3840_ck: virt_3840_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 3840;
+};
+
+sys_clkin1: sys_clkin1@4ae06110 {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = virt_1200_ck, virt_2000_ck, virt_1680_ck,
virt_1920_ck, virt_2600_ck, virt_2700_ck,
virt_3840_ck;
+ reg = 0x4ae06110 0x4;
+ bit-mask = 0x7;
+ index-starts-at-one;
+};
+
+sys_clkin2: sys_clkin2 {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 22579200;
+};
+
+usb_otg_clkin_ck: usb_otg_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+video1_clkin_ck: video1_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+video1_m2_clkin_ck: video1_m2_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
[PATCHv4 30/33] clk: OMAP: DRA7: Add APLL support
From: Keerthy j-keer...@ti.com
The patch adds support for DRA7 PCIe APLL. The APLL
sources the optional functional clocks for PCIe module.
APLL stands for Analog PLL. This is different when comapred
with DPLL meaning Digital PLL, the phase detection is done
using an analog circuit.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/mach-omap2/clock.h |1 -
drivers/clk/omap/Makefile |3 +-
drivers/clk/omap/apll.c | 213 +++
drivers/clk/omap/clk.c |1 +
include/linux/clk/omap.h|3 +
5 files changed, 219 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/omap/apll.c
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 949d293..5f1c7d4 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -38,7 +38,6 @@ struct omap_clk {
}
struct clockdomain;
-#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
#define DEFINE_STRUCT_CLK(_name, _parent_array_name, _clkops_name) \
static struct clk _name = { \
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 85b0dc7..6bceb27 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,3 +1,4 @@
obj-y += clk.o dpll.o autoidle.o gate.o \
clk-44xx.o clk-54xx.o clk-7xx.o \
- clk-33xx.o interface.o clk-3xxx.o
+ clk-33xx.o interface.o clk-3xxx.o \
+ apll.o
diff --git a/drivers/clk/omap/apll.c b/drivers/clk/omap/apll.c
new file mode 100644
index 000..3a216b8
--- /dev/null
+++ b/drivers/clk/omap/apll.c
@@ -0,0 +1,213 @@
+/*
+ * OMAP APLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * J Keerthy j-keer...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/omap.h
+#include linux/delay.h
+
+#define APLL_FORCE_LOCK 0x1
+#define APLL_AUTO_IDLE 0x2
+#define MAX_APLL_WAIT_TRIES100
+
+int dra7_apll_enable(struct clk_hw *hw)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+ int r = 0, i = 0;
+ struct dpll_data *ad;
+ const char *clk_name;
+ u8 state = 1;
+ u32 v;
+
+ ad = clk-dpll_data;
+ if (!ad)
+ return -EINVAL;
+
+ clk_name = __clk_get_name(clk-hw.clk);
+
+ state = __ffs(ad-idlest_mask);
+
+ /* Check is already locked */
+ if ((__raw_readl(ad-idlest_reg) ad-idlest_mask) == state)
+ return r;
+
+ v = __raw_readl(ad-control_reg);
+ v = ~ad-enable_mask;
+ v |= APLL_FORCE_LOCK __ffs(ad-enable_mask);
+ __raw_writel(v, ad-control_reg);
+
+ state = __ffs(ad-idlest_mask);
+
+ while (((__raw_readl(ad-idlest_reg) ad-idlest_mask) != state)
+ i MAX_APLL_WAIT_TRIES) {
+ i++;
+ udelay(1);
+ }
+
+ if (i == MAX_APLL_WAIT_TRIES) {
+ pr_warn(clock: %s failed transition to '%s'\n,
+ clk_name, (state) ? locked : bypassed);
+ } else {
+ pr_debug(clock: %s transition to '%s' in %d loops\n,
+clk_name, (state) ? locked : bypassed, i);
+
+ r = 0;
+ }
+
+ return r;
+}
+
+void dra7_apll_disable(struct clk_hw *hw)
+{
+ struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+ struct dpll_data *ad;
+ u8 state = 1;
+ u32 v;
+
+ ad = clk-dpll_data;
+
+ state = __ffs(ad-idlest_mask);
+
+ v = __raw_readl(ad-control_reg);
+ v = ~ad-enable_mask;
+ v |= APLL_AUTO_IDLE __ffs(ad-enable_mask);
+ __raw_writel(v, ad-control_reg);
+}
+
+u8 dra7_init_apll_parent(struct clk_hw *hw)
+{
+ return 0;
+}
+
+static const struct clk_ops apll_ck_ops = {
+ .enable = dra7_apll_enable,
+ .disable= dra7_apll_disable,
+ .get_parent = dra7_init_apll_parent,
+};
+
+struct clk *omap_clk_register_apll(struct device *dev, const char *name,
+ const char **parent_names, int num_parents, unsigned long flags,
+ struct dpll_data *dpll_data, const char *clkdm_name,
+ const struct clk_ops *ops)
+{
[PATCHv4 27/33] ARM: OMAP3: hwmod: initialize clkdm from clkdm_name
DT clocks are mostly missing clkdm info now, and this causes an issue with
counter32k which makes its slave idlemode wrong and prevents core idle.
Fixed by initializing the hwmod clkdm pointers for omap3 also which makes
sure the clkdm flag matching logic works properly.
This patch also changes the return value for _init_clkdm to 0 for
incorrect clkdm_name, as this a warning, not a fatal error.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index a6a59bd..da26659 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1544,7 +1544,7 @@ static int _init_clkdm(struct omap_hwmod *oh)
if (!oh-clkdm) {
pr_warning(omap_hwmod: %s: could not associate to clkdm %s\n,
oh-name, oh-clkdm_name);
- return -EINVAL;
+ return 0;
}
pr_debug(omap_hwmod: %s: associated to clkdm %s\n,
@@ -4115,6 +4115,7 @@ void __init omap_hwmod_init(void)
soc_ops.assert_hardreset = _omap2_assert_hardreset;
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
+ soc_ops.init_clkdm = _init_clkdm;
} else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
--
1.7.9.5
--
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
[PATCHv4 25/33] ARM: OMAP: hwmod: fix an incorrect clk type cast with _get_clkdm
If the main clock for a hwmod is of basic clock type, it is illegal to type
cast this to clk_hw_omap and will result in bogus data. Fixed by checking
the clock flags before attempting the type cast.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5cc5123..a6a59bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -656,6 +656,8 @@ static struct clockdomain *_get_clkdm(struct omap_hwmod *oh)
if (oh-clkdm) {
return oh-clkdm;
} else if (oh-_clk) {
+ if (__clk_get_flags(oh-_clk) CLK_IS_BASIC)
+ return NULL;
clk = to_clk_hw_omap(__clk_get_hw(oh-_clk));
return clk-clkdm;
}
--
1.7.9.5
--
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
[PATCHv4 33/33] clk: DTS: DRA7: Add PCIe related clock nodes
From: Keerthy j-keer...@ti.com
This patch adds optfclk_pciephy_clk and optfclk_pciephy_div_clk
which are used by PCIe phy. It also adds a mux clock to choose
the source of optfclk_pciephy_div_clk clock.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index fcc14d4..32b9985 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2087,3 +2087,27 @@ vip3_gclk_mux: vip3_gclk_mux@4a009030 {
reg = 0x4a009030 0x4;
bit-mask = 0x1;
};
+
+optfclk_pciephy_div: optfclk_pciephy_div@4a00821c {
+ compatible = divider-clock;
+ clocks = apll_pcie_ck;
+ #clock-cells = 0;
+ reg = 0x4a00821c 0x4;
+ bit-mask = 0x100;
+};
+
+optfclk_pciephy_clk: optfclk_pciephy_clk@4a0093b0 {
+ compatible = gate-clock;
+ clocks = apll_pcie_ck;
+ #clock-cells = 0;
+ reg = 0x4a0093b0 0x4;
+ bit-shift = 9;
+};
+
+optfclk_pciephy_div_clk: optfclk_pciephy_div_clk@4a0093b0 {
+ compatible = gate-clock;
+ clocks = optfclk_pciephy_div;
+ #clock-cells = 0;
+ reg = 0x4a0093b0 0x4;
+ bit-shift = 10;
+};
--
1.7.9.5
--
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
[PATCHv4 20/33] ARM: AM33xx: remove old clock data and link in new clock init code
AM33xx clocks have now been moved to DT, thus remove the old data file
and use the new init code under OMAP clock driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/cclock33xx_data.c | 1059 -
drivers/clk/omap/Makefile |3 +-
3 files changed, 2 insertions(+), 1061 deletions(-)
delete mode 100644 arch/arm/mach-omap2/cclock33xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9f8d3ed..a4782e2 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -178,7 +178,6 @@ obj-$(CONFIG_ARCH_OMAP3)+= clkt_iclk.o
obj-$(CONFIG_ARCH_OMAP4) += $(clock-common)
obj-$(CONFIG_ARCH_OMAP4) += dpll3xxx.o dpll44xx.o
obj-$(CONFIG_SOC_AM33XX) += $(clock-common) dpll3xxx.o
-obj-$(CONFIG_SOC_AM33XX) += cclock33xx_data.o
obj-$(CONFIG_SOC_OMAP5)+= $(clock-common)
obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
deleted file mode 100644
index ba6534d..000
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ /dev/null
@@ -1,1059 +0,0 @@
-/*
- * AM33XX Clock data
- *
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
- * Vaibhav Hiremath hvaib...@ti.com
- *
- * 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.
- */
-
-#include linux/kernel.h
-#include linux/list.h
-#include linux/clk-private.h
-#include linux/clkdev.h
-#include linux/io.h
-
-#include am33xx.h
-#include soc.h
-#include iomap.h
-#include clock.h
-#include control.h
-#include cm.h
-#include cm33xx.h
-#include cm-regbits-33xx.h
-#include prm.h
-
-/* Modulemode control */
-#define AM33XX_MODULEMODE_HWCTRL_SHIFT 0
-#define AM33XX_MODULEMODE_SWCTRL_SHIFT 1
-
-/*LIST_HEAD(clocks);*/
-
-/* Root clocks */
-
-/* RTC 32k */
-DEFINE_CLK_FIXED_RATE(clk_32768_ck, CLK_IS_ROOT, 32768, 0x0);
-
-/* On-Chip 32KHz RC OSC */
-DEFINE_CLK_FIXED_RATE(clk_rc32k_ck, CLK_IS_ROOT, 32000, 0x0);
-
-/* Crystal input clks */
-DEFINE_CLK_FIXED_RATE(virt_1920_ck, CLK_IS_ROOT, 1920, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_2400_ck, CLK_IS_ROOT, 2400, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_2500_ck, CLK_IS_ROOT, 2500, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_2600_ck, CLK_IS_ROOT, 2600, 0x0);
-
-/* Oscillator clock */
-/* 19.2, 24, 25 or 26 MHz */
-static const char *sys_clkin_ck_parents[] = {
- virt_1920_ck, virt_2400_ck, virt_2500_ck,
- virt_2600_ck,
-};
-
-/*
- * sys_clk in: input to the dpll and also used as funtional clock for,
- * adc_tsc, smartreflex0-1, timer1-7, mcasp0-1, dcan0-1, cefuse
- *
- */
-DEFINE_CLK_MUX(sys_clkin_ck, sys_clkin_ck_parents, NULL, 0x0,
- AM33XX_CTRL_REGADDR(AM33XX_CONTROL_STATUS),
- AM33XX_CONTROL_STATUS_SYSBOOT1_SHIFT,
- AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH,
- 0, NULL);
-
-/* External clock - 12 MHz */
-DEFINE_CLK_FIXED_RATE(tclkin_ck, CLK_IS_ROOT, 1200, 0x0);
-
-/* Module clocks and DPLL outputs */
-
-/* DPLL_CORE */
-static struct dpll_data dpll_core_dd = {
- .mult_div1_reg = AM33XX_CM_CLKSEL_DPLL_CORE,
- .clk_bypass = sys_clkin_ck,
- .clk_ref= sys_clkin_ck,
- .control_reg= AM33XX_CM_CLKMODE_DPLL_CORE,
- .modes = (1 DPLL_LOW_POWER_BYPASS) | (1 DPLL_LOCKED),
- .idlest_reg = AM33XX_CM_IDLEST_DPLL_CORE,
- .mult_mask = AM33XX_DPLL_MULT_MASK,
- .div1_mask = AM33XX_DPLL_DIV_MASK,
- .enable_mask= AM33XX_DPLL_EN_MASK,
- .idlest_mask= AM33XX_ST_DPLL_CLK_MASK,
- .max_multiplier = 2047,
- .max_divider= 128,
- .min_divider= 1,
-};
-
-/* CLKDCOLDO output */
-static const char *dpll_core_ck_parents[] = {
- sys_clkin_ck,
-};
-
-static struct clk dpll_core_ck;
-
-static const struct clk_ops dpll_core_ck_ops = {
- .recalc_rate= omap3_dpll_recalc,
- .get_parent = omap2_init_dpll_parent,
-};
-
-static struct clk_hw_omap dpll_core_ck_hw = {
- .hw = {
- .clk= dpll_core_ck,
- },
- .dpll_data = dpll_core_dd,
- .ops= clkhwops_omap3_dpll,
-};
-
-DEFINE_STRUCT_CLK(dpll_core_ck, dpll_core_ck_parents, dpll_core_ck_ops);
-
-static const char *dpll_core_x2_ck_parents[] = {
- dpll_core_ck,
-};
-
-static struct clk dpll_core_x2_ck;
-
-static const struct
[PATCHv4 24/33] CLK: OMAP: move some defines from machine to driver header
This is done in preparation for adding support for OMAP3 clocks. Signed-off-by: Tero Kristo t-kri...@ti.com --- arch/arm/mach-omap2/clock.h | 10 -- include/linux/clk/omap.h| 16 2 files changed, 16 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h index 6273f14..949d293 100644 --- a/arch/arm/mach-omap2/clock.h +++ b/arch/arm/mach-omap2/clock.h @@ -257,9 +257,6 @@ extern void omap2_clkt_iclk_deny_idle(struct clk_hw_omap *clk); unsigned long omap2_get_dpll_rate(struct clk_hw_omap *clk); -int omap2_dflt_clk_enable(struct clk_hw *hw); -void omap2_dflt_clk_disable(struct clk_hw *hw); -int omap2_dflt_clk_is_enabled(struct clk_hw *hw); void omap2_clk_dflt_find_companion(struct clk_hw_omap *clk, void __iomem **other_reg, u8 *other_bit); @@ -286,14 +283,7 @@ extern const struct clksel_rate gfx_l3_rates[]; extern const struct clksel_rate dsp_ick_rates[]; extern struct clk dummy_ck; -extern const struct clk_hw_omap_ops clkhwops_iclk_wait; -extern const struct clk_hw_omap_ops clkhwops_wait; -extern const struct clk_hw_omap_ops clkhwops_iclk; extern const struct clk_hw_omap_ops clkhwops_omap3430es2_ssi_wait; -extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait; -extern const struct clk_hw_omap_ops clkhwops_omap3430es2_dss_usbhost_wait; -extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_dss_usbhost_wait; -extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_hsotgusb_wait; extern const struct clk_hw_omap_ops clkhwops_omap3430es2_hsotgusb_wait; extern const struct clk_hw_omap_ops clkhwops_am35xx_ipss_module_wait; extern const struct clk_hw_omap_ops clkhwops_am35xx_ipss_wait; diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h index c8d9468..24bdd83 100644 --- a/include/linux/clk/omap.h +++ b/include/linux/clk/omap.h @@ -183,19 +183,35 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, int omap2_clkops_enable_clkdm(struct clk_hw *hw); void omap2_clkops_disable_clkdm(struct clk_hw *hw); +int omap2_dflt_clk_enable(struct clk_hw *hw); +void omap2_dflt_clk_disable(struct clk_hw *hw); +int omap2_dflt_clk_is_enabled(struct clk_hw *hw); + +int omap3_dpll4_set_rate(struct clk_hw *clk, unsigned long rate, +unsigned long parent_rate); + int omap2_clk_disable_autoidle_all(void); void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks); extern const struct clk_hw_omap_ops clkhwops_omap3_dpll; extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx; +extern const struct clk_hw_omap_ops clkhwops_omap3430es2_dss_usbhost_wait; +extern const struct clk_hw_omap_ops clkhwops_wait; +extern const struct clk_hw_omap_ops clkhwops_iclk_wait; +extern const struct clk_hw_omap_ops clkhwops_iclk; +extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_ssi_wait; +extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_dss_usbhost_wait; +extern const struct clk_hw_omap_ops clkhwops_omap3430es2_iclk_hsotgusb_wait; /* DT functions */ int dt_omap_clk_init(void); extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt); void of_omap4_dpll_setup(struct device_node *node); +void of_omap3_dpll_setup(struct device_node *node); void of_omap_fixed_factor_setup(struct device_node *node); void of_omap_divider_setup(struct device_node *node); void of_omap_gate_clk_setup(struct device_node *node); +void of_omap_interface_clk_setup(struct device_node *node); void of_omap_clk_allow_autoidle_all(void); void of_omap_clk_deny_autoidle_all(void); -- 1.7.9.5 -- 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
[PATCHv4 31/33] ARM: dts: clk: Add apll related clocks
From: Keerthy j-keer...@ti.com
The patch adds a mux node to choose the parent of apll_pcie_ck node.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 8477ff9..e923311 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -328,13 +328,24 @@ dpll_pcie_ref_m2ldo_ck: dpll_pcie_ref_m2ldo_ck@4a008210 {
ti,autoidle-low;
};
+/* APLL_PCIE */
+
+/* mux clock to select the reference clock */
+apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
+ compatible = mux-clock;
+ clocks = dpll_pcie_ref_ck, pciesref_acs_clk_ck;
+ #clock-cells = 0;
+ reg = 0x4a00821c 0x4;
+ bit-mask = 0x80;
+};
+
apll_pcie_ck: apll_pcie_ck@4a008200 {
#clock-cells = 0;
- compatible = ti,omap4-dpll-clock;
- clocks = dpll_pcie_ref_ck;
- reg = 0x4a008200 0x4, 0x4a008204 0x4, 0x4a008208 0x4, 0x4a00820c
0x4;
- ti,clk-ref = dpll_pcie_ref_ck;
+ clocks = apll_pcie_in_clk_mux;
+ reg = 0x4a00821c 0x4, 0x4a008220 0x4;
ti,clk-bypass = dpll_pcie_ref_ck;
+ ti,clk-ref = apll_pcie_in_clk_mux;
+ compatible = ti,dra7-apll-clock;
};
apll_pcie_clkvcoldo: apll_pcie_clkvcoldo {
--
1.7.9.5
--
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
[PATCHv4 32/33] clk: OMAP: DRA7: Change apll_pcie_m2_ck to fixed factor clock
From: Keerthy j-keer...@ti.com
This patch changes apll_pcie_m2_ck to fixed factor
clock as there are no configurable divider associated to m2.
Signed-off-by: Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/dra7xx-clocks.dtsi |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index e923311..fcc14d4 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -366,13 +366,10 @@ apll_pcie_clkvcoldo_div: apll_pcie_clkvcoldo_div {
apll_pcie_m2_ck: apll_pcie_m2_ck@4a008224 {
#clock-cells = 0;
- compatible = divider-clock;
+ compatible = fixed-factor-clock;
clocks = apll_pcie_ck;
- ti,autoidle-shift = 8;
- reg = 0x4a008224 0x4;
- bit-mask = 0x7f;
- index-starts-at-one;
- ti,autoidle-low;
+ clock-mult = 1;
+ clock-div = 1;
};
sys_clk1_dclk_div: sys_clk1_dclk_div@4ae061c8 {
--
1.7.9.5
--
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 01/15] drivers: phy: add generic PHY framework
Hi Alan,
On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
The PHY and the controller it is attached to are both physical
devices.
The connection between them is hardwired by the system
manufacturer and cannot be changed by software.
PHYs are generally described by fixed system-specific board
files or by Device Tree information. Are they ever discovered
dynamically?
No. They are created just like any other platform devices are created.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
Is the same true for the controllers attached to the PHYs?
If not -- if both a PHY and a controller are discovered
dynamically -- how does the kernel know whether they are
connected to each other?
No differences here. Both PHY and controller will have dt information
or hwmod data using which platform devices will be created.
The kernel needs to know which controller is attached to which
PHY. Currently this information is represented by name or ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous replies.
Without any extra data in platform data. (I have even posted a code
example.)
The PHY's driver (the supplier) uses the platform data to
construct a platform_device structure that represents the PHY.
Currently the driver assigns static labels (corresponding to the label
used in the platform data of the controller).
Until this is done, the controller's driver (the client) cannot
use the PHY.
right.
Since there is no parent-child relation between the PHY and the
controller, there is no guarantee that the PHY's driver will be
ready when the controller's driver wants to use it. A deferred
probe may be needed.
right.
The issue (or one of the issues) in this discussion is that
Greg does not like the idea of using names or IDs to associate
PHYs with controllers, because they are too prone to
duplications or other errors. Pointers are more reliable.
But pointers to what? Since the only data known to be
available to both the PHY driver and controller driver is the
platform data, the obvious answer is a pointer to platform data
(either for the PHY or for the controller, or maybe both).
hmm.. it's not going to be simple though as the platform device for
the PHY and controller can be created in entirely different places.
e.g., in some cases the PHY device is a child of some mfd core device
(the device will be created in drivers/mfd) and the controller driver
(usually) is created in board file. I guess then we have to come up
with something to share a pointer in two different files.
The ability for two different source files to share a pointer to a data
item defined in a third source file has been around since long before
the C language was invented. :-)
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host drivers.
This means you would have to export symbol with the same name from both
PHY drivers, which obviously would not work in this case, because having
both drivers enabled (in a multiplatform aware configuration) would lead
to linking conflict.
Best regards,
Tomasz
--
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 01/15] drivers: phy: add generic PHY framework
[Fixed address of devicetree mailing list and added more people on CC.]
For reference, full thread can be found under following link:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813
Best regards,
Tomasz
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
On Monday 22 of July 2013 10:44:39 Alan Stern wrote:
On Mon, 22 Jul 2013, Kishon Vijay Abraham I wrote:
The PHY and the controller it is attached to are both
physical
devices.
The connection between them is hardwired by the system
manufacturer and cannot be changed by software.
PHYs are generally described by fixed system-specific
board
files or by Device Tree information. Are they ever
discovered
dynamically?
No. They are created just like any other platform devices are
created.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
Is the same true for the controllers attached to the PHYs?
If not -- if both a PHY and a controller are discovered
dynamically -- how does the kernel know whether they are
connected to each other?
No differences here. Both PHY and controller will have dt
information
or hwmod data using which platform devices will be created.
The kernel needs to know which controller is attached to
which
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
The PHY's driver (the supplier) uses the platform data to
construct a platform_device structure that represents the
PHY.
Currently the driver assigns static labels (corresponding to the
label
used in the platform data of the controller).
Until this is done, the controller's driver (the client)
cannot
use the PHY.
right.
Since there is no parent-child relation between the PHY
and the
controller, there is no guarantee that the PHY's driver
will be
ready when the controller's driver wants to use it. A
deferred
probe may be needed.
right.
The issue (or one of the issues) in this discussion is
that
Greg does not like the idea of using names or IDs to
associate
PHYs with controllers, because they are too prone to
duplications or other errors. Pointers are more reliable.
But pointers to what? Since the only data known to be
available to both the PHY driver and controller driver is
the
platform data, the obvious answer is a pointer to platform
data
(either for the PHY or for the controller, or maybe both).
hmm.. it's not going to be simple though as the platform device for
the PHY and controller can be created in entirely different places.
e.g., in some cases the PHY device is a child of some mfd core
device
(the device will be created in drivers/mfd) and the controller
driver
(usually) is created in board file. I guess then we have to come up
with something to share a pointer in two different files.
The ability for two different source files to share a pointer to a
data
item defined in a third source file has been around since long before
the C language was invented. :-)
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
Re: [PATCHv4 00/33] ARM: OMAP: clock conversion to DT
Hrmph, Seems like the old devicetree list was terminated yesterday, so if you reply to this you will get some bounces. Sorry about that. -Tero On 07/23/2013 10:19 AM, Tero Kristo wrote: Hi, Changes compared to previous version: - Clock init files moved from mach-omap2/ to drivers/clk/omap/ - AM33xx support added [patches 15-20] - OMAP3 support added [patches 21-29] - DRA7 APLL support added (thanks Keerthy) [patches 30-33] Test branch on top of 3.11-rc1 available here: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git branch: mainline-3.11-rc1-omap-dt-clks Testing done: - boot + suspend tested on OMAP3 beagle C4 (omap3530) - boot + suspend tested on OMAP4 panda ES (omap4460) - boot tested on beagle bone (am335x) A boot test was also executed for DRA7 and OMAP5 on a separate branch (mainline does not have OMAP5 / DRA7 support so far.) TODO: - Add AM35xx support (OMAP3 derivative, AM35xx only clock nodes missing) Overall diffstat added just for fun: arch/arm/boot/dts/am33xx-clocks.dtsi | 663 arch/arm/boot/dts/am33xx.dtsi |7 + arch/arm/boot/dts/dra7xx-clocks.dtsi | 2113 arch/arm/boot/dts/omap3.dtsi |7 + arch/arm/boot/dts/omap3430es1-clocks.dtsi | 166 + arch/arm/boot/dts/omap34xx-omap36xx-clocks.dtsi| 240 ++ arch/arm/boot/dts/omap34xx.dtsi|9 + .../omap36xx-am35xx-omap3430es2plus-clocks.dtsi| 214 ++ arch/arm/boot/dts/omap36xx-clocks.dtsi | 97 + .../boot/dts/omap36xx-omap3430es2plus-clocks.dtsi | 185 + arch/arm/boot/dts/omap36xx.dtsi| 10 + arch/arm/boot/dts/omap3xxx-clocks.dtsi | 1594 + arch/arm/boot/dts/omap443x-clocks.dtsi | 17 + arch/arm/boot/dts/omap443x.dtsi|8 + arch/arm/boot/dts/omap4460.dtsi|8 + arch/arm/boot/dts/omap446x-clocks.dtsi | 27 + arch/arm/boot/dts/omap44xx-clocks.dtsi | 1654 + arch/arm/boot/dts/omap54xx-clocks.dtsi | 1416 arch/arm/mach-omap2/Makefile |5 +- arch/arm/mach-omap2/cclock33xx_data.c | 1059 -- arch/arm/mach-omap2/cclock3xxx_data.c | 3641 arch/arm/mach-omap2/cclock44xx_data.c | 1730 -- arch/arm/mach-omap2/clock.c|6 + arch/arm/mach-omap2/clock.h| 163 +- arch/arm/mach-omap2/clock3xxx.h|7 +- arch/arm/mach-omap2/io.c |7 +- arch/arm/mach-omap2/omap_hwmod.c |5 +- drivers/clk/Makefile |1 + drivers/clk/clk-divider.c |6 +- drivers/clk/clk-fixed-factor.c |6 +- drivers/clk/clk-gate.c |8 +- drivers/clk/clk-mux.c |6 +- drivers/clk/clkdev.c | 32 + drivers/clk/omap/Makefile |4 + drivers/clk/omap/apll.c| 213 ++ drivers/clk/omap/autoidle.c| 130 + drivers/clk/omap/clk-33xx.c| 85 + drivers/clk/omap/clk-3xxx.c| 171 + drivers/clk/omap/clk-44xx.c| 118 + drivers/clk/omap/clk-54xx.c| 58 + drivers/clk/omap/clk-7xx.c | 67 + drivers/clk/omap/clk.c | 84 + drivers/clk/omap/dpll.c| 387 +++ drivers/clk/omap/gate.c| 166 + drivers/clk/omap/interface.c | 110 + include/linux/clk/omap.h | 223 ++ 46 files changed, 10327 insertions(+), 6606 deletions(-) -Tero -- 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 -- 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] drivers: net: cpsw: add support to show hw stats via ethtool
On 7/22/2013 10:35 PM, Ben Hutchings wrote:
On Mon, 2013-07-22 at 14:07 +0530, Mugunthan V N wrote:
Add support to show CPSW hardware statistics to user via ethtool
so user can find if there were any error reported by hardware or
the system is over loaded duing high data rate transfer.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 202
-
1 file changed, 200 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 05a1674..f344c05 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
[...]
+static const struct cpsw_stats cpsw_gstrings_stats[] = {
+{ Good Rx Frames, CPSW_STAT(rxgoodframes) },
+{ Broadcast Rx Frames, CPSW_STAT(rxbroadcastframes) },
+{ Multicast Rx Frames, CPSW_STAT(rxmulticastframes) },
+{ Pause Rx Frames, CPSW_STAT(rxpauseframes) },
+{ Rx CRC Errors, CPSW_STAT(rxcrcerrors) },
[...]
Statistic names usually don't contain spaces, though I can accept this
is probably more readable.
+static void cpsw_get_ethtool_stats(struct net_device *ndev,
+struct ethtool_stats *stats, u64 *data)
+{
+struct cpsw_priv *priv = netdev_priv(ndev);
+struct cpdma_chan_stats rx_stats;
+struct cpdma_chan_stats tx_stats;
+u32 val;
+u8 *p;
+int i;
+
+/* Collect Davinci CPDMA stats for Rx and Tx Channel */
+cpdma_chan_get_stats(priv-rxch, rx_stats);
+cpdma_chan_get_stats(priv-txch, tx_stats);
+
+for (i = 0; i CPSW_STATS_LEN; i++) {
+switch (cpsw_gstrings_stats[i].type) {
+case CPSW_STATS:
+val = readl((u8 *)priv-hw_stats +
Shouldn't this cast use 'u8 __iomem *'?
Yes, will change this in v2 and submit it.
Regards
Mugunthan V N
--
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: OMAP2430 SDP boot broken after Linus' rmk merge
On Tuesday 23 July 2013 12:37 PM, Paul Walmsley wrote: Hi Rajendra, On Tue, 23 Jul 2013, Rajendra Nayak wrote: On Tuesday 23 July 2013 01:37 AM, Paul Walmsley wrote: On Mon, 22 Jul 2013, Russell King - ARM Linux wrote: Bear in mind that I'm almost at the point of not boot-testing anything I sent to Linus because of the uselessness of the SDP4430 board now that it's DT only - the only platform which boot-tests anything I send is the 3430LDP board now. If people care about that, maybe they can assist with sorting out the issues I've raised on these lists about the SDP4430 - and why the SDP4430 build remains disabled in my build and boot system. I understand completely... Looking at the boot log, it just stops after uboot hands over control. With the lack of output from the decompressor, it's not possible to tell whether it's a decompressor problem or a kernel problem. I think you need to turn on the LL_DEBUG option, select the appropriate output option, and also get the decompressor to use the kernel's debug io functions to output it's stuff (I think the option is DEBUG_UNCOMPRESS). OK, will dig deeper here at the next opportunity. Paul, I can take a look at the 4430sdp issue. Are you also seeing this also on 2430sdp as the subject says, or was that a typo? Thanks for the offer. The issue that I'm seeing is on the 2430SDP in my testbed. I don't have a 4430SDP, so you might consider touching base with rmk for that one. So I tried commit 'fb2af00' on the 4430SDP and it did boot fine, though I see the below errors. (I am using the mainline bootloaders which do not lock any additional DPLLs like USB) [0.00] clock: dpll_usb_ck failed transition to 'locked' [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [c001bfe8] (unwind_backtrace+0x0/0xf4) from [c001868c] (show_stack+0x10/0x14) [0.00] [c001868c] (show_stack+0x10/0x14) from [c02deb28] (Ldiv0+0x8/0x10) [0.00] [c02deb28] (Ldiv0+0x8/0x10) from [c0477030] (clk_divider_set_rate+0x10/0x114) [0.00] [c0477030] (clk_divider_set_rate+0x10/0x114) from [c0476ef4] (clk_change_rate+0x38/0xb8) [0.00] [c0476ef4] (clk_change_rate+0x38/0xb8) from [c0476f5c] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [c001bfe8] (unwind_backtrace+0x0/0xf4) from [c001868c] (show_stack+0x10/0x14) [0.00] [c001868c] (show_stack+0x10/0x14) from [c02deb28] (Ldiv0+0x8/0x10) [0.00] [c02deb28] (Ldiv0+0x8/0x10) from [c0477030] (clk_divider_set_rate+0x10/0x114) [0.00] [c0477030] (clk_divider_set_rate+0x10/0x114) from [c0476ef4] (clk_change_rate+0x38/0xb8) [0.00] [c0476ef4] (clk_change_rate+0x38/0xb8) from [c0476f5c] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [c001bfe8] (unwind_backtrace+0x0/0xf4) from [c001868c] (show_stack+0x10/0x14) [0.00] [c001868c] (show_stack+0x10/0x14) from [c02deb28] (Ldiv0+0x8/0x10) [0.00] [c02deb28] (Ldiv0+0x8/0x10) from [c0477030] (clk_divider_set_rate+0x10/0x114) [0.00] [c0477030] (clk_divider_set_rate+0x10/0x114) from [c0476ef4] (clk_change_rate+0x38/0xb8) [0.00] [c0476ef4] (clk_change_rate+0x38/0xb8) from [c0476f5c] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [c001bfe8] (unwind_backtrace+0x0/0xf4) from [c001868c] (show_stack+0x10/0x14) [0.00] [c001868c] (show_stack+0x10/0x14) from [c02deb28] (Ldiv0+0x8/0x10) [0.00] [c02deb28] (Ldiv0+0x8/0x10) from [c0477030] (clk_divider_set_rate+0x10/0x114) [0.00] [c0477030] (clk_divider_set_rate+0x10/0x114) from [c0476ef4] (clk_change_rate+0x38/0xb8) [0.00] [c0476ef4] (clk_change_rate+0x38/0xb8) from [c0476f5c] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [c001bfe8] (unwind_backtrace+0x0/0xf4) from [c001868c] (show_stack+0x10/0x14) [0.00] [c001868c] (show_stack+0x10/0x14) from [c02deb28] (Ldiv0+0x8/0x10) [0.00] [c02deb28] (Ldiv0+0x8/0x10) from [c0477030] (clk_divider_set_rate+0x10/0x114) [0.00] [c0477030] (clk_divider_set_rate+0x10/0x114) from [c0476ef4] (clk_change_rate+0x38/0xb8) [0.00] [c0476ef4] (clk_change_rate+0x38/0xb8) from [c0476f5c] (clk_change_rate+0xa0/0xb8) [0.00] Division by zero in kernel. [0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-03445-gfb2af00-dirty #7 [0.00] [c001bfe8] (unwind_backtrace+0x0/0xf4) from [c001868c] (show_stack+0x10/0x14) [
[PATCH 0/2] OMAP: Panda DVI fix and a cleanup
Hi Tony, Here's a fix for 3.11 that makes EDID read for DVI work again. I also included a cleanup patch that removes the non-DT support functions that are no longer called from anywhere. It's not a fix, but as we're in quite early rcs, I thought it would be nice to remove the dead code. Up to you if you want to include that one for 3.11 or not. If not, I'll include it in a board file series for 3.12 that I'll send soon. Tomi Tomi Valkeinen (2): ARM: OMAP: dss-common: fix Panda's DVI DDC channel ARM: OMAP2+: Remove legacy DSS initialization for omap4 arch/arm/mach-omap2/dss-common.c | 49 +--- arch/arm/mach-omap2/dss-common.h | 2 -- 2 files changed, 1 insertion(+), 50 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP2+: Remove legacy DSS initialization for omap4
This is no longer needed as omap4 is now booted using device tree.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/dss-common.c | 47
arch/arm/mach-omap2/dss-common.h | 2 --
2 files changed, 49 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 043e570..00c0492 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -80,24 +80,6 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
.default_device = omap4_panda_dvi_device,
};
-void __init omap4_panda_display_init(void)
-{
- omap_display_init(omap4_panda_dss_data);
-
- /*
-* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-* later have external pull up on the HDMI I2C lines
-*/
- if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
- omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
- else
- omap_hdmi_init(0);
-
- omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
void __init omap4_panda_display_init_of(void)
{
omap_display_init(omap4_panda_dss_data);
@@ -204,35 +186,6 @@ static struct omap_dss_board_info sdp4430_dss_data = {
* used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
* selected by default
*/
-void __init omap_4430sdp_display_init(void)
-{
- int r;
-
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- display_sel);
- if (r)
- pr_err(%s: Could not get display_sel GPIO\n, __func__);
-
- r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- DLP POWER ON);
- if (r)
- pr_err(%s: Could not get DLP POWER ON GPIO\n, __func__);
-
- omap_display_init(sdp4430_dss_data);
- /*
-* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
-* later have external pull up on the HDMI I2C lines
-*/
- if (cpu_is_omap446x() || omap_rev() OMAP4430_REV_ES2_2)
- omap_hdmi_init(OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP);
- else
- omap_hdmi_init(0);
-
- omap_mux_init_gpio(HDMI_GPIO_LS_OE, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD, OMAP_PIN_OUTPUT);
- omap_mux_init_gpio(HDMI_GPIO_HPD, OMAP_PIN_INPUT_PULLDOWN);
-}
-
void __init omap_4430sdp_display_init_of(void)
{
int r;
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
index 915f6ff..c28fe3c 100644
--- a/arch/arm/mach-omap2/dss-common.h
+++ b/arch/arm/mach-omap2/dss-common.h
@@ -6,9 +6,7 @@
* This file will be removed when DSS supports DT.
*/
-void __init omap4_panda_display_init(void);
void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init(void);
void __init omap_4430sdp_display_init_of(void);
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP: dss-common: fix Panda's DVI DDC channel
Panda's DVI connector's DDC pins are connected to OMAP's third i2c bus.
With non-DT, the bus number was 3, and that is what is used in the
dss-common.c which contains the platform data for Panda's DVI.
However, with DT, the bus number is 2. As we now only have DT boot for
Panda, we have to change the bus number to make DVI EDID read
operational.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/dss-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 393aeef..043e570 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -42,7 +42,7 @@
/* Using generic display panel */
static struct tfp410_platform_data omap4_dvi_panel = {
- .i2c_bus_num= 3,
+ .i2c_bus_num= 2,
.power_down_gpio= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
};
--
1.8.1.2
--
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 6/6] USB: ehci-omap: Implement suspend/resume
On 07/22/2013 06:18 PM, Alan Stern wrote:
On Mon, 22 Jul 2013, Roger Quadros wrote:
Right, I understand it now. How does the below code look?
+static int omap_ehci_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ bool do_wakeup = device_may_wakeup(dev);
+ int ret;
+
+ dev_dbg(dev, %s may_wakeup %d\n, __func__, do_wakeup);
+
+ if (pm_runtime_status_suspended(dev)) {
You need to do this only when do_wakeup is false.
Right. Missed that.
+ pm_runtime_get_sync(dev);
+ ehci_resume(hcd, false);
+ ret = ehci_suspend(hcd, do_wakeup);
+ pm_runtime_put_sync(dev);
It would be better to call pm_runtime_resume(dev) at the start instead
of pm_runtime_get_sync(), and eliminate the last two lines. Then the
ehci_suspend() below could be moved outside the if statement.
Why do I find pm_runtime_* so confusing ;)
Alternatively, if you are able to turn off the wakeup setting without
going through an entire resume/suspend cycle, that would be preferable.
As we don't rely on the EHCI controller's interrupt any more after we
power it down, maybe ehci_resume/suspend cycle is not required at all on OMAP,
even if the wakeup setting is disabled during system suspend.
As the wakeup is controlled entirely by pad wakeup, all we need to do is make
sure
the IO pad wakeup is configured correctly based on do_wakeup. How this is done
is still in transition but it might be turn out to be as simple as
irq_set_irq_wake()
So IMHO, for ehci-omap this should suffice
static int omap_ehci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
bool do_wakeup = device_may_wakeup(dev);
int ret = 0;
if (!pm_runtime_status_suspended(dev))
ret = ehci_suspend(hcd, do_wakeup);
/* Not tested yet */
irq_set_irq_wake(hcd-irq, do_wakeup);
return ret;
}
What do you think?
As the OMAP IO pad wakeup management code [1] is still in transition, I'll wait
till
that gets settled and then resend this series.
cheers,
-roger
[1] - http://thread.gmane.org/gmane.linux.ports.arm.omap/99010
--
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] omapfb: In omapfb_probe return -EPROBE_DEFER when display driver is not loaded yet
On 13/07/13 21:27, Pavel Machek wrote:
On Wed 2013-07-10 15:08:59, Pali Rohár wrote:
* On RX-51 probing for acx565akm driver is later then for omapfb which cause
that omapfb probe fail and framebuffer is not working
* EPROBE_DEFER causing that kernel try to probe for omapfb later again which
fixing this problem
* Without this patch display on Nokia RX-51 (N900) phone not working
Signed-off-by: Pali Rohár pali.ro...@gmail.com
Tested-by: Pavel Machek pa...@ucw.cz
Which kernel version is this? Does it have
dfbc32316c6991010328c21e6046b05bac57eb84 (OMAPFB: defer probe if no displays)?
Then again, rx51 has tv-output, which probably gets probed early. So omapfb
does see one functional display, and starts, even if the LCD is not available
yet.
(Actually, do we know which commit broke the ordering? We may want to
simply revert that one...)
Well, my understand that this is how it's supposed to work. There's no defined
order with the driver probes, and the drivers just have to deal with their
dependencies not being there yet.
I don't have a perfect solution for this problem for omapfb. omapfb doesn't
support dynamically adding displays, so all the displays it uses have to be
probed before omapfb. And omapfb doesn't know which displays will be probed.
The patch below was added for 3.11. Does it fix the issue for you? Perhaps it
should be added for 3.10 also.
Tomi
commit e9f322b4913e5d3e5c5d21dc462ca6f8a86e1df1
Author: Tomi Valkeinen tomi.valkei...@ti.com
Date: Thu May 23 16:41:25 2013 +0300
OMAPFB: use EPROBE_DEFER if default display is not present
Currently omapfb returns EPROBE_DEFER if no displays have been probed at
the time omapfb is probed. However, sometimes some of the displays have
been probed at that time, but not all. We can't return EPROBE_DEFER in
that case, because then one missing driver would cause omapfb to defer
always, preventing any display from working.
However, if the user has defined a default display, we can presume that
the driver for that display is eventually loaded. Thus, this patch
changes omapfb to return EPROBE_DEFER in case default display is not
found.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 528e453..27d6905 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2503,7 +2503,7 @@ static int omapfb_probe(struct platform_device *pdev)
if (def_display == NULL) {
dev_err(fbdev-dev, failed to find default display\n);
- r = -EINVAL;
+ r = -EPROBE_DEFER;
goto cleanup;
}
signature.asc
Description: OpenPGP digital signature
[net-next PATCH v2 1/1] drivers: net: cpsw: add support to show hw stats via ethtool
Add support to show CPSW hardware statistics to user via ethtool
so user can find if there were any error reported by hardware or
the system is over loaded duing high data rate transfer.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Changes from initial version
* Change hw_stats variable from struct cpsw_hw_stats __iomem * to u8 __iomem *,
so that accessing hw_stats doesn't require type casting.
---
drivers/net/ethernet/ti/cpsw.c | 202 +++-
1 file changed, 200 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 05a1674..1cd1c00 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -91,6 +91,7 @@ do {
\
#define CPSW1_SLAVE_SIZE 0x040
#define CPSW1_CPDMA_OFFSET 0x100
#define CPSW1_STATERAM_OFFSET 0x200
+#define CPSW1_HW_STATS 0x400
#define CPSW1_CPTS_OFFSET 0x500
#define CPSW1_ALE_OFFSET 0x600
#define CPSW1_SLIVER_OFFSET0x700
@@ -99,6 +100,7 @@ do {
\
#define CPSW2_SLAVE_OFFSET 0x200
#define CPSW2_SLAVE_SIZE 0x100
#define CPSW2_CPDMA_OFFSET 0x800
+#define CPSW2_HW_STATS 0x900
#define CPSW2_STATERAM_OFFSET 0xa00
#define CPSW2_CPTS_OFFSET 0xc00
#define CPSW2_ALE_OFFSET 0xd00
@@ -299,6 +301,44 @@ struct cpsw_sliver_regs {
u32 rx_pri_map;
};
+struct cpsw_hw_stats {
+ u32 rxgoodframes;
+ u32 rxbroadcastframes;
+ u32 rxmulticastframes;
+ u32 rxpauseframes;
+ u32 rxcrcerrors;
+ u32 rxaligncodeerrors;
+ u32 rxoversizedframes;
+ u32 rxjabberframes;
+ u32 rxundersizedframes;
+ u32 rxfragments;
+ u32 __pad_0[2];
+ u32 rxoctets;
+ u32 txgoodframes;
+ u32 txbroadcastframes;
+ u32 txmulticastframes;
+ u32 txpauseframes;
+ u32 txdeferredframes;
+ u32 txcollisionframes;
+ u32 txsinglecollframes;
+ u32 txmultcollframes;
+ u32 txexcessivecollisions;
+ u32 txlatecollisions;
+ u32 txunderrun;
+ u32 txcarriersenseerrors;
+ u32 txoctets;
+ u32 octetframes64;
+ u32 octetframes65t127;
+ u32 octetframes128t255;
+ u32 octetframes256t511;
+ u32 octetframes512t1023;
+ u32 octetframes1024tup;
+ u32 netoctets;
+ u32 rxsofoverruns;
+ u32 rxmofoverruns;
+ u32 rxdmaoverruns;
+};
+
struct cpsw_slave {
void __iomem*regs;
struct cpsw_sliver_regs __iomem *sliver;
@@ -332,6 +372,7 @@ struct cpsw_priv {
struct cpsw_platform_data data;
struct cpsw_ss_regs __iomem *regs;
struct cpsw_wr_regs __iomem *wr_regs;
+ u8 __iomem *hw_stats;
struct cpsw_host_regs __iomem *host_port_regs;
u32 msg_enable;
u32 version;
@@ -354,6 +395,94 @@ struct cpsw_priv {
u32 emac_port;
};
+struct cpsw_stats {
+ char stat_string[ETH_GSTRING_LEN];
+ int type;
+ int sizeof_stat;
+ int stat_offset;
+};
+
+enum {
+ CPSW_STATS,
+ CPDMA_RX_STATS,
+ CPDMA_TX_STATS,
+};
+
+#define CPSW_STAT(m) CPSW_STATS, \
+ sizeof(((struct cpsw_hw_stats *)0)-m), \
+ offsetof(struct cpsw_hw_stats, m)
+#define CPDMA_RX_STAT(m) CPDMA_RX_STATS,\
+ sizeof(((struct cpdma_chan_stats *)0)-m), \
+ offsetof(struct cpdma_chan_stats, m)
+#define CPDMA_TX_STAT(m) CPDMA_TX_STATS,\
+ sizeof(((struct cpdma_chan_stats *)0)-m), \
+ offsetof(struct cpdma_chan_stats, m)
+
+static const struct cpsw_stats cpsw_gstrings_stats[] = {
+ { Good Rx Frames, CPSW_STAT(rxgoodframes) },
+ { Broadcast Rx Frames, CPSW_STAT(rxbroadcastframes) },
+ { Multicast Rx Frames, CPSW_STAT(rxmulticastframes) },
+ { Pause Rx Frames, CPSW_STAT(rxpauseframes) },
+ { Rx CRC Errors, CPSW_STAT(rxcrcerrors) },
+ { Rx Align/Code Errors, CPSW_STAT(rxaligncodeerrors) },
+ { Oversize Rx Frames, CPSW_STAT(rxoversizedframes) },
+ { Rx Jabbers, CPSW_STAT(rxjabberframes) },
+ { Undersize (Short) Rx Frames, CPSW_STAT(rxundersizedframes) },
+ { Rx Fragments, CPSW_STAT(rxfragments) },
+ { Rx Octets, CPSW_STAT(rxoctets) },
+ { Good Tx Frames, CPSW_STAT(txgoodframes) },
+ { Broadcast Tx Frames, CPSW_STAT(txbroadcastframes) },
+ { Multicast Tx Frames,
Re: OMAP2430 SDP boot broken after Linus' rmk merge
Hi Paul, On 22/07/13 19:07, Paul Walmsley wrote: Hi, After Linus's commit fb2af0020a51709ad87ea8055c325d3fbde04158 (Merge branch 'for-linus' of git://git.linaro.org/people/rmk/linux-arm), the OMAP2430 SDP here stopped booting. Here's the bootlog at the commit before the merge, commit 790eac5640: http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722015454/ and here's a log at commit fb2af0020a5: http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130722005921/ Any ideas as to what might have caused this? I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) in the hope that we might be able to reproduce this on those boards, but I'm afraid the integrator works... I took your config, modified it as little as possible to switch to Integrator and turn on earlyprintk, and then tried to boot. That *did* require switching away from ARCH_MULTIPLATFORM, so it isn't as similar as I'd like, though... So I think we can at least say that this is not 1136 specific... Sorry not to be more helpful... Jonny -- 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 6/6] USB: ehci-omap: Implement suspend/resume
On Tue, 23 Jul 2013, Roger Quadros wrote:
+ pm_runtime_get_sync(dev);
+ ehci_resume(hcd, false);
+ ret = ehci_suspend(hcd, do_wakeup);
+ pm_runtime_put_sync(dev);
It would be better to call pm_runtime_resume(dev) at the start instead
of pm_runtime_get_sync(), and eliminate the last two lines. Then the
ehci_suspend() below could be moved outside the if statement.
Why do I find pm_runtime_* so confusing ;)
It tries to provide every service anyone might want, and ends up being
confusingly large.
In this case, though, the reasoning is simple. We know that after the
system resumes, the device will be back in the active state. Hence
there's no point in calling pm_runtime_put_sync here, other than to
balance the _get_sync above. Since there's no danger of another thread
trying to do a runtime suspend at this point, you don't need to
increment the usage counter. Therefore pm_runtime_resume is good
enough.
Alternatively, if you are able to turn off the wakeup setting without
going through an entire resume/suspend cycle, that would be preferable.
As we don't rely on the EHCI controller's interrupt any more after we
power it down, maybe ehci_resume/suspend cycle is not required at all on OMAP,
even if the wakeup setting is disabled during system suspend.
As the wakeup is controlled entirely by pad wakeup, all we need to do is make
sure
the IO pad wakeup is configured correctly based on do_wakeup. How this is done
is still in transition but it might be turn out to be as simple as
irq_set_irq_wake()
So IMHO, for ehci-omap this should suffice
static int omap_ehci_suspend(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
bool do_wakeup = device_may_wakeup(dev);
int ret = 0;
if (!pm_runtime_status_suspended(dev))
ret = ehci_suspend(hcd, do_wakeup);
/* Not tested yet */
irq_set_irq_wake(hcd-irq, do_wakeup);
return ret;
}
What do you think?
Nice and simple. It looks good.
As the OMAP IO pad wakeup management code [1] is still in transition, I'll
wait till
that gets settled and then resend this series.
Okay.
Alan Stern
--
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 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
And so on. This explicitly gives the connection between PHYs and
controllers. The PHY providers would use phy1 or phy2, and the PHY
consumers would use host1 or host2.
Alan Stern
--
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 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:05 Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted
a
code example.)
I don't understand, because I don't know what a PHY lookup does.
I have provided a code example in [1]. Feel free to ask questions about
those code snippets.
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=20889
In this case, it doesn't matter where the platform_device
structures
are created or where the driver source code is. Let's take a
simple
example. Suppose the system design includes a PHY named foo.
Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make
up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the
same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation -
you
export random driver-specific symbols from one driver to another.
Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
It's still a random, driver-specific global symbol exported from board file
to drivers.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
and
there are two types of consumer drivers (e.g. USB host controllers).
Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same
name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
And so on. This explicitly gives the connection between PHYs and
controllers. The PHY providers would use phy1 or phy2, and the PHY
consumers would use host1 or host2.
This could work assuming that only one SoC and one board is supported in
single kernel image. However it's not the case.
We've used to support multiple boards since a long time already and now for
selected platforms we even support multiplatform, i.e. multiple SoCs in
single zImage. Such solution will not work.
Best regards,
Tomasz
--
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 01/15] drivers: phy: add generic PHY framework
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
Yes. I think we could use i2c_board_info for passing platform data.
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
It is how the PHY framework finds a PHY, when the controller (say USB)requests
a PHY from the PHY framework.
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
I think instead we can use the same data while creating the platform data of
the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also pass the
*data* it actually got from the platform data to the framework.
The PHY user driver (USB), while requesting for the PHY (from the PHY
framework) will pass the *data* it got from its platform data.
The PHY framework can do a comparison of the *data* pointers it has and return
the appropriate PHY to the controller.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
phy_data.info = info;
platform_device_add_data(pdev, phy_data, sizeof(*phy_data))
platform_device_add();
While creating the controller device
struct usb_controller_platform_data controller_data;
controller_data.info = info;
platform_device_add_data(pdev, controller_data,
sizeof(*controller_data))
platform_device_add();
Then modify PHY framework API phy create
phy_create((struct device *dev, const struct phy_ops
[PATCH 1/4] mfd: twl6030-irq: migrate to IRQ threaded handler
From: Naga Venkata Srikanth V vnv.srika...@samsung.com
1) Removed request_irq() and replaced it with request_threaded_irq().
2) Removed generic_handle_irq() and replaced it with
handle_nested_irq().
Handling of these interrupts is nested, as we are handling an
interrupt (for e.g rtc, mmc1) when we are still servicing TWL irq.
3) Removed I2C read-retry logic for the case when twl_i2c_read() is
failed inside IRQ handler - there is no sense to do that, so just report
an error and return.
Signed-off-by: Naga Venkata Srikanth V vnv.srika...@samsung.com
Signed-off-by: Oleg_Kosheliev oleg.koshel...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/mfd/twl6030-irq.c | 146 +++--
1 file changed, 49 insertions(+), 97 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 277a8db..b6030d9 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -90,7 +90,6 @@ static unsigned twl6030_irq_base;
static int twl_irq;
static bool twl_irq_wake_enabled;
-static struct completion irq_event;
static atomic_t twl6030_wakeirqs = ATOMIC_INIT(0);
static int twl6030_irq_pm_notifier(struct notifier_block *notifier,
@@ -131,95 +130,57 @@ static struct notifier_block
twl6030_irq_pm_notifier_block = {
};
/*
- * This thread processes interrupts reported by the Primary Interrupt Handler.
- */
-static int twl6030_irq_thread(void *data)
+* Threaded irq handler for the twl6030 interrupt.
+* We query the interrupt controller in the twl6030 to determine
+* which module is generating the interrupt request and call
+* handle_nested_irq for that module.
+*/
+static irqreturn_t twl6030_irq_thread(int irq, void *data)
{
- long irq = (long)data;
- static unsigned i2c_errors;
- static const unsigned max_i2c_errors = 100;
- int ret;
-
- while (!kthread_should_stop()) {
- int i;
- union {
+ int i, ret;
+ union {
u8 bytes[4];
u32 int_sts;
- } sts;
-
- /* Wait for IRQ, then read PIH irq status (also blocking) */
- wait_for_completion_interruptible(irq_event);
-
- /* read INT_STS_A, B and C in one shot using a burst read */
- ret = twl_i2c_read(TWL_MODULE_PIH, sts.bytes,
- REG_INT_STS_A, 3);
- if (ret) {
- pr_warning(twl6030: I2C error %d reading PIH ISR\n,
- ret);
- if (++i2c_errors = max_i2c_errors) {
- printk(KERN_ERR Maximum I2C error count
-exceeded. Terminating %s.\n,
- __func__);
- break;
- }
- complete(irq_event);
- continue;
- }
-
+ } sts;
+ /* read INT_STS_A, B and C in one shot using a burst read */
+ ret = twl_i2c_read(TWL_MODULE_PIH, sts.bytes, REG_INT_STS_A, 3);
+ if (ret) {
+ pr_warn(%s: I2C error %d reading PIH ISR\n, __func__, ret);
+ return IRQ_HANDLED;
+ }
- sts.bytes[3] = 0; /* Only 24 bits are valid*/
+ sts.bytes[3] = 0; /* Only 24 bits are valid*/
- /*
-* Since VBUS status bit is not reliable for VBUS disconnect
-* use CHARGER VBUS detection status bit instead.
-*/
- if (sts.bytes[2] 0x10)
- sts.bytes[2] |= 0x08;
+ /*
+* Since VBUS status bit is not reliable for VBUS disconnect
+* use CHARGER VBUS detection status bit instead.
+*/
+ if (sts.bytes[2] 0x10)
+ sts.bytes[2] |= 0x08;
- for (i = 0; sts.int_sts; sts.int_sts = 1, i++) {
- local_irq_disable();
- if (sts.int_sts 0x1) {
- int module_irq = twl6030_irq_base +
+ for (i = 0; sts.int_sts; sts.int_sts = 1, i++)
+ if (sts.int_sts 0x1) {
+ int module_irq = twl6030_irq_base +
twl6030_interrupt_mapping[i];
- generic_handle_irq(module_irq);
-
- }
- local_irq_enable();
+ handle_nested_irq(module_irq);
+ pr_debug(%s: PIH ISR %u, virq%u\n,
+__func__, i, module_irq);
}
- /*
-* NOTE:
-* Simulation confirms that documentation is wrong w.r.t the
-* interrupt status clear operation. A single *byte* write to
-* any one of STS_A to STS_C register results in all three
-* STS registers being
[PATCH 0/4] mfd: twl6030-irq: rework and add twl6032 support
This patch series intorduces twl6030-irq module rework to use Threaded IRQ and linear irq_domain, and adds support for PMIC TWL6032 IRQs. After this patch series TWL6030/6032 IRQs will be supported only for DT boot mode. Based on v3.11-rc1 Tested generation of RTC_ALARM(3) and PWRON(0) IRQs on OMAP4430/TWL6030 and OMAP4470/TWL6032. Grygorii Strashko (2): mfd: twl6030-irq: add error check when IRQs are masked initially mfd: twl6030-irq: convert to use linear irq_domain Naga Venkata Srikanth V (1): mfd: twl6030-irq: migrate to IRQ threaded handler Oleksandr Dmytryshyn (1): mfd: twl6030-irq: Add interrupt mapping table for the twl6032 drivers/mfd/twl6030-irq.c | 296 +++-- 1 file changed, 154 insertions(+), 142 deletions(-) -- 1.7.9.5 -- 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 0/4] Add PWM polarity flag macro for DT
On Fri, Jul 19, 2013 at 01:29:13PM +0200, Laurent Pinchart wrote: Hi Stephen, On Thursday 18 July 2013 10:55:56 Stephen Warren wrote: On 07/17/2013 04:54 PM, Laurent Pinchart wrote: Hello, Here's a small patch set that replaces PWM polarity numerical constants with macros in DT. The series, Reviewed-by: Stephen Warren swar...@nvidia.com I'm (very very) slightly hesitant about patch 3/4, since it's moving towards all PWMs having to use the same specifier format, whereas specifiers are at least potentially binding-specific, not device-type-specific. However, consistency is good; there's no need to do something different just for the heck of it. Equally, there's nothing actually stopping a new binding from defining its own format rather than simply deferring to pwm.txt if it absolutely has to, so I think this will turn out fine. Exactly, that's why I don't think it's an issue. pwm.txt defines a common format, individual bindings are free to use it or not. Thierry, if you're fine with the patches, could you take them in your tree with Stephen's Reviewed-by, or should I report them and send you a pull request ? They look good to me. I'll take them into my tree and add Stephen's Reviwed-by. It might take me another week, though, as I'm currently rather busy with other things. Thierry signature.asc Description: Digital signature
[PATCH 4/4] mfd: twl6030-irq: Add interrupt mapping table for the twl6032
From: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
This patch adds interrupt mapping table for the twl6032.
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/mfd/twl6030-irq.c | 49 -
1 file changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 89f130b..e4df87f 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -41,6 +41,7 @@
#include linux/suspend.h
#include linux/of.h
#include linux/irqdomain.h
+#include linux/of_device.h
#include twl-core.h
@@ -84,6 +85,36 @@ static int twl6030_interrupt_mapping[24] = {
CHARGERFAULT_INTR_OFFSET, /* Bit 22 INT_CHRG*/
RSV_INTR_OFFSET,/* Bit 23 Reserved*/
};
+
+static int twl6032_interrupt_mapping[24] = {
+ PWR_INTR_OFFSET,/* Bit 0PWRON */
+ PWR_INTR_OFFSET,/* Bit 1RPWRON */
+ PWR_INTR_OFFSET,/* Bit 2SYS_VLOW*/
+ RTC_INTR_OFFSET,/* Bit 3RTC_ALARM */
+ RTC_INTR_OFFSET,/* Bit 4RTC_PERIOD */
+ HOTDIE_INTR_OFFSET, /* Bit 5HOT_DIE */
+ SMPSLDO_INTR_OFFSET,/* Bit 6VXXX_SHORT */
+ PWR_INTR_OFFSET,/* Bit 7SPDURATION */
+
+ PWR_INTR_OFFSET,/* Bit 8WATCHDOG*/
+ BATDETECT_INTR_OFFSET, /* Bit 9BAT */
+ SIMDETECT_INTR_OFFSET, /* Bit 10 SIM */
+ MMCDETECT_INTR_OFFSET, /* Bit 11 MMC */
+ MADC_INTR_OFFSET, /* Bit 12 GPADC_RT_EOC*/
+ MADC_INTR_OFFSET, /* Bit 13 GPADC_SW_EOC*/
+ GASGAUGE_INTR_OFFSET, /* Bit 14 CC_EOC */
+ GASGAUGE_INTR_OFFSET, /* Bit 15 CC_AUTOCAL */
+
+ USBOTG_INTR_OFFSET, /* Bit 16 ID_WKUP */
+ USBOTG_INTR_OFFSET, /* Bit 17 VBUS_WKUP */
+ USBOTG_INTR_OFFSET, /* Bit 18 ID */
+ USB_PRES_INTR_OFFSET, /* Bit 19 VBUS*/
+ CHARGER_INTR_OFFSET,/* Bit 20 CHRG_CTRL */
+ CHARGERFAULT_INTR_OFFSET, /* Bit 21 EXT_CHRG*/
+ CHARGERFAULT_INTR_OFFSET, /* Bit 22 INT_CHRG*/
+ RSV_INTR_OFFSET,/* Bit 23 Reserved*/
+};
+
/*--*/
static unsigned twl6030_irq_base;
@@ -91,6 +122,7 @@ static int twl_irq;
static bool twl_irq_wake_enabled;
static atomic_t twl6030_wakeirqs = ATOMIC_INIT(0);
+static const int *irq_mapping_tbl;
static int twl6030_irq_pm_notifier(struct notifier_block *notifier,
unsigned long pm_event, void *unused)
@@ -164,7 +196,7 @@ static irqreturn_t twl6030_irq_thread(int irq, void *data)
if (sts.int_sts 0x1) {
int module_irq =
irq_find_mapping(irq_domain,
-twl6030_interrupt_mapping[i]);
+irq_mapping_tbl[i]);
if (module_irq)
handle_nested_irq(module_irq);
else
@@ -339,6 +371,12 @@ static struct irq_domain_ops twl6030_irq_domain_ops = {
.xlate = irq_domain_xlate_onetwocell,
};
+static const struct of_device_id twl6030_of_match[] = {
+ {.compatible = ti,twl6030, twl6030_interrupt_mapping},
+ {.compatible = ti,twl6032, twl6032_interrupt_mapping},
+ { },
+};
+
int twl6030_init_irq(struct device *dev, int irq_num)
{
struct device_node *node = dev-of_node;
@@ -346,6 +384,15 @@ int twl6030_init_irq(struct device *dev, int irq_num)
int status;
u8 mask[3];
struct irq_domain *irq_domain;
+ const struct of_device_id *of_id;
+
+ of_id = of_match_device(twl6030_of_match, dev);
+ if (!of_id || !of_id-data) {
+ dev_err(dev, Unknown TWL device model\n);
+ return -EINVAL;
+ }
+
+ irq_mapping_tbl = of_id-data;
nr_irqs = TWL6030_NR_IRQS;
--
1.7.9.5
--
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 v2 0/3] Input: omap-keypad: Convert to threaded IRQ and cleanup
Replace unclear hardcoded values with bit field, convert to threaded IRQ and clear pending interrupts when open the keypad. Based on top of v3.11-rc2. Tested on OMAP4 SDP. Illia Smyrnov (3): Input: omap-keypad: Cleanup - use bitfiled instead of hardcoded values Input: omap-keypad: Convert to threaded IRQ Input: omap-keypad: Clear pending interrupts on open drivers/input/keyboard/omap4-keypad.c | 59 +++-- 1 files changed, 34 insertions(+), 25 deletions(-) -- 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 v2 3/3] Input: omap-keypad: Clear pending interrupts on open
Clear pending interrupts when open keypad. Signed-off-by: Illia Smyrnov illia.smyr...@ti.com --- drivers/input/keyboard/omap4-keypad.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index b876a0d..62abc3e 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -185,13 +185,14 @@ static int omap4_keypad_open(struct input_dev *input) (OMAP4_VAL_PVT OMAP4_DEF_CTRL_PTV_SHIFT)); kbd_writel(keypad_data, OMAP4_KBD_DEBOUNCINGTIME, OMAP4_VAL_DEBOUNCINGTIME); - kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS, - OMAP4_VAL_IRQDISABLE); kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE, OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY); kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE, OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA); + /* clear pending interrupts */ + kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS, +kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS)); enable_irq(keypad_data-irq); -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] mfd: twl6030-irq: convert to use linear irq_domain
Since the TWL6030 PMIC is used with OMAP4 SoCs only and OMAP4 legacy
boot is dropped there are no needs to allocate the range of IRQ
descriptors during system boot to support TWL6030 IRQs.
Hence, convert it to use linear irq_domain and move IRQ configuration in
.map()/.unmap() callbacks of irq_domain. So, IRQ mapping and descriptors
allocation will be performed dynamically basing on DT configuration.
The error message will be reported in case if unmapped IRQ is received by
TWL6030 (virq==0).
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/mfd/twl6030-irq.c | 114 -
1 file changed, 61 insertions(+), 53 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 790cc28..89f130b 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -138,6 +138,7 @@ static struct notifier_block twl6030_irq_pm_notifier_block
= {
static irqreturn_t twl6030_irq_thread(int irq, void *data)
{
int i, ret;
+ struct irq_domain *irq_domain = (struct irq_domain *)data;
union {
u8 bytes[4];
u32 int_sts;
@@ -161,9 +162,14 @@ static irqreturn_t twl6030_irq_thread(int irq, void *data)
for (i = 0; sts.int_sts; sts.int_sts = 1, i++)
if (sts.int_sts 0x1) {
- int module_irq = twl6030_irq_base +
- twl6030_interrupt_mapping[i];
- handle_nested_irq(module_irq);
+ int module_irq =
+ irq_find_mapping(irq_domain,
+twl6030_interrupt_mapping[i]);
+ if (module_irq)
+ handle_nested_irq(module_irq);
+ else
+ pr_err(%s: Unmapped PIH ISR %u detected\n,
+ __func__, i);
pr_debug(%s: PIH ISR %u, virq%u\n,
__func__, i, module_irq);
}
@@ -186,19 +192,6 @@ static irqreturn_t twl6030_irq_thread(int irq, void *data)
/*--*/
-static inline void activate_irq(int irq)
-{
-#ifdef CONFIG_ARM
- /* ARM requires an extra step to clear IRQ_NOREQUEST, which it
-* sets on behalf of every irq_chip. Also sets IRQ_NOPROBE.
-*/
- set_irq_flags(irq, IRQF_VALID);
-#else
- /* same effect on other architectures */
- irq_set_noprobe(irq);
-#endif
-}
-
static int twl6030_irq_set_wake(struct irq_data *d, unsigned int on)
{
if (on)
@@ -308,28 +301,54 @@ int twl6030_mmc_card_detect(struct device *dev, int slot)
}
EXPORT_SYMBOL(twl6030_mmc_card_detect);
+static struct irq_chip twl6030_irq_chip;
+
+static int twl6030_irq_map(struct irq_domain *d, unsigned int virq,
+ irq_hw_number_t hwirq)
+{
+ irq_set_chip_data(virq, twl6030_irq_chip);
+ irq_set_chip_and_handler(virq, twl6030_irq_chip, handle_simple_irq);
+ irq_set_nested_thread(virq, true);
+
+#ifdef CONFIG_ARM
+ /*
+* ARM requires an extra step to clear IRQ_NOREQUEST, which it
+* sets on behalf of every irq_chip. Also sets IRQ_NOPROBE.
+*/
+ set_irq_flags(virq, IRQF_VALID);
+#else
+ /* same effect on other architectures */
+ irq_set_noprobe(virq);
+#endif
+
+ return 0;
+}
+
+static void twl6030_irq_unmap(struct irq_domain *d, unsigned int virq)
+{
+#ifdef CONFIG_ARM
+ set_irq_flags(virq, 0);
+#endif
+ irq_set_chip_and_handler(virq, NULL, NULL);
+ irq_set_chip_data(virq, NULL);
+}
+
+static struct irq_domain_ops twl6030_irq_domain_ops = {
+ .map= twl6030_irq_map,
+ .unmap = twl6030_irq_unmap,
+ .xlate = irq_domain_xlate_onetwocell,
+};
+
int twl6030_init_irq(struct device *dev, int irq_num)
{
struct device_node *node = dev-of_node;
- int nr_irqs, irq_base, irq_end;
- static struct irq_chip twl6030_irq_chip;
+ int nr_irqs;
int status;
- int i;
u8 mask[3];
+ struct irq_domain *irq_domain;
nr_irqs = TWL6030_NR_IRQS;
- irq_base = irq_alloc_descs(-1, 0, nr_irqs, 0);
- if (IS_ERR_VALUE(irq_base)) {
- dev_err(dev, Fail to allocate IRQ descs\n);
- return irq_base;
- }
-
- irq_domain_add_legacy(node, nr_irqs, irq_base, 0,
- irq_domain_simple_ops, NULL);
-
- irq_end = irq_base + nr_irqs;
-
mask[0] = 0xFF;
mask[1] = 0xFF;
mask[2] = 0xFF;
@@ -346,8 +365,6 @@ int twl6030_init_irq(struct device *dev, int irq_num)
return status;
}
- twl6030_irq_base = irq_base;
-
[PATCH v2 2/3] Input: omap-keypad: Convert to threaded IRQ
Convert to use threaded IRQ.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Illia Smyrnov illia.smyr...@ti.com
---
drivers/input/keyboard/omap4-keypad.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index c727548..b876a0d 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -112,8 +112,22 @@ static void kbd_write_irqreg(struct omap4_keypad
*keypad_data,
}
-/* Interrupt handler */
-static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
+/* Interrupt handlers */
+static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
+{
+ struct omap4_keypad *keypad_data = dev_id;
+
+ if (kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS)) {
+ /* Disable interrupts */
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
+OMAP4_VAL_IRQDISABLE);
+ return IRQ_WAKE_THREAD;
+ }
+
+ return IRQ_NONE;
+}
+
+static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
{
struct omap4_keypad *keypad_data = dev_id;
struct input_dev *input_dev = keypad_data-input;
@@ -121,10 +135,6 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
unsigned int col, row, code, changed;
u32 *new_state = (u32 *) key_state;
- /* Disable interrupts */
- kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
-OMAP4_VAL_IRQDISABLE);
-
*new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
*(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
@@ -360,9 +370,10 @@ static int omap4_keypad_probe(struct platform_device *pdev)
goto err_free_keymap;
}
- error = request_irq(keypad_data-irq, omap4_keypad_interrupt,
-IRQF_TRIGGER_RISING,
-omap4-keypad, keypad_data);
+ error = request_threaded_irq(keypad_data-irq, omap4_keypad_irq_handler,
+omap4_keypad_irq_thread_fn,
+IRQF_TRIGGER_RISING,
+omap4-keypad, keypad_data);
if (error) {
dev_err(pdev-dev, failed to register interrupt\n);
goto err_free_input;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] mfd: twl6030-irq: add error check when IRQs are masked initially
Add a missed check for errors when TWL IRQs are masked
initially on probe and report an error in case of failure.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/mfd/twl6030-irq.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index b6030d9..790cc28 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -313,7 +313,7 @@ int twl6030_init_irq(struct device *dev, int irq_num)
struct device_node *node = dev-of_node;
int nr_irqs, irq_base, irq_end;
static struct irq_chip twl6030_irq_chip;
- int status = 0;
+ int status;
int i;
u8 mask[3];
@@ -335,11 +335,16 @@ int twl6030_init_irq(struct device *dev, int irq_num)
mask[2] = 0xFF;
/* mask all int lines */
- twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_LINE_A, 3);
+ status = twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_LINE_A, 3);
/* mask all int sts */
- twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_STS_A, 3);
+ status |= twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_STS_A, 3);
/* clear INT_STS_A,B,C */
- twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_STS_A, 3);
+ status |= twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_STS_A, 3);
+
+ if (status 0) {
+ dev_err(dev, I2C err writing TWL_MODULE_PIH: %d\n, status);
+ return status;
+ }
twl6030_irq_base = irq_base;
--
1.7.9.5
--
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 v2 1/3] Input: omap-keypad: Cleanup - use bitfiled instead of hardcoded values
Use bitfiled instead of hardcoded values to set KBD_CTRL, use BIT macro,
remove unused defines.
Signed-off-by: Illia Smyrnov illia.smyr...@ti.com
---
drivers/input/keyboard/omap4-keypad.c | 25 +++--
1 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index f4aa53a..c727548 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -53,21 +53,17 @@
#define OMAP4_KBD_FULLCODE63_320x48
/* OMAP4 bit definitions */
-#define OMAP4_DEF_IRQENABLE_EVENTEN(1 0)
-#define OMAP4_DEF_IRQENABLE_LONGKEY(1 1)
-#define OMAP4_DEF_IRQENABLE_TIMEOUTEN (1 2)
-#define OMAP4_DEF_WUP_EVENT_ENA(1 0)
-#define OMAP4_DEF_WUP_LONG_KEY_ENA (1 1)
-#define OMAP4_DEF_CTRL_NOSOFTMODE (1 1)
-#define OMAP4_DEF_CTRLPTVVALUE (1 2)
-#define OMAP4_DEF_CTRLPTV (1 1)
+#define OMAP4_DEF_IRQENABLE_EVENTENBIT(0)
+#define OMAP4_DEF_IRQENABLE_LONGKEYBIT(1)
+#define OMAP4_DEF_WUP_EVENT_ENABIT(0)
+#define OMAP4_DEF_WUP_LONG_KEY_ENA BIT(1)
+#define OMAP4_DEF_CTRL_NOSOFTMODE BIT(1)
+#define OMAP4_DEF_CTRL_PTV_SHIFT 2
/* OMAP4 values */
-#define OMAP4_VAL_IRQDISABLE 0x00
-#define OMAP4_VAL_DEBOUNCINGTIME 0x07
-#define OMAP4_VAL_FUNCTIONALCFG0x1E
-
-#define OMAP4_MASK_IRQSTATUSDISABLE0x
+#define OMAP4_VAL_IRQDISABLE 0x0
+#define OMAP4_VAL_DEBOUNCINGTIME 0x7
+#define OMAP4_VAL_PVT 0x7
enum {
KBD_REVISION_OMAP4 = 0,
@@ -175,7 +171,8 @@ static int omap4_keypad_open(struct input_dev *input)
disable_irq(keypad_data-irq);
kbd_writel(keypad_data, OMAP4_KBD_CTRL,
- OMAP4_VAL_FUNCTIONALCFG);
+ OMAP4_DEF_CTRL_NOSOFTMODE |
+ (OMAP4_VAL_PVT OMAP4_DEF_CTRL_PTV_SHIFT));
kbd_writel(keypad_data, OMAP4_KBD_DEBOUNCINGTIME,
OMAP4_VAL_DEBOUNCINGTIME);
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
--
1.7.0.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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
Yes. I think we could use i2c_board_info for passing platform data.
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
It is how the PHY framework finds a PHY, when the controller (say USB)requests
a PHY from the PHY framework.
In this case, it doesn't matter where the platform_device structures
are created or where the driver source code is. Let's take a simple
example. Suppose the system design includes a PHY named foo. Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that; make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation - you
export random driver-specific symbols from one driver to another. Then
No, that's not what I said. Neither the PHY driver nor the controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
I think instead we can use the same data while creating the platform data of
the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also pass the
*data* it actually got from the platform data to the framework.
The PHY user driver (USB), while requesting for the PHY (from the PHY
framework) will pass the *data* it got from its platform data.
The PHY framework can do a comparison of the *data* pointers it has and return
the appropriate PHY to the controller.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2 and
there are two types of consumer drivers (e.g. USB host controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
phy_data.info = info;
platform_device_add_data(pdev, phy_data, sizeof(*phy_data))
platform_device_add();
While creating the controller device
struct usb_controller_platform_data controller_data;
controller_data.info = info;
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
Hi Greg,
On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
.
.
snip
.
.
static struct phy *phy_lookup(void *priv) {
.
.
if (phy-priv==priv) //instead of string comparison, we'll use
pointer
return phy;
}
PHY driver should be like
phy_create((dev, ops, pdata-info);
The controller driver would do
phy_get(dev, NULL, pdata-info);
Now the PHY framework will check for a match of *priv* pointer and return
the PHY.
I think this should be possible?
Ick, no. Why can't you just pass the pointer to the phy itself? If you
had a priv pointer to search from, then you could have just passed the
original phy pointer in the first place, right?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
Please just pass the real phy pointer around, that's what it is there
for. Your board binding logic/code should be able to handle this, as
it somehow was going to do the same thing with a name.
The problem is the board file won't have the *phy* pointer. *phy* pointer is
created at a much later time when the phy driver is probed.
Thanks
Kishon
--
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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 09:58:34PM +0530, Kishon Vijay Abraham I wrote:
Hi Greg,
On Tuesday 23 July 2013 09:48 PM, Greg KH wrote:
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever parent?
.
.
snip
.
.
static struct phy *phy_lookup(void *priv) {
.
.
if (phy-priv==priv) //instead of string comparison, we'll use
pointer
return phy;
}
PHY driver should be like
phy_create((dev, ops, pdata-info);
The controller driver would do
phy_get(dev, NULL, pdata-info);
Now the PHY framework will check for a match of *priv* pointer and return
the PHY.
I think this should be possible?
Ick, no. Why can't you just pass the pointer to the phy itself? If you
had a priv pointer to search from, then you could have just passed the
original phy pointer in the first place, right?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
Please just pass the real phy pointer around, that's what it is there
for. Your board binding logic/code should be able to handle this, as
it somehow was going to do the same thing with a name.
The problem is the board file won't have the *phy* pointer. *phy* pointer is
created at a much later time when the phy driver is probed.
Ok, then save it then, as no one could have used it before then, right?
All I don't want to see is any get by name/void * functions in the
api, as that way is fragile and will break, as people have already
shown.
Just pass the real pointer around. If that is somehow a problem, then
something larger is a problem with how board devices are tied together :)
thanks,
greg k-h
--
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] dma: edma: add device_slave_caps() support
Implement device_slave_caps(). EDMA has a limited number of slots.
Slave drivers such as omap_hsmmc will query the driver to make
sure they don't pass in more than these many scatter segments.
Signed-off-by: Joel Fernandes jo...@ti.com
---
Vinod, or Dan- If this patch looks ok, can you please merge in for
-rc cycle? This patch is required to fix MMC support on AM33xx. This
patch is blocking 3 other patches which fix various MMC things. Thanks!
Notes:
(1) this approach is temporary and only for -rc cycle to fix MMC on
AM335x. It will be replace by the RFC series in future kernels:
http://www.spinics.net/lists/arm-kernel/msg260094.html
(2) Patch depends Vinod's patch at:
http://permalink.gmane.org/gmane.linux.kernel/1525112
drivers/dma/edma.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7222cbe..81d5429 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -517,6 +517,14 @@ static void edma_issue_pending(struct dma_chan *chan)
spin_unlock_irqrestore(echan-vchan.lock, flags);
}
+static inline int edma_slave_caps(struct dma_chan *chan,
+ struct dma_slave_caps *caps)
+{
+ caps-max_sg_nr = MAX_NR_SG;
+
+ return 0;
+}
+
static size_t edma_desc_size(struct edma_desc *edesc)
{
int i;
@@ -594,6 +602,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct
dma_device *dma,
dma-device_issue_pending = edma_issue_pending;
dma-device_tx_status = edma_tx_status;
dma-device_control = edma_control;
+ dma-device_slave_caps = edma_slave_caps;
dma-dev = dev;
INIT_LIST_HEAD(dma-channels);
--
1.7.9.5
--
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 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 09:18:46 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:48:24PM +0530, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 23 July 2013 08:07 PM, Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
On Tuesday 23 of July 2013 09:29:32 Tomasz Figa wrote:
Hi Alan,
Thanks for helping to clarify the issues here.
Okay. Are PHYs _always_ platform devices?
They can be i2c, spi or any other device types as well.
In those other cases, presumably there is no platform data associated
with the PHY since it isn't a platform device. Then how does the
kernel know which controller is attached to the PHY? Is this spelled
out in platform data associated with the PHY's i2c/spi/whatever
parent?
Yes. I think we could use i2c_board_info for passing platform data.
PHY. Currently this information is represented by name or
ID
strings embedded in platform data.
right. It's embedded in the platform data of the controller.
It must also be embedded in the PHY's platform data somehow.
Otherwise, how would the kernel know which PHY to use?
By using a PHY lookup as Stephen and I suggested in our previous
replies. Without any extra data in platform data. (I have even
posted a
code example.)
I don't understand, because I don't know what a PHY lookup does.
It is how the PHY framework finds a PHY, when the controller (say
USB)requests a PHY from the PHY framework.
In this case, it doesn't matter where the platform_device
structures
are created or where the driver source code is. Let's take a
simple
example. Suppose the system design includes a PHY named foo.
Then
the board file could contain:
struct phy_info { ... } phy_foo;
EXPORT_SYMBOL_GPL(phy_foo);
and a header file would contain:
extern struct phy_info phy_foo;
The PHY supplier could then call phy_create(phy_foo), and the PHY
client could call phy_find(phy_foo). Or something like that;
make up
your own structure tags and function names.
It's still possible to have conflicts, but now two PHYs with the
same
name (or a misspelled name somewhere) will cause an error at link
time.
This is incorrect, sorry. First of all it's a layering violation -
you
export random driver-specific symbols from one driver to another.
Then
No, that's not what I said. Neither the PHY driver nor the
controller
driver exports anything to the other. Instead, both drivers use data
exported by the board file.
I think instead we can use the same data while creating the platform
data of the controller and the PHY.
The PHY driver while creating the PHY (using PHY framework) will also
pass the *data* it actually got from the platform data to the
framework. The PHY user driver (USB), while requesting for the PHY
(from the PHY framework) will pass the *data* it got from its platform
data.
The PHY framework can do a comparison of the *data* pointers it has and
return the appropriate PHY to the controller.
imagine 4 SoCs - A, B, C, D. There are two PHY types PHY1 and PHY2
and
there are two types of consumer drivers (e.g. USB host
controllers). Now
consider following mapping:
SoC PHY consumer
A PHY1HOST1
B PHY1HOST2
C PHY2HOST1
D PHY2HOST2
So we have to be able to use any of the PHYs with any of the host
drivers. This means you would have to export symbol with the same
name
from both PHY drivers, which obviously would not work in this case,
because having both drivers enabled (in a multiplatform aware
configuration) would lead to linking conflict.
You're right; the scheme was too simple. Instead, the board file
must
export two types of data structures, one for PHYs and one for
controllers. Like this:
struct phy_info {
/* Info for the controller attached to this PHY */
struct controller_info *hinfo;
};
struct controller_info {
/* Info for the PHY which this controller is attached to */
struct phy_info *pinfo;
};
The board file for SoC A would contain:
struct phy_info phy1 = {host1);
EXPORT_SYMBOL(phy1);
struct controller_info host1 = {phy1};
EXPORT_SYMBOL(host1);
The board file for SoC B would contain:
struct phy_info phy1 = {host2);
EXPORT_SYMBOL(phy1);
struct controller_info host2 = {phy1};
EXPORT_SYMBOL(host2);
I meant something like this
struct phy_info {
const char *name;
};
struct phy_platform_data {
.
.
struct phy_info *info;
};
struct usb_controller_platform_data {
.
.
struct phy_info *info;
};
struct phy_info phy_info;
While creating the phy device
struct phy_platform_data phy_data;
[PATCH 1/1] arm: dts: dra7-evm: add sd/eMMC node
Add micro SD card and eMMC support for dra7-evm
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
arch/arm/boot/dts/dra7-evm.dts | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index cb0703c..4656ab4 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -17,4 +17,22 @@
device_type = memory;
reg = 0x8000 0x6000; /* 1536 MB */
};
+
+ vmmc_fixed: fixedregulator-mmc {
+ compatible = regulator-fixed;
+ regulator-name = vmmc_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ };
+};
+
+mmc1 {
+ vmmc-supply = vmmc_fixed;
+ bus-width = 4;
+};
+
+mmc2 {
+ vmmc-supply = vmmc_fixed;
+ bus-width = 8;
+ ti,non-removable;
};
--
1.7.5.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 v2 1/3] Input: omap-keypad: Cleanup - use bitfiled instead of hardcoded values
Hi, On Tue, Jul 23, 2013 at 07:09:56PM +0300, Illia Smyrnov wrote: Use bitfiled instead of hardcoded values to set KBD_CTRL, use BIT macro, remove unused defines. Signed-off-by: Illia Smyrnov illia.smyr...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/3] Input: omap-keypad: Convert to threaded IRQ
Hi,
On Tue, Jul 23, 2013 at 07:09:57PM +0300, Illia Smyrnov wrote:
Convert to use threaded IRQ.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Illia Smyrnov illia.smyr...@ti.com
---
drivers/input/keyboard/omap4-keypad.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index c727548..b876a0d 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -112,8 +112,22 @@ static void kbd_write_irqreg(struct omap4_keypad
*keypad_data,
}
-/* Interrupt handler */
-static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
+/* Interrupt handlers */
+static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
+{
+ struct omap4_keypad *keypad_data = dev_id;
+
+ if (kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS)) {
+ /* Disable interrupts */
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
+ OMAP4_VAL_IRQDISABLE);
+ return IRQ_WAKE_THREAD;
+ }
+
+ return IRQ_NONE;
+}
+
+static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
{
struct omap4_keypad *keypad_data = dev_id;
struct input_dev *input_dev = keypad_data-input;
@@ -121,10 +135,6 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
unsigned int col, row, code, changed;
u32 *new_state = (u32 *) key_state;
- /* Disable interrupts */
- kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
- OMAP4_VAL_IRQDISABLE);
looking a lot better, but I wonder if you should add a mutex to this
threaded handler, but I guess there's no way this will never race since
IRQs are masked anyway and registers are only accessed from within IRQ
handlers.
Reviewed-by: Felipe Balbi ba...@ti.com
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 3/3] Input: omap-keypad: Clear pending interrupts on open
Hi, On Tue, Jul 23, 2013 at 07:09:58PM +0300, Illia Smyrnov wrote: Clear pending interrupts when open keypad. where are these interrupts coming from ? Signed-off-by: Illia Smyrnov illia.smyr...@ti.com --- drivers/input/keyboard/omap4-keypad.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c index b876a0d..62abc3e 100644 --- a/drivers/input/keyboard/omap4-keypad.c +++ b/drivers/input/keyboard/omap4-keypad.c @@ -185,13 +185,14 @@ static int omap4_keypad_open(struct input_dev *input) (OMAP4_VAL_PVT OMAP4_DEF_CTRL_PTV_SHIFT)); kbd_writel(keypad_data, OMAP4_KBD_DEBOUNCINGTIME, OMAP4_VAL_DEBOUNCINGTIME); - kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS, - OMAP4_VAL_IRQDISABLE); kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE, OMAP4_DEF_IRQENABLE_EVENTEN | OMAP4_DEF_IRQENABLE_LONGKEY); kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE, OMAP4_DEF_WUP_EVENT_ENA | OMAP4_DEF_WUP_LONG_KEY_ENA); + /* clear pending interrupts */ + kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS, + kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS)); you might want to clear these interrupts before unmasking them :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 2/3] Input: omap-keypad: Convert to threaded IRQ
Hi,
On Tue, Jul 23, 2013 at 08:25:01PM +0300, Felipe Balbi wrote:
Convert to use threaded IRQ.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Illia Smyrnov illia.smyr...@ti.com
---
drivers/input/keyboard/omap4-keypad.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index c727548..b876a0d 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -112,8 +112,22 @@ static void kbd_write_irqreg(struct omap4_keypad
*keypad_data,
}
-/* Interrupt handler */
-static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
+/* Interrupt handlers */
+static irqreturn_t omap4_keypad_irq_handler(int irq, void *dev_id)
+{
+ struct omap4_keypad *keypad_data = dev_id;
+
+ if (kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS)) {
+ /* Disable interrupts */
+ kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
+OMAP4_VAL_IRQDISABLE);
+ return IRQ_WAKE_THREAD;
+ }
+
+ return IRQ_NONE;
+}
+
+static irqreturn_t omap4_keypad_irq_thread_fn(int irq, void *dev_id)
{
struct omap4_keypad *keypad_data = dev_id;
struct input_dev *input_dev = keypad_data-input;
@@ -121,10 +135,6 @@ static irqreturn_t omap4_keypad_interrupt(int irq,
void *dev_id)
unsigned int col, row, code, changed;
u32 *new_state = (u32 *) key_state;
- /* Disable interrupts */
- kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
-OMAP4_VAL_IRQDISABLE);
looking a lot better, but I wonder if you should add a mutex to this
threaded handler, but I guess there's no way this will never race since
s/never/ever
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself? If you
had a priv pointer to search from, then you could have just passed the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but let's try to
check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in some, not
so uncommon cases, but there is already a lot of existing lookup solutions
over the kernel and so there is no point in introducing another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
Please just pass the real phy pointer around, that's what it is there
for. Your board binding logic/code should be able to handle this, as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't really nice,
because it's a layering violation (at least if I understood what you mean).
This is because you need to have full definition of struct phy in board file
and a structure that is used as private data in PHY core comes from
platform code.
No, just a pointer, you don't need the full structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
thanks,
greg k-h
--
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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:05AM -0400, Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: Okay. Are PHYs _always_ platform devices? They can be i2c, spi or any other device types as well. In those other cases, presumably there is no platform data associated with the PHY since it isn't a platform device. Then how does the kernel know which controller is attached to the PHY? Is this spelled out in platform data associated with the PHY's i2c/spi/whatever parent? Platform data is nothing to do with the platform bus - it's board specific data (ie, data for the platform) and can be done with any device. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: I fully agree that a simple, single string will not scale even in some, not so uncommon cases, but there is already a lot of existing lookup solutions over the kernel and so there is no point in introducing another one. I'm trying to get _rid_ of lookup solutions and just use a real pointer, as you should. I'll go tackle those other ones after this one is taken care of, to show how the others should be handled as well. What are the problems you are seeing with doing things with lookups? Having to write platform data for everything gets old fast and the code duplication is pretty tedious... signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself? If
you
had a priv pointer to search from, then you could have just passed
the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but let's
try to check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
---
-8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
struct and other hardware parameters would it take?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in some,
not so uncommon cases, but there is already a lot of existing lookup
solutions over the kernel and so there is no point in introducing
another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was that in
board file there is no way to get a pointer to something that is going to be
created much later in time. We don't do time travel ;-).
Please just pass the real phy pointer around, that's what it is
there
for. Your board binding logic/code should be able to handle this,
as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't really
nice, because it's a layering violation (at least if I understood what
you mean). This is because you need to have full definition of struct
phy in board file and a structure that is used as private data in PHY
core comes from platform code.
No, just a pointer, you don't need the full structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be done,
considering how driver core and generic frameworks work.
Best regards,
Tomasz
--
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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: On Tue, Jul 23, 2013 at 10:37:11AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote: I fully agree that a simple, single string will not scale even in some, not so uncommon cases, but there is already a lot of existing lookup solutions over the kernel and so there is no point in introducing another one. I'm trying to get _rid_ of lookup solutions and just use a real pointer, as you should. I'll go tackle those other ones after this one is taken care of, to show how the others should be handled as well. What are the problems you are seeing with doing things with lookups? You don't know the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) Having to write platform data for everything gets old fast and the code duplication is pretty tedious... Adding a single pointer is tedious? Where is the name that you are going to lookup going to come from? That code doesn't write itself... thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] mfd: twl6030-irq: add error check when IRQs are masked initially
On 23/07/13 17:07, Grygorii Strashko wrote:
Add a missed check for errors when TWL IRQs are masked
initially on probe and report an error in case of failure.
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/mfd/twl6030-irq.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index b6030d9..790cc28 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -313,7 +313,7 @@ int twl6030_init_irq(struct device *dev, int irq_num)
struct device_node *node = dev-of_node;
int nr_irqs, irq_base, irq_end;
static struct irq_chip twl6030_irq_chip;
- int status = 0;
+ int status;
int i;
u8 mask[3];
@@ -335,11 +335,16 @@ int twl6030_init_irq(struct device *dev, int irq_num)
mask[2] = 0xFF;
/* mask all int lines */
- twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_LINE_A, 3);
+ status = twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_LINE_A, 3);
/* mask all int sts */
- twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_STS_A, 3);
+ status |= twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_MSK_STS_A, 3);
/* clear INT_STS_A,B,C */
- twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_STS_A, 3);
+ status |= twl_i2c_write(TWL_MODULE_PIH, mask[0], REG_INT_STS_A, 3);
+
You can save two i2c writes here for slightly faster initialisation,
only one of the REG_INT_STS_A registers needs to be written to clear
them all. As per the irq handling routine comment.
+ if (status 0) {
+ dev_err(dev, I2C err writing TWL_MODULE_PIH: %d\n, status);
+ return status;
+ }
twl6030_irq_base = irq_base;
Graeme
--
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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself? If
you
had a priv pointer to search from, then you could have just passed
the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but let's
try to check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
---
-8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data structure
unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would change
include/linux/platform_data/ata-pxa.h to have a phy pointer in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call to
phy_create(). Then you can use that pointer wherever that plaform data
is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What phy_ops
struct and other hardware parameters would it take?
The issue is that a string name is not going to scale at all, as it
requires hard-coded information that will change over time (as the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in some,
not so uncommon cases, but there is already a lot of existing lookup
solutions over the kernel and so there is no point in introducing
another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this one
is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was that in
board file there is no way to get a pointer to something that is going to be
created much later in time. We don't do time travel ;-).
Please just pass the real phy pointer around, that's what it is
there
for. Your board binding logic/code should be able to handle this,
as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't really
nice, because it's a layering violation (at least if I understood what
you mean). This is because you need to have full definition of struct
phy in board file and a structure that is used as private data in PHY
core comes from platform code.
No, just a pointer, you don't need the full structure until you get to
some .c code that actually manipulates the phy itself, for all other
places, you are just dealing with a pointer and a structure you never
reference.
Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be done,
considering how driver core and generic frameworks work.
Ok, given that I seem to be totally confused as to exactly how the
board-specific frameworks work, I'll take your word for it.
But again, I will not accept lookup by name type solutions, when the
name is dynamic and will change. Because you are using a name, you
can deal with a pointer, putting it _somewhere_ in your board-specific
data structures, as you are going to need to store it anyway (hint, you
had to get that name from somewhere, right?)
And maybe the way that these generic frameworks are created is wrong,
given that you don't feel that a generic pointer can be passed to the
needed devices. That seems like a huge problem, one that has already
been pointed out is causing issues with other subsystems.
So maybe they need to be fixed?
thanks,
greg k-h
--
To
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:01:10AM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 06:44:56PM +0100, Mark Brown wrote: What are the problems you are seeing with doing things with lookups? You don't know the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) I got copied in very late so don't have most of the thread I'm afraid, I did try looking at web archives but didn't see a clear problem statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. Having to write platform data for everything gets old fast and the code duplication is pretty tedious... Adding a single pointer is tedious? Where is the name that you are going to lookup going to come from? That code doesn't write itself... It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. signature.asc Description: Digital signature
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote:
IMHO it would be better if you provided some code example, but let's try to
check if I understood you correctly.
8
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
This should be controller_pdev, not phy_pdev, yes?
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
Or even just phy_get(pdev-dev), because phy_get() could be smart
enough to to set phy = dev-platform_data.
8
Is this what you mean?
That's what I was going to suggest too. The struct phy is defined in
the board file, which already knows about all the PHYs that exist in
the system. (Or perhaps it is allocated dynamically, so that when many
board files are present in the same kernel, only the entries listed in
the board file for the current system get created.) Then the
structure's address is stored in the platform data and made available
to both the provider and the consumer.
Even though the struct phy is defined (or allocated) in the board file,
its contents don't get filled in until the PHY driver provides the
details.
It's technically correct, but quality of this solution isn't really nice,
because it's a layering violation (at least if I understood what you mean).
This is because you need to have full definition of struct phy in board file
and a structure that is used as private data in PHY core comes from
platform code.
You don't have to have a full definition in the board file. Just a
partial definition -- most of the contents can be filled in later, when
the PHY driver is ready to store the private data.
It's not a layering violation for one region of the kernel to store
private data in a structure defined by another part of the kernel.
This happens all the time (e.g., dev_set_drvdata).
Alan Stern
--
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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: You don't know the id of the device you are looking up, due to multiple devices being in the system (dynamic ids, look back earlier in this thread for details about that.) I got copied in very late so don't have most of the thread I'm afraid, I did try looking at web archives but didn't see a clear problem statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. What do you mean by locally? The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a lookup based on the name and id (mushed together), because it knew that this device was the one it wanted. Just like the clock api, which, for multiple devices, has proven to cause problems. I don't want to see us accept an api that we know has issues in it now, I'd rather us fix it up properly. Subsystems should be able to create ids how ever they want to, and not rely on the code calling them to specify the names of the devices that way, otherwise the api is just too fragile. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on known names or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. Having to write platform data for everything gets old fast and the code duplication is pretty tedious... Adding a single pointer is tedious? Where is the name that you are going to lookup going to come from? That code doesn't write itself... It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. The clock api is having problems with multiple names due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. thanks, greg k-h -- 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 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
You don't know the id of the device you are looking up, due to
multiple devices being in the system (dynamic ids, look back earlier
in
this thread for details about that.)
I got copied in very late so don't have most of the thread I'm afraid,
I did try looking at web archives but didn't see a clear problem
statement. In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
What do you mean by locally?
The problem with the api was that the phy core wanted a id and a name to
create a phy, and then later other code was doing a lookup based on
the name and id (mushed together), because it knew that this device
was the one it wanted.
Just like the clock api, which, for multiple devices, has proven to
cause problems. I don't want to see us accept an api that we know has
issues in it now, I'd rather us fix it up properly.
Subsystems should be able to create ids how ever they want to, and not
rely on the code calling them to specify the names of the devices that
way, otherwise the api is just too fragile.
I think, that if you create a device, then just carry around the pointer
to that device (in this case a phy) and pass it to whatever other code
needs it. No need to do lookups on known names or anything else,
just normal pointers, with no problems for multiple devices, busses, or
naming issues.
PHY object is not a device, it is something that a device driver creates
(one or more instances of) when it is being probed. You don't have a clean
way to export this PHY object to other driver, other than keeping this PHY
on a list inside PHY core with some well-known ID (e.g. device name +
consumer port name/index, like in regulator core) and then to use this
well-known ID inside consumer driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for regulators
might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't
receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = foo-ehci,
.port = usbphy,
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = foo-otg,
.port = otgphy,
},
};
static const struct phy_init_data my_phys[] = {
{
.name = USB 2.0 PHY 0,
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = USB 2.0 PHY 1,
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = foo-usbphy,
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev-dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(foo-phy[i], init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, usbphy);
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, otgphy);
/* ... */
}
Having to write platform data for everything gets old fast and the
code
duplication is pretty tedious...
Adding a single pointer is tedious? Where is the name that you
are
going to lookup going to come from? That code doesn't write
itself...
It's adding platform data in the first place that gets tedious - and
of
course there's also DT and ACPI to worry about, it's not just a case
of
platform data and then you're done. Pushing the lookup into library
code means that drivers don't have to worry about any of this stuff.
I agree, so just pass around the pointer to the phy and all is good. No
need to worry about DT or ACPI or anything else.
With Device Tree we don't have board files anymore. How would
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 15:36:00 Alan Stern wrote:
On Tue, 23 Jul 2013, Tomasz Figa wrote:
IMHO it would be better if you provided some code example, but let's
try to check if I understood you correctly.
8---
-
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
This should be controller_pdev, not phy_pdev, yes?
Right. A copy-pasto.
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
Or even just phy_get(pdev-dev), because phy_get() could be smart
enough to to set phy = dev-platform_data.
Unless you need more than one PHY in this driver...
--
--8
Is this what you mean?
That's what I was going to suggest too. The struct phy is defined in
the board file, which already knows about all the PHYs that exist in
the system. (Or perhaps it is allocated dynamically, so that when many
board files are present in the same kernel, only the entries listed in
the board file for the current system get created.)
Well, such dynamic allocation is a must. We don't accept non-multiplatform
aware code anymore, not even saying about multiboard.
Then the
structure's address is stored in the platform data and made available
to both the provider and the consumer.
Yes, technically this can work. You would still have to perform some kind
of synchronization to make sure that the PHY bound to this structure is
actually present. This is again technically doable (e.g. a list of
registered struct phys inside PHY core).
Even though the struct phy is defined (or allocated) in the board file,
its contents don't get filled in until the PHY driver provides the
details.
You can't assure this. Board file is free to do whatever it wants with
this struct. A clean solution would prevent this.
It's technically correct, but quality of this solution isn't really
nice, because it's a layering violation (at least if I understood
what you mean). This is because you need to have full definition of
struct phy in board file and a structure that is used as private data
in PHY core comes from platform code.
You don't have to have a full definition in the board file. Just a
partial definition -- most of the contents can be filled in later, when
the PHY driver is ready to store the private data.
It's not a layering violation for one region of the kernel to store
private data in a structure defined by another part of the kernel.
This happens all the time (e.g., dev_set_drvdata).
Not really. The phy struct is something that _is_ private data of PHY
subsystem, not something that can store private data of PHY subsystem
(sure it can store private data of particular PHY driver, but that's
another story) and only PHY subsystem should have access to its contents.
By the way, we need to consider other cases here as well, for example it
would be nice to have a single phy_get() function that works for both non-
DT and DT cases to make the consumer driver not have to worry whether it's
being probed from DT or not.
I'd suggest simply reusing the lookup method of regulator framework, just
as I suggested here:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813/focus=101661
Best regards,
Tomasz
--
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 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 11:04:14 Greg KH wrote:
On Tue, Jul 23, 2013 at 07:48:11PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 10:37:11 Greg KH wrote:
On Tue, Jul 23, 2013 at 06:50:29PM +0200, Tomasz Figa wrote:
Ick, no. Why can't you just pass the pointer to the phy itself?
If
you
had a priv pointer to search from, then you could have just
passed
the
original phy pointer in the first place, right?
IMHO it would be better if you provided some code example, but
let's
try to check if I understood you correctly.
It's not my code that I want to have added, so I don't have to write
examples, I just get to complain about the existing stuff :)
Still, I think that some small code snippets illustrating the idea are
really helpful.
8---
-
[Board file]
static struct phy my_phy;
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
static struct platform_device phy_pdev = {
/* ... */
.platform_data = my_phy;
/* ... */
};
[Provider driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_create(phy);
[Consumer driver]
struct phy *phy = pdev-dev.platform_data;
ret = phy_get(pdev-dev, phy);
--
-
-8
Is this what you mean?
No. Well, kind of. What's wrong with using the platform data
structure unique to the board to have the pointer?
For example (just randomly picking one), the ata-pxa driver would
change include/linux/platform_data/ata-pxa.h to have a phy pointer
in it:
struct phy;
struct pata_pxa_pdata {
/* PXA DMA DREQ0:2 pin */
uint32_tdma_dreq;
/* Register shift */
uint32_treg_shift;
/* IRQ flags */
uint32_tirq_flags;
/* PHY */
struct phy *phy;
};
Then, when you create the platform, set the phy* pointer with a call
to
phy_create(). Then you can use that pointer wherever that plaform
data
is available (i.e. whereever platform_data is at).
Hmm? So, do you suggest to call phy_create() from board file? What
phy_ops struct and other hardware parameters would it take?
The issue is that a string name is not going to scale at all,
as it
requires hard-coded information that will change over time (as
the
existing clock interface is already showing.)
I fully agree that a simple, single string will not scale even in
some,
not so uncommon cases, but there is already a lot of existing
lookup
solutions over the kernel and so there is no point in introducing
another one.
I'm trying to get _rid_ of lookup solutions and just use a real
pointer, as you should. I'll go tackle those other ones after this
one
is taken care of, to show how the others should be handled as well.
There was a reason for introducing lookup solutions. The reason was
that in board file there is no way to get a pointer to something that
is going to be created much later in time. We don't do time travel
;-).
Please just pass the real phy pointer around, that's what it
is
there
for. Your board binding logic/code should be able to handle
this,
as
it somehow was going to do the same thing with a name.
It's technically correct, but quality of this solution isn't
really
nice, because it's a layering violation (at least if I understood
what
you mean). This is because you need to have full definition of
struct
phy in board file and a structure that is used as private data in
PHY
core comes from platform code.
No, just a pointer, you don't need the full structure until you
get to some .c code that actually manipulates the phy itself, for
all other places, you are just dealing with a pointer and a
structure you never reference.
Does that make more sense?
Well, to the point that I think I now understood your suggestion.
Unfortunately the suggestion alone isn't really something that can be
done, considering how driver core and generic frameworks work.
Ok, given that I seem to be totally confused as to exactly how the
board-specific frameworks work, I'll take your word for it.
Well, they are working in a way that keeps separation of layers, making
things clean. Platform code should not (well, there might exist some in
tree hacks, but this should not be propagated) used to exchange data
between drivers, but rather to specify board specific parameters for
generic drivers. If drivers need to cooperate, there must be a dedicated
interface for
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
You don't know the id of the device you are looking up, due to
multiple devices being in the system (dynamic ids, look back earlier
in
this thread for details about that.)
I got copied in very late so don't have most of the thread I'm afraid,
I did try looking at web archives but didn't see a clear problem
statement. In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
What do you mean by locally?
The problem with the api was that the phy core wanted a id and a name to
create a phy, and then later other code was doing a lookup based on
the name and id (mushed together), because it knew that this device
was the one it wanted.
Just like the clock api, which, for multiple devices, has proven to
cause problems. I don't want to see us accept an api that we know has
issues in it now, I'd rather us fix it up properly.
Subsystems should be able to create ids how ever they want to, and not
rely on the code calling them to specify the names of the devices that
way, otherwise the api is just too fragile.
I think, that if you create a device, then just carry around the pointer
to that device (in this case a phy) and pass it to whatever other code
needs it. No need to do lookups on known names or anything else,
just normal pointers, with no problems for multiple devices, busses, or
naming issues.
PHY object is not a device, it is something that a device driver creates
(one or more instances of) when it is being probed.
But you created a 'struct device' for it, so I think of it as a device
be it virtual or real :)
You don't have a clean way to export this PHY object to other driver,
other than keeping this PHY on a list inside PHY core with some
well-known ID (e.g. device name + consumer port name/index, like in
regulator core) and then to use this well-known ID inside consumer
driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for
regulators might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and wouldn't
receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = foo-ehci,
.port = usbphy,
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = foo-otg,
.port = otgphy,
},
};
static const struct phy_init_data my_phys[] = {
{
.name = USB 2.0 PHY 0,
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = USB 2.0 PHY 1,
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = foo-usbphy,
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev-dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(foo-phy[i], init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, usbphy);
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, otgphy);
/* ... */
}
That's not so bad, as long as you let the phy core use whatever name it
wants for the device when it registers it with sysfs. Use the name you
are requesting as a tag or some such hint as to what the phy can be
looked up by.
Good luck handling duplicate tags :)
thanks,
greg k-h
--
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 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: That's what I was going to suggest too. The struct phy is defined in the board file, which already knows about all the PHYs that exist in the system. (Or perhaps it is allocated dynamically, so that when many board files are present in the same kernel, only the entries listed in the board file for the current system get created.) Well, such dynamic allocation is a must. We don't accept non-multiplatform aware code anymore, not even saying about multiboard. Then the structure's address is stored in the platform data and made available to both the provider and the consumer. Yes, technically this can work. You would still have to perform some kind of synchronization to make sure that the PHY bound to this structure is actually present. This is again technically doable (e.g. a list of registered struct phys inside PHY core). The synchronization takes place inside phy_get. If phy_create hasn't been called for this structure by the time phy_get runs, phy_get will return an error. Even though the struct phy is defined (or allocated) in the board file, its contents don't get filled in until the PHY driver provides the details. You can't assure this. Board file is free to do whatever it wants with this struct. A clean solution would prevent this. I'm not sure what you mean here. Of course I can't prevent a board file from messing up a data structure. I can't prevent it from causing memory access violations either; in fact, I can't prevent any bugs in other people's code. Besides, why do you say the board file is free to do whatever it wants with the struct phy? Currently the struct phy is created by the PHY provider and the PHY core, right? It's not even mentioned in the board file. It's technically correct, but quality of this solution isn't really nice, because it's a layering violation (at least if I understood what you mean). This is because you need to have full definition of struct phy in board file and a structure that is used as private data in PHY core comes from platform code. You don't have to have a full definition in the board file. Just a partial definition -- most of the contents can be filled in later, when the PHY driver is ready to store the private data. It's not a layering violation for one region of the kernel to store private data in a structure defined by another part of the kernel. This happens all the time (e.g., dev_set_drvdata). Not really. The phy struct is something that _is_ private data of PHY subsystem, not something that can store private data of PHY subsystem (sure it can store private data of particular PHY driver, but that's another story) and only PHY subsystem should have access to its contents. If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. By the way, we need to consider other cases here as well, for example it would be nice to have a single phy_get() function that works for both non- DT and DT cases to make the consumer driver not have to worry whether it's being probed from DT or not. You ought to be able to adapt this scheme to work with DT. Maybe by having multiple phy_address arrays. Alan Stern -- 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 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 16:53:55 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: That's what I was going to suggest too. The struct phy is defined in the board file, which already knows about all the PHYs that exist in the system. (Or perhaps it is allocated dynamically, so that when many board files are present in the same kernel, only the entries listed in the board file for the current system get created.) Well, such dynamic allocation is a must. We don't accept non-multiplatform aware code anymore, not even saying about multiboard. Then the structure's address is stored in the platform data and made available to both the provider and the consumer. Yes, technically this can work. You would still have to perform some kind of synchronization to make sure that the PHY bound to this structure is actually present. This is again technically doable (e.g. a list of registered struct phys inside PHY core). The synchronization takes place inside phy_get. If phy_create hasn't been called for this structure by the time phy_get runs, phy_get will return an error. Yes, this is the solution that I had in mind when saying that this is doable. Even though the struct phy is defined (or allocated) in the board file, its contents don't get filled in until the PHY driver provides the details. You can't assure this. Board file is free to do whatever it wants with this struct. A clean solution would prevent this. I'm not sure what you mean here. Of course I can't prevent a board file from messing up a data structure. I can't prevent it from causing memory access violations either; in fact, I can't prevent any bugs in other people's code. Besides, why do you say the board file is free to do whatever it wants with the struct phy? Currently the struct phy is created by the PHY provider and the PHY core, right? It's not even mentioned in the board file. I mean, if you have a struct type of which full declaration is available for some code, this code can access any memeber of it without any hacks, which is not something that we want to have in board files. The phy struct should be opaque for them. It's technically correct, but quality of this solution isn't really nice, because it's a layering violation (at least if I understood what you mean). This is because you need to have full definition of struct phy in board file and a structure that is used as private data in PHY core comes from platform code. You don't have to have a full definition in the board file. Just a partial definition -- most of the contents can be filled in later, when the PHY driver is ready to store the private data. It's not a layering violation for one region of the kernel to store private data in a structure defined by another part of the kernel. This happens all the time (e.g., dev_set_drvdata). Not really. The phy struct is something that _is_ private data of PHY subsystem, not something that can store private data of PHY subsystem (sure it can store private data of particular PHY driver, but that's another story) and only PHY subsystem should have access to its contents. If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. By the way, we need to consider other cases here as well, for example it would be nice to have a single phy_get() function that works for both non- DT and DT cases to make the consumer driver not have to worry whether it's being probed from DT or not. You ought to be able to adapt this scheme to work with DT. Maybe by having multiple phy_address arrays. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only to pass data from it to drivers, not the other way. Ideally all data in a board file should be marked as const and __init and dropped after system initialization. Best regards, Tomasz -- To
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 13:50:07 Greg KH wrote:
On Tue, Jul 23, 2013 at 10:07:52PM +0200, Tomasz Figa wrote:
On Tuesday 23 of July 2013 12:44:23 Greg KH wrote:
On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote:
You don't know the id of the device you are looking up, due to
multiple devices being in the system (dynamic ids, look back
earlier
in
this thread for details about that.)
I got copied in very late so don't have most of the thread I'm
afraid,
I did try looking at web archives but didn't see a clear problem
statement. In any case this is why the APIs doing lookups do the
lookups in the context of the requesting device - devices ask for
whatever name they use locally.
What do you mean by locally?
The problem with the api was that the phy core wanted a id and a
name to create a phy, and then later other code was doing a
lookup based on the name and id (mushed together), because it
knew that this device was the one it wanted.
Just like the clock api, which, for multiple devices, has proven to
cause problems. I don't want to see us accept an api that we know
has
issues in it now, I'd rather us fix it up properly.
Subsystems should be able to create ids how ever they want to, and
not
rely on the code calling them to specify the names of the devices
that
way, otherwise the api is just too fragile.
I think, that if you create a device, then just carry around the
pointer to that device (in this case a phy) and pass it to whatever
other code needs it. No need to do lookups on known names or
anything else, just normal pointers, with no problems for multiple
devices, busses, or naming issues.
PHY object is not a device, it is something that a device driver
creates (one or more instances of) when it is being probed.
But you created a 'struct device' for it, so I think of it as a device
be it virtual or real :)
Keep in mind that those virtual devices are created by PHY driver bound to
a real device and one real device can have multiple virtual devices behind
it.
You don't have a clean way to export this PHY object to other driver,
other than keeping this PHY on a list inside PHY core with some
well-known ID (e.g. device name + consumer port name/index, like in
regulator core) and then to use this well-known ID inside consumer
driver as a lookup key passed to phy_get();
Actually I think for PHY case, exactly the same way as used for
regulators might be completely fine:
1. Each PHY would have some kind of platform, non-unique name, that is
just used to print some messages (like the platform/board name of a
regulator).
2. Each PHY would have an array of consumers. Consumer specifier would
consist of consumer device name and consumer port name - just like in
regulator subsystem.
3. PHY driver receives an array of, let's say, phy_init_data inside
its
platform data that it would use to register its PHYs.
4. Consumer drivers would have constant consumer port names and
wouldn't receive any information about PHYs from platform code.
Code example:
[Board file]
static const struct phy_consumer_data usb_20_phy0_consumers[] = {
{
.devname = foo-ehci,
.port = usbphy,
},
};
static const struct phy_consumer_data usb_20_phy1_consumers[] = {
{
.devname = foo-otg,
.port = otgphy,
},
};
static const struct phy_init_data my_phys[] = {
{
.name = USB 2.0 PHY 0,
.consumers = usb_20_phy0_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy0_consumers),
},
{
.name = USB 2.0 PHY 1,
.consumers = usb_20_phy1_consumers,
.num_consumers = ARRAY_SIZE(usb_20_phy1_consumers),
},
{ }
};
static const struct platform_device usb_phy_pdev = {
.name = foo-usbphy,
.id = -1,
.dev = {
.platform_data = my_phys,
},
};
[PHY driver]
static int foo_usbphy_probe(pdev)
{
struct foo_usbphy *foo;
struct phy_init_data *init_data = pdev-dev.platform_data;
/* ... */
// for each PHY in init_data {
phy_register(foo-phy[i], init_data[i]);
// }
/* ... */
}
[EHCI driver]
static int foo_ehci_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, usbphy);
/* ... */
}
[OTG driver]
static int foo_otg_probe(pdev)
{
struct phy *phy;
/* ... */
phy = phy_get(pdev-dev, otgphy);
/* ... */
}
That's not so bad, as long as you let the phy core use whatever name it
wants for the device when it registers it with sysfs.
Yes, in regulator core
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Tue, 23 Jul 2013, Tomasz Figa wrote: If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. There's no reason the phy_address things have to be arrays. A separate individual pointer for each PHY would work just as well. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only to pass data from it to drivers, not the other way. Ideally all data in a board file should be marked as const and __init and dropped after system initialization. The phy_address things don't have to be defined or allocated in the board file; they could be set up along with the platform data. In any case, this was simply meant to be a suggestion to show that it is relatively easy to do what you need without using name or ID strings. Alan Stern -- 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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 11:05:48PM +0200, Tomasz Figa wrote: That's not so bad, as long as you let the phy core use whatever name it wants for the device when it registers it with sysfs. Yes, in regulator core consumer names are completely separated from this. Regulator core simply assigns a sequential integer ID to each regulator and registers /sys/class/regulator/regulator.ID for each regulator. Yes, that's fine. Use the name you are requesting as a tag or some such hint as to what the phy can be looked up by. Good luck handling duplicate tags :) The tag alone is not a key. Lookup key consists of two components, consumer device name and consumer tag. What kind of duplicate tags can be a problem here? Ok, I didn't realize it looked at both parts, that makes sense, thanks. greg k-h -- 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 01/15] drivers: phy: add generic PHY framework
On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote: On Tue, 23 Jul 2013, Tomasz Figa wrote: If you want to keep the phy struct completely separate from the board file, there's an easy way to do it. Let's say the board file knows about N different PHYs in the system. Then you define an array of N pointers to phys: struct phy *(phy_address[N]); In the platform data for both PHY j and its controller, store phy_address[j]. The PHY provider passes this cookie to phy_create: cookie = pdev-dev.platform_data; ret = phy_create(phy, cookie); and phy_create simply stores: *cookie = phy. The PHY consumer does much the same the same thing: cookie = pdev-dev.platform_data; phy = phy_get(cookie); phy_get returns *cookie if it isn't NULL, or an ERR_PTR otherwise. OK, this can work. Again, just technically, because it's rather ugly. There's no reason the phy_address things have to be arrays. A separate individual pointer for each PHY would work just as well. Where would you want to have those phy_address arrays stored? There are no board files when booting with DT. Not even saying that you don't need to use any hacky schemes like this when you have DT that nicely specifies relations between devices. If everybody agrees DT has a nice scheme for specifying relations between devices, why not use that same scheme in the PHY core? It is already used, for cases when consumer device has a DT node attached. In non-DT case this kind lookup translates loosely to something that is being done in regulator framework - you can't bind devices by pointers, because you don't have those pointers, so you need to use device names. Anyway, board file should not be considered as a method to exchange data between drivers. It should be used only to pass data from it to drivers, not the other way. Ideally all data in a board file should be marked as const and __init and dropped after system initialization. The phy_address things don't have to be defined or allocated in the board file; they could be set up along with the platform data. There is no platform data when booting with DT. In any case, this was simply meant to be a suggestion to show that it is relatively easy to do what you need without using name or ID strings. Sure. It's good to have different options discussed as well. Best regards, Tomasz -- 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 01/15] drivers: phy: add generic PHY framework
On Tue, Jul 23, 2013 at 12:44:23PM -0700, Greg KH wrote: On Tue, Jul 23, 2013 at 08:31:05PM +0100, Mark Brown wrote: statement. In any case this is why the APIs doing lookups do the lookups in the context of the requesting device - devices ask for whatever name they use locally. What do you mean by locally? Within themselves - for example a regulator consumer asks for a given supply on the device in terms of the supply names the device has. The problem with the api was that the phy core wanted a id and a name to create a phy, and then later other code was doing a lookup based on the name and id (mushed together), because it knew that this device was the one it wanted. Ah, that sounds like the API is missing a component to link things together. But I could be wrong. What I would expect to see is that the consumer says I want the PHY called X and the PHY driver says I provide this set of PHYs with a layer in between that plugs those together. This would normally involve talking about the parent device rather than the PHY itself. I think, that if you create a device, then just carry around the pointer to that device (in this case a phy) and pass it to whatever other code needs it. No need to do lookups on known names or anything else, just normal pointers, with no problems for multiple devices, busses, or naming issues. I think you're not really talking about the lookup API at all here but rather about one way in which the matching code can be written. What everything *really* wants to do is work in terms of resources namespaced within struct devices since every bit of hardware in the system should have one of those it can use and if you have a struct device you can do useful things like call dev_printk() and find the device tree data to do device tree based lookups. Unfortunately for a number of buses even when statically registering the struct device doesn't get allocated until the device is probed so what everyone fell back on doing was using dev_name() in cases where the struct device wasn't there yet, or just always using it for consistency since for most of the affected buses dev_name() is fixed for human interface reasons. I think this is the issue you're concerned about here since if the dev_name() is dynamically allocated this breaks down. This only affects board files, DT and ACPI can both use their own data structures to do the mapping. I had thought you were talking about picking the names that the consumers use (which isn't actually that big a deal, it's just a bit annoying for the clock API). It's adding platform data in the first place that gets tedious - and of course there's also DT and ACPI to worry about, it's not just a case of platform data and then you're done. Pushing the lookup into library code means that drivers don't have to worry about any of this stuff. I agree, so just pass around the pointer to the phy and all is good. No need to worry about DT or ACPI or anything else. No, in practice passing around the pointer gets tricky if you're using something other than board files (or even are doing any kind of dynamic stuff with board files) since the two devices need to find each other and if you're using platform data then the code doing the matching has to know about the platform data for every device it might need to match which is just miserable. Something would need to do something like allocate the PHY objects and then arrange for them to be passed to both provider and consumer devices prior to those being registered, knowing where to place the pointers in the platform data for each device. This is straightforward with board files but not otherwise, people have tried this before. For most of the APIs doing this there is a clear and unambiguous name in the hardware that can be used (and for hardware process reasons is unlikely to get changed). The major exception to this is the clock API since it is relatively rare to have clear, segregated IP level information for IPs baked into larger chips. The other APIs tend to be establishing chip to chip links. The clock api is having problems with multiple names due to dynamic devices from what I was told. I want to prevent the PHY interface from having that same issue. I think the underlying issue here is that we don't have a good enough general way for board files (or other C code but mostly them) to talk about devices prior to their being registered - rather than have the pointer you're talking about be the PHY object itself have the pointer be something which allows us to match the struct device when it's created. This should be transparent to drivers and would be usable by all the existing APIs. signature.asc Description: Digital signature
