Skip to contentSkip to conversation

Migrate PXA27x platforms to clock framework

PATCH Superseded Robert Jarzmik 5 participants 24 messages Jul 30, 2014 – Sep 30, 2014

Subsystems (5)
Device tree bindings Arm (32-bit) Arm sub-architectures Common clk +1 more subsystems
lore
Share & tools
lore

Robert Jarzmik

author maintainer
#0 lore raw

v3 cover Migrate PXA27x platforms to clock framework

This is the third opus of this serie.

Quoted 1 line

From the previous one :

- the boot ordering was fixed
For DT, we rely on time_init() in arch/arm
For non-DT, we keep the postcore_init() until all 3 PXA variants are converted, and meanwhile I'll discuss with Haojian where to call directly the clocks init function.
- the section mismatches were fixed
A split is done between CKEN clock descriptor and CKEN clock structure

The result was tested with a Mitac MIO A701 :
- with the upstream platform-data based machine code
- with the device-tree version

As for the patches, if they are carried fully by Mike, I think there will be a minor conflict in arch/arm/mach-pxa/Makefile with the clocksource patches I submitted earlier.

As before, the goal remains the same :
- keeping legacy platforms working (ie. without device-tree)
- enable PXA27x to work with a device-tree kernel, and hence open the way to drivers conversion
- be robust enough to support pxa25x and pxa3xx later inclusion with almost no change to clk-pxa-dt.c.

Robert Jarzmik (6):
clk: add pxa clocks infrastructure
clk: dts: document pxa clock binding
arm: pxa: add clock pll selection bits
clk: add pxa27x clock drivers
dts: add devicetree bindings for pxa27x clocks
arm: pxa: Transition pxa27x to clk framework

 .../devicetree/bindings/clock/pxa-clock.txt        |  16 +
 arch/arm/Kconfig                                   |   1 +
 arch/arm/boot/dts/pxa27x.dtsi                      |  20 +-
 arch/arm/mach-pxa/Makefile                         |   8 +-
 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h       |  10 +
 arch/arm/mach-pxa/pxa27x.c                         | 186 +----------
 drivers/clk/Makefile                               |   1 +
 drivers/clk/pxa/Makefile                           |   2 +
 drivers/clk/pxa/clk-pxa.c                          |  97 ++++++
 drivers/clk/pxa/clk-pxa.h                          | 107 ++++++
 drivers/clk/pxa/clk-pxa27x.c                       | 370 +++++++++++++++++++++
 include/dt-bindings/clock/pxa-clock.h              |  77 +++++
 12 files changed, 716 insertions(+), 179 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/pxa-clock.txt
 create mode 100644 drivers/clk/pxa/Makefile
 create mode 100644 drivers/clk/pxa/clk-pxa.c
 create mode 100644 drivers/clk/pxa/clk-pxa.h
 create mode 100644 drivers/clk/pxa/clk-pxa27x.c
 create mode 100644 include/dt-bindings/clock/pxa-clock.h
Signature · 1 line
2.0.0.rc2
author maintainer
#1 lore raw

PATCH v3 1/6 clk: add pxa clocks infrastructure

Add a the common code used by all PXA variants.

This is the first step in the transition from architecture defined clocks (in arch/arm/mach-pxa) towards clock framework. The goal is to have the same features (and not all the features) of the existing clocks, and enable the transition of PXA to device-tree.

All PXA rely on a "CKEN" type clock, which :
- has a gate (bit in CKEN register)
- is generated from a PLL, generally divided
- has an alternate low power clock

Each variant will specialize the CKEN clock :
- pxa25x have no low power clock
- pxa27x in low power use always the 13 MHz ring oscillator
- pxa3xx in low power have specific dividers for each clock

The device-tree provides a list of CLK_* (ex: CLK_USB or CLK_I2C) to get a handle on the clock. While pxa-clock.h will describe all the clocks of all the variants, each variant will only use a subset of it.

Signed-off-by Robert Jarzmik <[email protected]>
---
 drivers/clk/Makefile                  |   1 +
 drivers/clk/pxa/Makefile              |   1 +
 drivers/clk/pxa/clk-pxa.c             |  97 ++++++++++++++++++++++++++++++
 drivers/clk/pxa/clk-pxa.h             | 107 ++++++++++++++++++++++++++++++++++
 include/dt-bindings/clock/pxa-clock.h |  77 ++++++++++++++++++++++++
 5 files changed, 283 insertions(+)
 create mode 100644 drivers/clk/pxa/Makefile
 create mode 100644 drivers/clk/pxa/clk-pxa.c
 create mode 100644 drivers/clk/pxa/clk-pxa.h
 create mode 100644 include/dt-bindings/clock/pxa-clock.h
drivers/clk/Makefile +1 -0
index 567f102..40390ea 100644
@@ -43,6 +43,7 @@ obj-$(CONFIG_ARCH_MMP)			+= mmp/
 endif
 obj-$(CONFIG_PLAT_ORION)		+= mvebu/
 obj-$(CONFIG_ARCH_MXS)			+= mxs/
+obj-$(CONFIG_ARCH_PXA)			+= pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)		+= qcom/
 obj-$(CONFIG_ARCH_ROCKCHIP)		+= rockchip/
 obj-$(CONFIG_COMMON_CLK_SAMSUNG)	+= samsung/
drivers/clk/pxa/Makefile new file +1 -0
new file mode 100644
index 0000000..cb2bd8f
@@ -0,0 +1 @@
+obj-y				+= clk-pxa.o
drivers/clk/pxa/clk-pxa.c new file +97 -0

97 lines not on this page · raw message

drivers/clk/pxa/clk-pxa.h new file +107 -0

107 lines not on this page · raw message

include/dt-bindings/clock/pxa-clock.h new file +77 -0

77 lines not on this page · raw message

Signature · 1 line
2.0.0.rc2
maintainer
#2 lore raw

PATCH v3 1/6 clk: add pxa clocks infrastructure

Quoted 115 lines · Robert Jarzmik

Add a the common code used by all PXA variants.

This is the first step in the transition from architecture defined clocks (in arch/arm/mach-pxa) towards clock framework. The goal is to have the same features (and not all the features) of the existing clocks, and enable the transition of PXA to device-tree.

All PXA rely on a "CKEN" type clock, which :
- has a gate (bit in CKEN register)
- is generated from a PLL, generally divided
- has an alternate low power clock

Each variant will specialize the CKEN clock :
- pxa25x have no low power clock
- pxa27x in low power use always the 13 MHz ring oscillator
- pxa3xx in low power have specific dividers for each clock

The device-tree provides a list of CLK_* (ex: CLK_USB or CLK_I2C) to get a handle on the clock. While pxa-clock.h will describe all the clocks of all the variants, each variant will only use a subset of it.

Signed-off-by Robert Jarzmik <[email protected]>
---
 drivers/clk/Makefile                  |   1 +
 drivers/clk/pxa/Makefile              |   1 +
 drivers/clk/pxa/clk-pxa.c             |  97 ++++++++++++++++++++++++++++++
 drivers/clk/pxa/clk-pxa.h             | 107 ++++++++++++++++++++++++++++++++++
 include/dt-bindings/clock/pxa-clock.h |  77 ++++++++++++++++++++++++
 5 files changed, 283 insertions(+)
 create mode 100644 drivers/clk/pxa/Makefile
 create mode 100644 drivers/clk/pxa/clk-pxa.c
 create mode 100644 drivers/clk/pxa/clk-pxa.h
 create mode 100644 include/dt-bindings/clock/pxa-clock.h
drivers/clk/Makefile +1 -0
index 567f102..40390ea 100644
@@ -43,6 +43,7 @@ obj-$(CONFIG_ARCH_MMP)                        += mmp/
 endif
 obj-$(CONFIG_PLAT_ORION)               += mvebu/
 obj-$(CONFIG_ARCH_MXS)                 += mxs/
+obj-$(CONFIG_ARCH_PXA)                 += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)          += qcom/
 obj-$(CONFIG_ARCH_ROCKCHIP)            += rockchip/
 obj-$(CONFIG_COMMON_CLK_SAMSUNG)       += samsung/
drivers/clk/pxa/Makefile new file +1 -0
new file mode 100644
index 0000000..cb2bd8f
@@ -0,0 +1 @@
+obj-y                          += clk-pxa.o
drivers/clk/pxa/clk-pxa.c new file +56 -0
new file mode 100644
index 0000000..ef3c053
@@ -0,0 +1,97 @@
+/*
+ * Marvell PXA family clocks
+ *
+ * Copyright (C) 2014 Robert Jarzmik
+ *
+ * Common clock code for PXA clocks ("CKEN" type clocks + DT)
+ *
+ * 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 of the License.
+ *
+ */
+#include <linux/clk.h>
+#include <linux/clk-provider.h>
+#include <linux/clkdev.h>
+#include <linux/of.h>
+
+#include <dt-bindings/clock/pxa-clock.h>
+#include "clk-pxa.h"
+
+DEFINE_SPINLOCK(lock);
+
+static struct clk *pxa_clocks[CLK_MAX];
+static struct clk_onecell_data onecell_data = {
+       .clks = pxa_clocks,
+       .clk_num = CLK_MAX,
+};
+
+#define to_pxa_clk(_hw) container_of(_hw, struct pxa_clk_cken, hw)
+
+static unsigned long cken_recalc_rate(struct clk_hw *hw,
+                                     unsigned long parent_rate)
+{
+       struct pxa_clk_cken *pclk = to_pxa_clk(hw);
+       struct clk_fixed_factor *fix;
+
+       if (!pclk->is_in_low_power || pclk->is_in_low_power())
+               fix = &pclk->lp;
+       else
+               fix = &pclk->hp;
+       fix->hw.clk = hw->clk;
+       return clk_fixed_factor_ops.recalc_rate(&fix->hw, parent_rate);
+}
+
+static struct clk_ops cken_rate_ops = {
+       .recalc_rate = cken_recalc_rate,
+};
+
+static u8 cken_get_parent(struct clk_hw *hw)
+{
+       struct pxa_clk_cken *pclk = to_pxa_clk(hw);
+
+       if (!pclk->is_in_low_power)
+               return 0;
+       return pclk->is_in_low_power() ? 0 : 1;
+}

drivers/clk/pxa/clk-pxa.c line 66

Quoted 10 lines
drivers/clk/pxa/clk-pxa.c new file +10 -0
+
+static struct clk_ops cken_mux_ops = {
+       .get_parent = cken_get_parent,
+       .set_parent = dummy_clk_set_parent,
+};
+
+void __init clkdev_pxa_register(int ckid, const char *con_id,
+                               const char *dev_id, struct clk *clk)
+{
+       if (!IS_ERR(clk) && (ckid != CLK_NONE))

Will you specify CLK_NONE in clock driver? It seems that CLK_NONE isn't used in pxa27x clock driver. And pxa_clocks[0] is not used. Is it redundant?

Quoted 230 lines
drivers/clk/pxa/clk-pxa.c new file +31 -0
+               pxa_clocks[ckid] = clk;
+       if (!IS_ERR(clk))
+               clk_register_clkdev(clk, con_id, dev_id);
+}
+
+int __init clk_pxa_cken_init(struct pxa_clk_cken *clks, int nb_clks)
+{
+       int i;
+       struct pxa_clk_cken *pclk;
+       struct clk *clk;
+
+       for (i = 0; i < nb_clks; i++) {
+               pclk = clks + i;
+               pclk->gate.lock = &lock;
+               clk = clk_register_composite(NULL, pclk->name,
+                                            pclk->parent_names, 2,
+                                            &pclk->hw, &cken_mux_ops,
+                                            &pclk->hw, &cken_rate_ops,
+                                            &pclk->gate.hw, &clk_gate_ops,
+                                            pclk->flags);
+               clkdev_pxa_register(pclk->ckid, pclk->con_id, pclk->dev_id,
+                                   clk);
+       }
+       return 0;
+}
+
+static void __init pxa_dt_clocks_init(struct device_node *np)
+{
+       of_clk_add_provider(np, of_clk_src_onecell_get, &onecell_data);
+}
+CLK_OF_DECLARE(pxa_clks, "marvell,pxa-clocks", pxa_dt_clocks_init);
drivers/clk/pxa/clk-pxa.h new file +107 -0
new file mode 100644
index 0000000..5fe219d
@@ -0,0 +1,107 @@
+/*
+ * Marvell PXA family clocks
+ *
+ * Copyright (C) 2014 Robert Jarzmik
+ *
+ * Common clock code for PXA clocks ("CKEN" type clocks + DT)
+ *
+ * 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 of the License.
+ *
+ */
+#ifndef _CLK_PXA_
+#define _CLK_PXA_
+
+#define PARENTS(name) \
+       static const char *name ## _parents[] __initconst
+#define MUX_RO_RATE_RO_OPS(name, clk_name)                     \
+       static struct clk_hw name ## _mux_hw;                   \
+       static struct clk_hw name ## _rate_hw;                  \
+       static struct clk_ops name ## _mux_ops = {              \
+               .get_parent = name ## _get_parent,              \
+               .set_parent = dummy_clk_set_parent,             \
+       };                                                      \
+       static struct clk_ops name ## _rate_ops = {             \
+               .recalc_rate = name ## _get_rate,               \
+       };                                                      \
+       static struct clk *clk_register_ ## name(void)          \
+       {                                                       \
+               return clk_register_composite(NULL, clk_name,   \
+                       name ## _parents,                       \
+                       ARRAY_SIZE(name ## _parents),           \
+                       &name ## _mux_hw, &name ## _mux_ops,    \
+                       &name ## _rate_hw, &name ## _rate_ops,  \
+                       NULL, NULL, CLK_GET_RATE_NOCACHE);      \
+       }
+
+#define RATE_RO_OPS(name, clk_name)                    \
+       static struct clk_hw name ## _rate_hw;                  \
+       static struct clk_ops name ## _rate_ops = {             \
+               .recalc_rate = name ## _get_rate,               \
+       };                                                      \
+       static struct clk *clk_register_ ## name(void)          \
+       {                                                       \
+               return clk_register_composite(NULL, clk_name,   \
+                       name ## _parents,                       \
+                       ARRAY_SIZE(name ## _parents),           \
+                       NULL, NULL,                             \
+                       &name ## _rate_hw, &name ## _rate_ops,  \
+                       NULL, NULL, CLK_GET_RATE_NOCACHE);      \
+       }
+
+/*
+ * CKEN clock type
+ * This clock takes it source from 2 possible parents :
+ *  - a low power parent
+ *  - a normal parent
+ *
+ *  +------------+     +-----------+
+ *  |  Low Power | --- | x mult_lp |
+ *  |    Clock   |     | / div_lp  |\
+ *  +------------+     +-----------+ \+-----+   +-----------+
+ *                                    | Mux |---| CKEN gate |
+ *  +------------+     +-----------+ /+-----+   +-----------+
+ *  | High Power |     | x mult_hp |/
+ *  |    Clock   | --- | / div_hp  |
+ *  +------------+     +-----------+
+ */
+struct pxa_clk_cken {
+       struct clk_hw hw;
+       int ckid;
+       const char *name;
+       const char *dev_id;
+       const char *con_id;
+       const char **parent_names;
+       struct clk_fixed_factor lp;
+       struct clk_fixed_factor hp;
+       struct clk_gate gate;
+       bool (*is_in_low_power)(void);
+       const unsigned long flags;
+};
+
+#define PXA_CKEN(_dev_id, _con_id, _name, parents, _mult_lp, _div_lp,  \
+                _mult_hp, _div_hp, is_lp, _cken_reg, _cken_bit, flag)  \
+       { .ckid = CLK_ ## _name, .name = #_name,                        \
+         .dev_id = _dev_id, .con_id = _con_id, .parent_names = parents,\
+         .lp = { .mult = _mult_lp, .div = _div_lp },                   \
+         .hp = { .mult = _mult_hp, .div = _div_hp },                   \
+         .is_in_low_power = is_lp,                                     \
+         .gate = { .reg = (void __iomem *)_cken_reg, .bit_idx = _cken_bit }, \
+         .flags = flag,                                                \
+       }
+#define PXA_CKEN_1RATE(dev_id, con_id, name, parents, cken_reg,                \
+                           cken_bit, flag)                             \
+       PXA_CKEN(dev_id, con_id, name, parents, 1, 1, 1, 1,             \
+                NULL, cken_reg, cken_bit, flag)
+
+static int dummy_clk_set_parent(struct clk_hw *hw, u8 index)
+{
+       return 0;
+}
+
+extern void clkdev_pxa_register(int ckid, const char *con_id,
+                               const char *dev_id, struct clk *clk);
+extern int clk_pxa_cken_init(struct pxa_clk_cken *clks, int nb_clks);
+
+#endif
include/dt-bindings/clock/pxa-clock.h new file +77 -1
new file mode 100644
index 0000000..e65803b
@@ -0,0 +1,77 @@
+/*
+ * Inspired by original work from pxa2xx-regs.h by Nicolas Pitre
+ * Copyright (C) 2014 Robert Jarzmik
+ *
+ * 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.
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_PXA2XX_H__
+#define __DT_BINDINGS_CLOCK_PXA2XX_H__
+
+#define CLK_NONE 0
+#define CLK_1WIRE 1
+#define CLK_AC97 2
+#define CLK_AC97CONF 3
+#define CLK_ASSP 4
+#define CLK_BOOT 5
+#define CLK_BTUART 6
+#define CLK_CAMERA 7
+#define CLK_CIR 8
+#define CLK_CORE 9
+#define CLK_DMC 10
+#define CLK_FFUART 11
+#define CLK_FICP 12
+#define CLK_GPIO 13
+#define CLK_HSIO2 14
+#define CLK_HWUART 15
+#define CLK_I2C 16
+#define CLK_I2S 17
+#define CLK_IM 18
+#define CLK_INC 19
+#define CLK_ISC 20
+#define CLK_KEYPAD 21
+#define CLK_LCD 22
+#define CLK_MEMC 23
+#define CLK_MEMSTK 24
+#define CLK_MINI_IM 25
+#define CLK_MINI_LCD 26
+#define CLK_MMC 27
+#define CLK_MMC1 28
+#define CLK_MMC2 29
+#define CLK_MMC3 30
+#define CLK_MSL 31
+#define CLK_MSL0 32
+#define CLK_MVED 33
+#define CLK_NAND 34
+#define CLK_NSSP 35
+#define CLK_OSTIMER 36
+#define CLK_PWM0 37
+#define CLK_PWM1 38
+#define CLK_PWM2 39
+#define CLK_PWM3 40
+#define CLK_PWRI2C 41
+#define CLK_PXA300_GCU 42
+#define CLK_PXA320_GCU 43
+#define CLK_SMC 44
+#define CLK_SSP 45
+#define CLK_SSP1 46
+#define CLK_SSP2 47
+#define CLK_SSP3 48
+#define CLK_SSP4 49
+#define CLK_STUART 50
+#define CLK_TOUCH 51
+#define CLK_TPM 52
+#define CLK_UDC 53
+#define CLK_USB 54
+#define CLK_USB2 55
+#define CLK_USBH 56
+#define CLK_USBHOST 57
+#define CLK_USIM 58
+#define CLK_USIM1 59
+#define CLK_USMI0 60
+#define CLK_MAX 61
+
+#endif
--

2.0.0.rc2

author maintainer
#3 lore raw

PATCH v3 1/6 clk: add pxa clocks infrastructure

Quoted 7 lines · Haojian Zhuang

drivers/clk/pxa/clk-pxa.c line 66

Quoted 4 lines · Robert Jarzmik
drivers/clk/pxa/clk-pxa.c new file +4 -0
+void __init clkdev_pxa_register(int ckid, const char *con_id,
+                               const char *dev_id, struct clk *clk)
+{
+       if (!IS_ERR(clk) && (ckid != CLK_NONE))

Will you specify CLK_NONE in clock driver?

I haven't found a use yet (ie. pxa27x has no use for it, while for pxa3xx and pxa25x I don't know yet).
I had put that here for a "CKEN" type clock which would be declared, but hidden from device-tree. That's the meaning of "CLK_NONE", hidden from DT.

I can remove it if you think that there is no pxaXXX which needs this functionality.

Quoted 2 lines

It seems that CLK_NONE isn't used in pxa27x clock driver. And pxa_clocks[0] is not used. Is it redundant?

Yes it is. pxa_clocks[0] is never filled by any clock.

Cheers.

--
Robert

author maintainer
#4 lore raw

PATCH v3 2/6 clk: dts: document pxa clock binding

In reply to Robert Jarzmik

Document the device-tree binding of Marvell PXA based SoCs. PXA clocks are mostly fixed rate and fixed ratio clocks derived from an external oscillator, and gated by a register set (CKEN or CKEN*).

Signed-off-by Robert Jarzmik <[email protected]>
---
 Documentation/devicetree/bindings/clock/pxa-clock.txt | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/pxa-clock.txt
Documentation/devicetree/bindings/clock/pxa-clock.txt new file +16 -0
new file mode 100644
index 0000000..4b4a902
@@ -0,0 +1,16 @@
+* Clock bindings for Marvell PXA chips
+
+Required properties:
+- compatible: Should be "marvell,pxa-clocks"
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell (see include/.../pxa-clock.h).
+
+Examples:
+
+pxa2xx_clks: pxa2xx_clks at 41300004 {
+        compatible = "marvell,pxa-clocks";
+        #clock-cells = <1>;
+        status = "okay";
+};
Signature · 1 line
2.0.0.rc2
author maintainer
#5 lore raw

PATCH v3 3/6 arm: pxa: add clock pll selection bits

In reply to Robert Jarzmik

Add missing bits for CCCR and CCSR :
- CPLL and PPLL selection, either full speed or 13MHz
- CPSR masks

Signed-off-by Robert Jarzmik <[email protected]>
---
 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h | 10 ++++++++++
 1 file changed, 10 insertions(+)
arch/arm/mach-pxa/include/mach/pxa2xx-regs.h +10 -0
index ee6ced1..f1dd629 100644
@@ -143,6 +143,16 @@
 #define CCCR_M_MASK	0x0060	/* Memory Frequency to Run Mode Frequency Multiplier */
 #define CCCR_L_MASK	0x001f	/* Crystal Frequency to Memory Frequency Multiplier */
 
+#define CCCR_CPDIS_BIT	(31)
+#define CCCR_PPDIS_BIT	(30)
+#define CCCR_LCD_26_BIT	(27)
+#define CCCR_A_BIT	(25)
+
+#define CCSR_N2_MASK	CCCR_N_MASK
+#define CCSR_M_MASK	CCCR_M_MASK
+#define CCSR_L_MASK	CCCR_L_MASK
+#define CCSR_N2_SHIFT	7
+
 #define CKEN_AC97CONF   (31)    /* AC97 Controller Configuration */
 #define CKEN_CAMERA	(24)	/* Camera Interface Clock Enable */
 #define CKEN_SSP1	(23)	/* SSP1 Unit Clock Enable */
Signature · 1 line
2.0.0.rc2
author maintainer
#6 lore raw

PATCH v3 4/6 clk: add pxa27x clock drivers

In reply to Robert Jarzmik

Move pxa27x clock drivers from arch/arm/mach-pxa to driver/clk. In the move :
- convert to new clock framework legacy clocks
- provide clocks as before for platform data based boards
- provide clocks through devicetree

Signed-off-by Robert Jarzmik <[email protected]>
---
 drivers/clk/pxa/Makefile     |   1 +
 drivers/clk/pxa/clk-pxa27x.c | 370 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 371 insertions(+)
 create mode 100644 drivers/clk/pxa/clk-pxa27x.c
drivers/clk/pxa/Makefile +1 -0
index cb2bd8f..4ff2abc 100644
@@ -1 +1,2 @@
 obj-y				+= clk-pxa.o
+obj-$(CONFIG_PXA27x)		+= clk-pxa27x.o
drivers/clk/pxa/clk-pxa27x.c new file +370 -0

370 lines not on this page · raw message

Signature · 1 line
2.0.0.rc2
author maintainer
#7 lore raw

PATCH v3 5/6 dts: add devicetree bindings for pxa27x clocks

In reply to Robert Jarzmik

Add the clock tree description for the PXA27x based boards.

Signed-off-by Robert Jarzmik <[email protected]>
---
 arch/arm/boot/dts/pxa27x.dtsi | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)
arch/arm/boot/dts/pxa27x.dtsi +19 -1
index a705469..80fc5d7 100644
@@ -1,5 +1,6 @@
 /* The pxa3xx skeleton simply augments the 2xx version */
-/include/ "pxa2xx.dtsi"
+#include "pxa2xx.dtsi"
+#include "dt-bindings/clock/pxa2xx-clock.h"
 
 / {
 	model = "Marvell PXA27x familiy SoC";

@@ -35,4 +36,21 @@
 			#pwm-cells = <1>;
 		};
 	};
+
+	clocks {
+	       /*
+		* The muxing of external clocks/internal dividers for osc* clock
+		* sources has been hidden under the carpet by now.
+		*/
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+
+		pxa2xx_clks: pxa2xx_clks at 41300004 {
+			compatible = "marvell,pxa-clocks";
+			#clock-cells = <1>;
+			status = "okay";
+		};
+	};
+
 };
Signature · 1 line
2.0.0.rc2
author maintainer
#8 lore raw

PATCH v3 6/6 arm: pxa: Transition pxa27x to clk framework

In reply to Robert Jarzmik

Transition the PXA27x CPUs to the clock framework.
This transition still enables legacy platforms to run without device tree as before, ie relying on platform data encoded in board specific files.

Signed-off-by Robert Jarzmik <[email protected]>
---
 arch/arm/Kconfig           |   1 +
 arch/arm/mach-pxa/Makefile |   8 +-
 arch/arm/mach-pxa/pxa27x.c | 186 +++------------------------------------------
 3 files changed, 17 insertions(+), 178 deletions(-)
arch/arm/Kconfig +1 -0
index 87b63fd..96bdc7b 100644
@@ -642,6 +642,7 @@ config ARCH_PXA
 	select ARCH_REQUIRE_GPIOLIB
 	select ARM_CPU_SUSPEND if PM
 	select AUTO_ZRELADDR
+	select COMMON_CLK if PXA27x
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
 	select GENERIC_CLOCKEVENTS
arch/arm/mach-pxa/Makefile +4 -4
index 648867a..ce15823 100644
@@ -3,16 +3,16 @@
 #
 
 # Common support (must be linked before board specific support)
-obj-y				+= clock.o devices.o generic.o irq.o \
+obj-y				+= devices.o generic.o irq.o \
 				   time.o reset.o
 obj-$(CONFIG_PM)		+= pm.o sleep.o standby.o
 
 # Generic drivers that other drivers may depend upon
 
 # SoC-specific code
-obj-$(CONFIG_PXA25x)		+= mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa25x.o
-obj-$(CONFIG_PXA27x)		+= mfp-pxa2xx.o clock-pxa2xx.o pxa2xx.o pxa27x.o
-obj-$(CONFIG_PXA3xx)		+= mfp-pxa3xx.o clock-pxa3xx.o pxa3xx.o smemc.o pxa3xx-ulpi.o
+obj-$(CONFIG_PXA25x)		+= mfp-pxa2xx.o clock.o clock-pxa2xx.o pxa2xx.o pxa25x.o
+obj-$(CONFIG_PXA27x)		+= mfp-pxa2xx.o pxa2xx.o pxa27x.o
+obj-$(CONFIG_PXA3xx)		+= mfp-pxa3xx.o clock.o clock-pxa3xx.o pxa3xx.o smemc.o pxa3xx-ulpi.o
 obj-$(CONFIG_CPU_PXA300)	+= pxa300.o
 obj-$(CONFIG_CPU_PXA320)	+= pxa320.o
 obj-$(CONFIG_CPU_PXA930)	+= pxa930.o
arch/arm/mach-pxa/pxa27x.c +12 -174

211 lines not on this page · raw message

Signature · 1 line
2.0.0.rc2
maintainer
#9 lore raw

v3 cover Migrate PXA27x platforms to clock framework

In reply to Robert Jarzmik
Quoted 53 lines · Robert Jarzmik

This is the third opus of this serie.
From the previous one :
- the boot ordering was fixed
For DT, we rely on time_init() in arch/arm
For non-DT, we keep the postcore_init() until all 3 PXA variants are converted, and meanwhile I'll discuss with Haojian where to call directly the clocks init function.
- the section mismatches were fixed
A split is done between CKEN clock descriptor and CKEN clock structure

The result was tested with a Mitac MIO A701 :
- with the upstream platform-data based machine code
- with the device-tree version

As for the patches, if they are carried fully by Mike, I think there will be a minor conflict in arch/arm/mach-pxa/Makefile with the clocksource patches I submitted earlier.

As before, the goal remains the same :
- keeping legacy platforms working (ie. without device-tree)
- enable PXA27x to work with a device-tree kernel, and hence open the way to drivers conversion
- be robust enough to support pxa25x and pxa3xx later inclusion with almost no change to clk-pxa-dt.c.

Robert Jarzmik (6):
clk: add pxa clocks infrastructure
clk: dts: document pxa clock binding
arm: pxa: add clock pll selection bits
clk: add pxa27x clock drivers
dts: add devicetree bindings for pxa27x clocks
arm: pxa: Transition pxa27x to clk framework

 .../devicetree/bindings/clock/pxa-clock.txt        |  16 +
 arch/arm/Kconfig                                   |   1 +
 arch/arm/boot/dts/pxa27x.dtsi                      |  20 +-
 arch/arm/mach-pxa/Makefile                         |   8 +-
 arch/arm/mach-pxa/include/mach/pxa2xx-regs.h       |  10 +
 arch/arm/mach-pxa/pxa27x.c                         | 186 +----------
 drivers/clk/Makefile                               |   1 +
 drivers/clk/pxa/Makefile                           |   2 +
 drivers/clk/pxa/clk-pxa.c                          |  97 ++++++
 drivers/clk/pxa/clk-pxa.h                          | 107 ++++++
 drivers/clk/pxa/clk-pxa27x.c                       | 370 +++++++++++++++++++++
 include/dt-bindings/clock/pxa-clock.h              |  77 +++++
 12 files changed, 716 insertions(+), 179 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/clock/pxa-clock.txt
 create mode 100644 drivers/clk/pxa/Makefile
 create mode 100644 drivers/clk/pxa/clk-pxa.c
 create mode 100644 drivers/clk/pxa/clk-pxa.h
 create mode 100644 drivers/clk/pxa/clk-pxa27x.c
 create mode 100644 include/dt-bindings/clock/pxa-clock.h
Quoted 3 lines

--
2.0.0.rc2

Acked-by Haojian Zhuang <[email protected]>

Only with a small comment.

Regards
Haojian

author maintainer
#10 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 6 lines · Haojian Zhuang
Acked-by Haojian Zhuang <[email protected]>

Only with a small comment.

Regards
Haojian

Hi Mike and Arnd,

I suppose this patchset didn't make it to 3.17 timeframe, right ? And I don't see it scheduled either for linux-next.

Is there something blocking it ?

Cheers.

Signature · 1 line
Robert
#11 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 5 lines · On Saturday 23 August 2014 18:05:41 Robert Jarzmik wrote:
Quoted 4 lines · Haojian Zhuang
Acked-by Haojian Zhuang <[email protected]>

Only with a small comment.

Quoted 8 lines
Quoted 2 lines

Regards
Haojian

Hi Mike and Arnd,

I suppose this patchset didn't make it to 3.17 timeframe, right ? And I don't see it scheduled either for linux-next.

Is there something blocking it ?

I didn't know we were supposed to merge it. There was no reason against merging it when you posted it, but you didn't make it clear what you want to happen.

By default, I'd expect Haojian to pick up the patches and send us a pull request. He sent an Ack, but also didn't make it clear that we should pick them up.

If you want code to be merged directly through arm-soc, please send the pull request "To:" arm at kernel.org (with all interested parties the mailing lists in Cc) and ask us directly to pull it, to avoid all ambiguity.

Sometimes we can miss patches (as opposed to pull requests) since at least I tend to scan my inbox for the 'GIT PULL' keyword. If we don't seem to react within a week, just send a friendly reminder.

For the specific case of PXA, I wonder if we should update the maintainer entry. As far as I can tell, Eric and Russell are no longer actively involved in the maintenance of PXA, and Haojian is doing only the bare minimum and is kept busy by other platforms these days (mach-hisi, mach-mmp). Should we perhaps add you and/or Daniel and remove some of the others if they are no longer as actively working on PXA?

Arnd

author maintainer
#12 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 3 lines · Arnd Bergmann

I didn't know we were supposed to merge it. There was no reason against merging it when you posted it, but you didn't make it clear what you want to happen.

Right.

Quoted 3 lines

By default, I'd expect Haojian to pick up the patches and send us a pull request. He sent an Ack, but also didn't make it clear that we should pick them up.

I was thinking that they would go through the clk maintainers, hence Haojian's ack. If they should go through arm-soc, they would need Mike's ack.

Quoted 4 lines

If you want code to be merged directly through arm-soc, please send the pull request "To:" arm at kernel.org (with all interested parties the mailing lists in Cc) and ask us directly to pull it, to avoid all ambiguity.

OK, I can do it with Mike's ack first.

Quoted 3 lines

Sometimes we can miss patches (as opposed to pull requests) since at least I tend to scan my inbox for the 'GIT PULL' keyword. If we don't seem to react within a week, just send a friendly reminder.

No problem, it's not as if this was a business critical platform :)

Quoted 7 lines

For the specific case of PXA, I wonder if we should update the maintainer entry. As far as I can tell, Eric and Russell are no longer actively involved in the maintenance of PXA, and Haojian is doing only the bare minimum and is kept busy by other platforms these days (mach-hisi, mach-mmp). Should we perhaps add you and/or Daniel and remove some of the others if they are no longer as actively working on PXA?

Sure, I'll send a patch to add myself to the MAINTAINERS of pxa. Would be great if Daniel stepped in too, as my pxa3xx knowledge is poor.

As to removing Russell and Eric, we should get their opinion, it's as they want, I can send it in the maintainers patch if they agree.

Cheers.

Signature · 1 line
Robert
maintainer
#13 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 10 lines · Robert Jarzmik
Quoted 7 lines · Arnd Bergmann

For the specific case of PXA, I wonder if we should update the maintainer entry. As far as I can tell, Eric and Russell are no longer actively involved in the maintenance of PXA, and Haojian is doing only the bare minimum and is kept busy by other platforms these days (mach-hisi, mach-mmp). Should we perhaps add you and/or Daniel and remove some of the others if they are no longer as actively working on PXA?

Quoted 2 lines

Sure, I'll send a patch to add myself to the MAINTAINERS of pxa. Would be great if Daniel stepped in too, as my pxa3xx knowledge is poor.

Sure, why not. However, I only have one platform to test PXA3xx stuff on, and that's a custom-made one that is not very versatile. Hence, I always thought that a maintainer who's employed by the chip vendor is a very good thing to have, because I'd imagined the vendor usually has access to a wider range of different hardware.

Also, I'm no longer actively working with this platform for my day job, so my efforts will be limited to my spare time. But after all, PXA has been quite calm over the years now. The only bigger topics that will consume some time in the future seem to be DT and DMA.

Quoted 2 lines

As to removing Russell and Eric, we should get their opinion, it's as they want, I can send it in the maintainers patch if they agree.

Yes, I'd definitely like to hear their opinion, too.

Daniel

#14 lore raw

v3 cover Migrate PXA27x platforms to clock framework

In reply to Robert Jarzmik
Quoted 5 lines · Robert Jarzmik
Quoted 3 lines

By default, I'd expect Haojian to pick up the patches and send us a pull request. He sent an Ack, but also didn't make it clear that we should pick them up.

I was thinking that they would go through the clk maintainers, hence Haojian's ack. If they should go through arm-soc, they would need Mike's ack.

Right, makes sense. We have in the past done it either way for other platforms. When merging the patches through the clk subsystem, it still makes sense to let us know of those plans and ask for an Ack from the arm-soc maintainers, to be sure we can plan ahead in case there are other (conflicting) patch sets that are sent through arm-soc.

Arnd

#15 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoting Arnd Bergmann (2014-08-24 05:08:19)

Quoted 6 lines · Robert Jarzmik
Quoted 5 lines
Quoted 3 lines

By default, I'd expect Haojian to pick up the patches and send us a pull request. He sent an Ack, but also didn't make it clear that we should pick them up.

I was thinking that they would go through the clk maintainers, hence Haojian's ack. If they should go through arm-soc, they would need Mike's ack.

Robert,

I'm happy to take the patches but they will need to be rebased onto clk-next and refactored to take into account Tomeu's api split[0].

Quoted 6 lines

Right, makes sense. We have in the past done it either way for other platforms. When merging the patches through the clk subsystem, it still makes sense to let us know of those plans and ask for an Ack from the arm-soc maintainers, to be sure we can plan ahead in case there are other (conflicting) patch sets that are sent through arm-soc.

Arnd,

Do I have your Ack for the arch/arm patches?

[0] https://lkml.kernel.org/r/<[email protected]>

Thanks,
Mike

Quoted 2 lines

Arnd

#16 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 9 lines · On Wednesday 03 September 2014 11:49:56 Mike Turquette wrote:
Quoted 5 lines

Right, makes sense. We have in the past done it either way for other platforms. When merging the patches through the clk subsystem, it still makes sense to let us know of those plans and ask for an Ack from the arm-soc maintainers, to be sure we can plan ahead in case there are other (conflicting) patch sets that are sent through arm-soc.

Do I have your Ack for the arch/arm patches?

[0] https://lkml.kernel.org/r/<[email protected]>

I have no objection to the change, but we might need to be careful in case we get a lot of conflicts.

How about making it a shared branch that you plan to send upstream but that we can also include in arm-soc to avoid conflicts if necessary?

Arnd

#17 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoting Arnd Bergmann (2014-09-03 12:33:31)

Quoted 9 lines · On Wednesday 03 September 2014 11:49:56 Mike Turquette wrote:
Quoted 8 lines
Quoted 5 lines

Right, makes sense. We have in the past done it either way for other platforms. When merging the patches through the clk subsystem, it still makes sense to let us know of those plans and ask for an Ack from the arm-soc maintainers, to be sure we can plan ahead in case there are other (conflicting) patch sets that are sent through arm-soc.

Do I have your Ack for the arch/arm patches?

Quoted 7 lines
Quoted 1 line

[0] https://lkml.kernel.org/r/<[email protected]>

I have no objection to the change, but we might need to be careful in case we get a lot of conflicts.

How about making it a shared branch that you plan to send upstream but that we can also include in arm-soc to avoid conflicts if necessary?

Sounds good. I'll probably need to perform a bit of surgery on my tree and rebase it in order to have the minimum set of patches that get pulled into arm-soc.

Regards,
Mike

Quoted 2 lines

Arnd

#18 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 15 lines · Mike Turquette

Quoting Arnd Bergmann (2014-09-03 12:33:31)

Quoted 14 lines · On Wednesday 03 September 2014 11:49:56 Mike Turquette wrote:
Quoted 9 lines
Quoted 5 lines

Right, makes sense. We have in the past done it either way for other platforms. When merging the patches through the clk subsystem, it still makes sense to let us know of those plans and ask for an Ack from the arm-soc maintainers, to be sure we can plan ahead in case there are other (conflicting) patch sets that are sent through arm-soc.

Do I have your Ack for the arch/arm patches?

[0] https://lkml.kernel.org/r/<[email protected]>

I have no objection to the change, but we might need to be careful in case we get a lot of conflicts.

Quoted 6 lines
Quoted 2 lines

How about making it a shared branch that you plan to send upstream but that we can also include in arm-soc to avoid conflicts if necessary?

Sounds good. I'll probably need to perform a bit of surgery on my tree and rebase it in order to have the minimum set of patches that get pulled into arm-soc.

Ok, I see. We might not pull it in right away, because it's possible that there are no actual conflicts and we don't need them, but it's definitely good if your branch is ready in case we do.

Arnd

author maintainer
#19 lore raw
In reply to Mike Turquette
Quoted 3 lines

I'm happy to take the patches but they will need to be rebased onto clk-next and refactored to take into account Tomeu's api split[0].

Hi Mike,

Ok, then when I'm back into the proximity of a computer, ie. in 2 weeks, I'll rebase the patchset. A 5" phone smart as it can be is a bit too hard
to work with.

Cheers.

--
Robert

author maintainer
#20 lore raw

v3 cover Migrate PXA27x platforms to clock framework

In reply to Mike Turquette
Quoted 5 lines · Mike Turquette

Quoting Arnd Bergmann (2014-08-24 05:08:19)

Quoted 4 lines · Robert Jarzmik
Quoted 3 lines
Quoted 3 lines

By default, I'd expect Haojian to pick up the patches and send us a pull request. He sent an Ack, but also didn't make it clear that we should pick them up.

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

I was thinking that they would go through the clk maintainers, hence Haojian's ack. If they should go through arm-soc, they would need Mike's ack.

Robert,

I'm happy to take the patches but they will need to be rebased onto clk-next and refactored to take into account Tomeu's api split[0].

Hi Mike,

I have had a look at clk-next and Tomeu's split.
My current understanding is that Tomeu's patches don't apply on your clk-next, as I get conflicts.

So either I rebase my patches on top of Tomeu's tree (as this is what will drive most of the rebase work AFAIU), or I wait for Tomeu's tree to be merged into your clk-next. Is there any chance Tomeu's work ends up in your clk-next tree soon ?

Cheers.

Signature · 1 line
Robert
#21 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoting Robert Jarzmik (2014-09-20 09:13:45)

Quoted 17 lines
Quoted 5 lines · Mike Turquette

Quoting Arnd Bergmann (2014-08-24 05:08:19)

Quoted 4 lines · Robert Jarzmik
Quoted 3 lines
Quoted 3 lines

By default, I'd expect Haojian to pick up the patches and send us a pull request. He sent an Ack, but also didn't make it clear that we should pick them up.

Quoted 7 lines
Quoted 2 lines
Quoted 2 lines

I was thinking that they would go through the clk maintainers, hence Haojian's ack. If they should go through arm-soc, they would need Mike's ack.

Robert,

I'm happy to take the patches but they will need to be rebased onto clk-next and refactored to take into account Tomeu's api split[0].

Hi Mike,

Quoted 8 lines

I have had a look at clk-next and Tomeu's split.
My current understanding is that Tomeu's patches don't apply on your clk-next, as I get conflicts.

So either I rebase my patches on top of Tomeu's tree (as this is what will drive most of the rebase work AFAIU), or I wait for Tomeu's tree to be merged into your clk-next. Is there any chance Tomeu's work ends up in your clk-next tree soon ?

Hi Robert,

Tomeu's stuff won't go into 3.18. I should have circled back to these patches when that become apparent, but it got lost in the paperwork.

I can take these patches without you rebasing onto his work. Since we have -rc7 I think there is time and these patches shouldn't wait for another merge window. I've applied them to clk-next from a stable branch with these six patches based on -rc1.

Hi Arnd,

I do not believe you'll need the stable branch (I tested merging it with linux-next and there were no issues), but I've put one up anyways:

https://git.linaro.org/people/mike.turquette/linux.git clk-pxa27x

Regards,
Mike

Quoted 5 lines

Cheers.

Signature · 1 line
Robert
author maintainer
#22 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 10 lines · Mike Turquette

Quoting Robert Jarzmik (2014-09-20 09:13:45)
Hi Robert,

Tomeu's stuff won't go into 3.18. I should have circled back to these patches when that become apparent, but it got lost in the paperwork.

I can take these patches without you rebasing onto his work. Since we have -rc7 I think there is time and these patches shouldn't wait for another merge window. I've applied them to clk-next from a stable branch with these six patches based on -rc1.

Thanks Mike, that's perfect. These patches are my corner stone to unblock the pxa device-tree port (at least on pxa27x).

There will be at least 1 corrective patch for init ordering (clocks must be initialized before the clocksource). But I believe it will go during the 3.18-rcs. I'll post the patch tomorrow for it to gather enough acks.

And I have also a patch for Tomeu's change. It's really small, so I'll post it too, but not for submission, just to have it reviewed when the API change will be ready.

Thanks.

Signature · 1 line
Robert
#23 lore raw

v3 cover Migrate PXA27x platforms to clock framework

Quoted 16 lines · Robert Jarzmik
Quoted 10 lines · Mike Turquette

Quoting Robert Jarzmik (2014-09-20 09:13:45)
Hi Robert,

Tomeu's stuff won't go into 3.18. I should have circled back to these patches when that become apparent, but it got lost in the paperwork.

I can take these patches without you rebasing onto his work. Since we have -rc7 I think there is time and these patches shouldn't wait for another merge window. I've applied them to clk-next from a stable branch with these six patches based on -rc1.

Thanks Mike, that's perfect. These patches are my corner stone to unblock the pxa device-tree port (at least on pxa27x).

Quoted 7 lines

There will be at least 1 corrective patch for init ordering (clocks must be initialized before the clocksource). But I believe it will go during the 3.18-rcs. I'll post the patch tomorrow for it to gather enough acks.

And I have also a patch for Tomeu's change. It's really small, so I'll post it too, but not for submission, just to have it reviewed when the API change will be ready.

OK, that sounds great. Please note that the 01.org builder found a problem with the Kconfig bits. Can you look into it?

Thanks,
Mike

Quoted 5 lines

Thanks.

--
Robert