Migrate PXA27x platforms to clock framework
Subsystems (5)
Robert Jarzmik
maintainercover Migrate PXA27x platforms to clock framework
As the RFC posted in [1] didn't meet an unrivaled success for review, I'm posting this serie for PXA27x transition to clock framework.
This transition is needed :
- to enable device-tree drivers port, as clocks are needed almost everywhere
- to enable the long term multi-platform kernel to support PXA
As I had said before, this serie aims at :
- 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.
As this serie is holding the rest of the device-tree drivers port, I'd like it to be reviewed, even it's an old unsexy platform.
Cheers.
--
Robert
[1]: http://www.spinics.net/lists/arm-kernel/msg337521.html
Robert Jarzmik (4):
clk: add pxa27x clock drivers
dts: add devicetree bindings for pxa27x clocks
arm: pxa: Transition pxa27x to clk framework
clk: dts: document pxa27x clock binding
.../devicetree/bindings/clock/pxa-clock.txt | 32 ++ arch/arm/Kconfig | 1 + arch/arm/boot/dts/pxa27x.dtsi | 134 ++++++++- arch/arm/mach-pxa/Makefile | 8 +- arch/arm/mach-pxa/pxa27x.c | 190 +----------- drivers/clk/Makefile | 1 + drivers/clk/pxa/Makefile | 4 + drivers/clk/pxa/clk-pxa-dt.c | 76 +++++ drivers/clk/pxa/clk-pxa27x.c | 324 +++++++++++++++++++++ drivers/clk/pxa/clk-pxa2xx.c | 74 +++++ drivers/clk/pxa/clk-pxa2xx.h | 47 +++ include/dt-bindings/clock/pxa2xx-clock.h | 45 +++ 12 files changed, 757 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-dt.c create mode 100644 drivers/clk/pxa/clk-pxa27x.c create mode 100644 drivers/clk/pxa/clk-pxa2xx.c create mode 100644 drivers/clk/pxa/clk-pxa2xx.h create mode 100644 include/dt-bindings/clock/pxa2xx-clock.h
Signature · 1 line
2.0.0.rc2
Robert Jarzmik
maintainerPATCH 1/4 clk: add pxa27x clock drivers
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 with clk-pxa-dt
This is the preliminary step in the conversion. The remaining steps are :
- migrate pxa25x and pxa3xx
- once PXA is fully converted to device tree, if that happens, clk-pxa2* and clk-pxa3* should only hold the core clocks which cannot be described in devicetree.
--- drivers/clk/Makefile | 1 + drivers/clk/pxa/Makefile | 4 + drivers/clk/pxa/clk-pxa-dt.c | 76 ++++++++++ drivers/clk/pxa/clk-pxa27x.c | 324 +++++++++++++++++++++++++++++++++++++++++++ drivers/clk/pxa/clk-pxa2xx.c | 74 ++++++++++ drivers/clk/pxa/clk-pxa2xx.h | 47 +++++++ 6 files changed, 526 insertions(+) create mode 100644 drivers/clk/pxa/Makefile create mode 100644 drivers/clk/pxa/clk-pxa-dt.c create mode 100644 drivers/clk/pxa/clk-pxa27x.c create mode 100644 drivers/clk/pxa/clk-pxa2xx.c create mode 100644 drivers/clk/pxa/clk-pxa2xx.h
drivers/clk/Makefile +1 -0
@@ -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 +4 -0
@@ -0,0 +1,4 @@ +obj-y += clk-pxa-dt.o +obj-$(CONFIG_PXA25x) += clk-pxa2xx.o clk-pxa25x.o +obj-$(CONFIG_PXA27x) += clk-pxa2xx.o clk-pxa27x.o +obj-$(CONFIG_PXA3xx) += clk-pxa3xx.o
drivers/clk/pxa/clk-pxa-dt.c new file +76 -0
76 lines not on this page · raw message
drivers/clk/pxa/clk-pxa27x.c new file +324 -0
324 lines not on this page · raw message
drivers/clk/pxa/clk-pxa2xx.c new file +74 -0
74 lines not on this page · raw message
drivers/clk/pxa/clk-pxa2xx.h new file +47 -0
47 lines not on this page · raw message
Signature · 1 line
2.0.0.rc2
Haojian Zhuang
maintainerPATCH 1/4 clk: add pxa27x clock drivers
Quoted 52 lines · Robert Jarzmik
Move pxa27x clock drivers from
arch/arm/mach-pxato 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 with clk-pxa-dtThis is the preliminary step in the conversion. The remaining steps are :
- migrate pxa25x and pxa3xx
- once PXA is fully converted to device tree, if that happens, clk-pxa2* and clk-pxa3* should only hold the core clocks which cannot be described in devicetree.Signed-off-by Robert Jarzmik <[email protected]>--- drivers/clk/Makefile | 1 + drivers/clk/pxa/Makefile | 4 + drivers/clk/pxa/clk-pxa-dt.c | 76 ++++++++++ drivers/clk/pxa/clk-pxa27x.c | 324 +++++++++++++++++++++++++++++++++++++++++++ drivers/clk/pxa/clk-pxa2xx.c | 74 ++++++++++ drivers/clk/pxa/clk-pxa2xx.h | 47 +++++++ 6 files changed, 526 insertions(+) create mode 100644 drivers/clk/pxa/Makefile create mode 100644 drivers/clk/pxa/clk-pxa-dt.c create mode 100644 drivers/clk/pxa/clk-pxa27x.c create mode 100644 drivers/clk/pxa/clk-pxa2xx.c create mode 100644 drivers/clk/pxa/clk-pxa2xx.hdrivers/clk/pxa/clk-pxa27x.c new file +24
-0+ +static struct pxa27x_clocks_fixed_cken pxa27x_without_dt_clocks[]__initdata = { +PXA2_FIXED_RATE ("pxa2xx-uart.0" ,NULL ,FFUART ,14857000 ,1 ), +PXA2_FIXED_RATE ("pxa2xx-uart.1" ,NULL ,BTUART ,14857000 ,1 ), +PXA2_FIXED_RATE ("pxa2xx-uart.2" ,NULL ,STUART ,14857000 ,1 ), +PXA2_FIXED_RATE (NULL ,"UARTCLK" ,STUART ,14857000 ,1 ), +PXA2_FIXED_RATE ("pxa2xx-i2s" ,NULL ,I2S ,14682000 ,0 ), +PXA2_FIXED_RATE ("pxa2xx-i2c.0" ,NULL ,I2C ,32842000 ,0 ), +PXA2_FIXED_RATE ("pxa27x-udc" ,NULL ,USB ,48000000 ,5 ), +PXA2_FIXED_RATE ("pxa2xx-mci.0" ,NULL ,MMC ,19500000 ,0 ), +PXA2_FIXED_RATE ("pxa2xx-ir" ,"FICPCLK" ,FICP ,48000000 ,0 ), +PXA2_FIXED_RATE ("pxa27x-ohci" ,NULL ,USBHOST ,48000000 ,0 ), +PXA2_FIXED_RATE ("pxa2xx-i2c.1" ,NULL ,PWRI2C ,13000000 ,0 ), +PXA2_FIXED_RATE ("pxa27x-keypad" ,NULL ,KEYPAD ,32768 ,0 ), +PXA2_FIXED_RATE ("pxa27x-ssp.0" ,NULL ,SSP1 ,13000000 ,0 ), +PXA2_FIXED_RATE ("pxa27x-ssp.1" ,NULL ,SSP2 ,13000000 ,0 ), +PXA2_FIXED_RATE ("pxa27x-ssp.2" ,NULL ,SSP3 ,13000000 ,0 ), +PXA2_FIXED_RATE ("pxa27x-pwm.0" ,NULL ,PWM0 ,13000000 ,0 ), +PXA2_FIXED_RATE ("pxa27x-pwm.1" ,NULL ,PWM1 ,13000000 ,0 ), +PXA2_FIXED_RATE (NULL ,"AC97CLK" ,AC97 ,24576000 ,0 ), +PXA2_FIXED_RATE (NULL ,"AC97CONFCLK" ,AC97CONF ,24576000 ,0 ), +PXA2_FIXED_RATE (NULL ,"MSLCLK" ,MSL ,48000000 ,0 ), +PXA2_FIXED_RATE (NULL ,"USIMCLK" ,USIM ,48000000 ,0 ), +PXA2_FIXED_RATE (NULL ,"MSTKCLK" ,MEMSTK ,19500000 ,0 ),
drivers/clk/pxa/clk-pxa27x.c line 190
Quoted 10 lines
drivers/clk/pxa/clk-pxa27x.c new file +10
-0+PXA2_FIXED_RATE (NULL ,"IMCLK" ,IM ,0 ,0 ), + PXA2_FIXED_RATE_AO("pxa27x-memc", "MEMCLK", MEMC, 0, 0), +}; + +static struct pxa27x_clocks_var_rate pxa27x_var_rate_clocks[]__initdata = { +PXA2_VAR_RATE ("pxa2xx-fb" , true,LCD , &clk_pxa27x_lcd_ops), +PXA2_VAR_RATE ("pxa27x-camera.0" , true,CAMERA , &clk_pxa27x_lcd_ops), +PXA2_VAR_RATE ("pxa2xx-pcmcia" , false,MEMC , &clk_pxa27x_mem_ops), +}; +
It's not good to define a VAR table any more.
Now we have the common clock framework. Since these three clocks are used as clock
gate. And their clock frequency is controlled by other bits in peripheral controller registers.
We can define parent & child clocks in clock tables. I think that you can get a lot of
reference in clock drivers, such as exynos, hisilicon, ...
Same comment on PXA_FIXED_RATE table.
Regards
Haojian
Robert Jarzmik
maintainerPATCH 1/4 clk: add pxa27x clock drivers
Quoted 10 lines · Haojian Zhuang
drivers/clk/pxa/clk-pxa27x.c line 190
Quoted 6 lines · Robert Jarzmik
drivers/clk/pxa/clk-pxa27x.c new file +6
-0+static struct pxa27x_clocks_var_rate pxa27x_var_rate_clocks[]__initdata = { +PXA2_VAR_RATE ("pxa2xx-fb" , true,LCD , &clk_pxa27x_lcd_ops), +PXA2_VAR_RATE ("pxa27x-camera.0" , true,CAMERA , &clk_pxa27x_lcd_ops), +PXA2_VAR_RATE ("pxa2xx-pcmcia" , false,MEMC , &clk_pxa27x_mem_ops), +}; +It's not good to define a VAR table any more.
Quoted 4 lines
Now we have the common clock framework. Since these three clocks are used as clock
gate. And their clock frequency is controlled by other bits in peripheral controller registers.
I understand the clock hierarchy part.
Quoted 5 lines
We can define parent & child clocks in clock tables. I think that you can get a lot of
reference in clock drivers, such as exynos, hisilicon, ...Same comment on
PXA_FIXED_RATEtable.
That's a bit of work which will be thrown away anyway.
The goal is :
- keep same level of clock functionnality in non-DT builds
- have the full clock framework power for DT builds
- have non-DT builds removed once everything is ported to device-tree
Therefore, I don't want to redefine the full clock hierarchy in non-DT builds. That's a lot of work for nothing. This patchset doesn't aim at a full clock rework part, it aims at enabling porting all PXA platforms to DT without breaking the non-DT part.
For DT, we already have this type of clock tree :
\u@\h:\w\$ cat /sys/kernel/debug/clk/clk_summary
clock enable_cnt prepare_cnt rate accuracy
--------------------------------------------------------------------------------
clk_dummy 1 1 0 0
im 0 0 0 0
osc32_768khz 1 1 32768 0
keypad 1 1 32768 0
osc13mhz 3 3 13000000 0
lcd 0 0 52000000 0
camera 0 0 52000000 0
memory 0 0 104000000 0
system bus 0 0 104000000 0
cpu core 0 0 104000000 0
halt-turbo mode 0 0 52000000 0
turbo mode 0 0 104000000 0
run mode 0 0 104000000 0
clk_ostimer 1 1 3250000 0
nssp,ostimer 1 1 3250000 0
clk_13mhz 2 2 13000000 0
ssp1 0 0 13000000 0
pwri2c 1 1 13000000 0
ssp3,hwuart 0 0 13000000 0
ssp2 0 0 13000000 0
pwm 1,3 0 0 13000000 0
pwm 0,2 1 1 13000000 0
pll_312mhz 3 3 312000000 0
clk_14_682mhz 0 0 12235294 0
i2s 0 0 12235294 0
clk_14_857mhz 1 3 14857142 0
btuart 1 2 14857142 0
ffuart 0 1 14857142 0
stuart 0 1 14857142 0
clk_19_5mhz 0 0 19500000 0
memstk 0 0 19500000 0
mmc 0 0 19500000 0
clk_32_842mhz 1 1 32842105 0
i2c 1 1 32842105 0
clk_48mhz 1 1 48000000 0
usim 0 0 48000000 0
msl 0 0 48000000 0
ficp 0 0 48000000 0
usb udc 1 1 48000000 0
usb host,assp 0 0 48000000 0Cheers.
Signature · 1 line
Robert
Robert Jarzmik
maintainerPATCH 2/4 dts: add devicetree bindings for pxa27x clocks
In reply to Robert JarzmikAdd the clock tree description for the PXA27x based boards.
--- arch/arm/boot/dts/pxa27x.dtsi | 134 ++++++++++++++++++++++++++++++- include/dt-bindings/clock/pxa2xx-clock.h | 45 +++++++++++ 2 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 include/dt-bindings/clock/pxa2xx-clock.h
arch/arm/boot/dts/pxa27x.dtsi +133 -1
@@ -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,135 @@ #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; + + osc13mhz:osc13mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <13000000>; + }; + + osc32_768khz:osc32_768khz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + + pll_312mhz:pll_312mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <1>; + clock-mult = <24>; + }; + + clk_48mhz:clk_48mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <13>; + clock-mult = <2>; + }; + + clk_32_842mhz:clk_32_842mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <19>; + clock-mult = <2>; + }; + + clk_19_5mhz:clk_19_5mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <32>; + clock-mult = <2>; + }; + + clk_14_857mhz:clk_14_857mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <42>; + clock-mult = <2>; + }; + + clk_14_682mhz:clk_14_682mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <51>; + clock-mult = <2>; + }; + + clk_13mhz:clk_13mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <1>; + clock-mult = <1>; + }; + + clk_dummy:clk_dummy { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + + clk_ostimer:clk_ostimer { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <4>; + clock-mult = <1>; + }; + + pxa27x_sysclks:pxa27x_sysclks { + compatible = "marvell,pxa270-core-clocks"; + #clock-cells = <1>; + clocks = <&osc13mhz>; + clock-output-names = "run mode", "half-turbo mode", + "turbo mode", "cpu core", "system bus", "memory", "lcd"; + }; + + pxa2xx_clks: pxa2xx_clks at 41300004 { + compatible = "marvell,pxa-clocks"; + reg = <0x41300004 0x4>; + clocks = + <&clk_13mhz>, <&clk_13mhz>, <&clk_dummy>, <&clk_13mhz>, + <&clk_13mhz>, <&clk_14_857mhz>, <&clk_14_857mhz>, <&clk_14_857mhz>, + <&clk_14_682mhz>, <&clk_ostimer>, <&clk_48mhz>, <&clk_48mhz>, + <&clk_19_5mhz>, <&clk_48mhz>, <&clk_32_842mhz>, <&clk_13mhz>, + <&pxa27x_sysclks 6>, <&clk_48mhz>, <&clk_48mhz>, <&osc32_768khz>, + <&clk_dummy>, <&clk_19_5mhz>, <&pxa27x_sysclks 4>, <&clk_13mhz>, + <&pxa27x_sysclks 6>, <&clk_dummy>; + #clock-cells = <1>; + clock-output-names = + "pwm 0,2", "pwm 1,3", "ac97", "ssp2", + "ssp3,hwuart", "stuart", "ffuart", "btuart", + "i2s", "nssp,ostimer", "usb host,assp", "usb udc", + "mmc", "ficp", "i2c", "pwri2c", + "lcd", "msl", "usim", "keypad", + "im", "memstk", "memc", "ssp1", + "camera", "ac97conf"; + clock-indices = < + CKEN_PWM0 CKEN_PWM1 CKEN_AC97 CKEN_SSP2 + CKEN_SSP3 CKEN_STUART CKEN_FFUART CKEN_BTUART + CKEN_I2S CKEN_OSTIMER CKEN_USBHOST CKEN_USB + CKEN_MMC CKEN_FICP CKEN_I2C CKEN_PWRI2C + CKEN_LCD CKEN_MSL CKEN_USIM CKEN_KEYPAD + CKEN_IM CKEN_MEMSTK 65 CKEN_SSP1 + CKEN_CAMERA CKEN_AC97CONF >; + }; + }; + };
include/dt-bindings/clock/pxa2xx-clock.h new file +45 -0
45 lines not on this page · raw message
Signature · 1 line
2.0.0.rc2
Haojian Zhuang
maintainerPATCH 2/4 dts: add devicetree bindings for pxa27x clocks
Quoted 147 lines · 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 | 134 ++++++++++++++++++++++++++++++- include/dt-bindings/clock/pxa2xx-clock.h | 45 +++++++++++ 2 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 include/dt-bindings/clock/pxa2xx-clock.harch/arm/boot/dts/pxa27x.dtsi +124
-1@@ -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,135 @@ #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; + + osc13mhz:osc13mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <13000000>; + }; + + osc32_768khz:osc32_768khz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + + pll_312mhz:pll_312mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <1>; + clock-mult = <24>; + }; + + clk_48mhz:clk_48mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <13>; + clock-mult = <2>; + }; + + clk_32_842mhz:clk_32_842mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <19>; + clock-mult = <2>; + }; + + clk_19_5mhz:clk_19_5mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <32>; + clock-mult = <2>; + }; + + clk_14_857mhz:clk_14_857mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <42>; + clock-mult = <2>; + }; + + clk_14_682mhz:clk_14_682mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <51>; + clock-mult = <2>; + }; + + clk_13mhz:clk_13mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <1>; + clock-mult = <1>; + }; + + clk_dummy:clk_dummy { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + + clk_ostimer:clk_ostimer { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <4>; + clock-mult = <1>; + }; + + pxa27x_sysclks:pxa27x_sysclks { + compatible = "marvell,pxa270-core-clocks"; + #clock-cells = <1>; + clocks = <&osc13mhz>; + clock-output-names = "run mode", "half-turbo mode", + "turbo mode", "cpu core", "system bus", "memory", "lcd"; + }; + + pxa2xx_clks: pxa2xx_clks at 41300004 { + compatible = "marvell,pxa-clocks"; + reg = <0x41300004 0x4>; + clocks = + <&clk_13mhz>, <&clk_13mhz>, <&clk_dummy>, <&clk_13mhz>, + <&clk_13mhz>, <&clk_14_857mhz>, <&clk_14_857mhz>, <&clk_14_857mhz>, + <&clk_14_682mhz>, <&clk_ostimer>, <&clk_48mhz>, <&clk_48mhz>, + <&clk_19_5mhz>, <&clk_48mhz>, <&clk_32_842mhz>, <&clk_13mhz>, + <&pxa27x_sysclks 6>, <&clk_48mhz>, <&clk_48mhz>, <&osc32_768khz>, + <&clk_dummy>, <&clk_19_5mhz>, <&pxa27x_sysclks 4>, <&clk_13mhz>, + <&pxa27x_sysclks 6>, <&clk_dummy>; + #clock-cells = <1>; + clock-output-names = + "pwm 0,2", "pwm 1,3", "ac97", "ssp2", + "ssp3,hwuart", "stuart", "ffuart", "btuart", + "i2s", "nssp,ostimer", "usb host,assp", "usb udc", + "mmc", "ficp", "i2c", "pwri2c", + "lcd", "msl", "usim", "keypad", + "im", "memstk", "memc", "ssp1", + "camera", "ac97conf"; + clock-indices = < + CKEN_PWM0 CKEN_PWM1 CKEN_AC97 CKEN_SSP2
arch/arm/boot/dts/pxa27x.dtsi line 170
Quoted 10 lines
arch/arm/boot/dts/pxa27x.dtsi +9
-0+ CKEN_SSP3 CKEN_STUART CKEN_FFUART CKEN_BTUART + CKEN_I2S CKEN_OSTIMER CKEN_USBHOST CKEN_USB + CKEN_MMC CKEN_FICP CKEN_I2C CKEN_PWRI2C + CKEN_LCD CKEN_MSL CKEN_USIM CKEN_KEYPAD + CKEN_IM CKEN_MEMSTK 65 CKEN_SSP1 + CKEN_CAMERA CKEN_AC97CONF >; + }; + }; + };
Maybe defining these clocks in pxa27x clock driver is better.
Regards
Haojian
PATCH 2/4 dts: add devicetree bindings for pxa27x clocks
Quoting Haojian Zhuang (2014-07-02 23:14:33)
Quoted 152 lines · Robert Jarzmik
Quoted 151 lines
Add the clock tree description for the PXA27x based boards.
Signed-off-by Robert Jarzmik <[email protected]>--- arch/arm/boot/dts/pxa27x.dtsi | 134 ++++++++++++++++++++++++++++++- include/dt-bindings/clock/pxa2xx-clock.h | 45 +++++++++++ 2 files changed, 178 insertions(+), 1 deletion(-) create mode 100644 include/dt-bindings/clock/pxa2xx-clock.harch/arm/boot/dts/pxa27x.dtsi +128
-1@@ -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,135 @@ #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; + + osc13mhz:osc13mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <13000000>; + }; + + osc32_768khz:osc32_768khz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <32768>; + }; + + pll_312mhz:pll_312mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <1>; + clock-mult = <24>; + }; + + clk_48mhz:clk_48mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <13>; + clock-mult = <2>; + }; + + clk_32_842mhz:clk_32_842mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <19>; + clock-mult = <2>; + }; + + clk_19_5mhz:clk_19_5mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <32>; + clock-mult = <2>; + }; + + clk_14_857mhz:clk_14_857mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <42>; + clock-mult = <2>; + }; + + clk_14_682mhz:clk_14_682mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&pll_312mhz>; + clock-div = <51>; + clock-mult = <2>; + }; + + clk_13mhz:clk_13mhz { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <1>; + clock-mult = <1>; + }; + + clk_dummy:clk_dummy { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + + clk_ostimer:clk_ostimer { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&osc13mhz>; + clock-div = <4>; + clock-mult = <1>; + }; + + pxa27x_sysclks:pxa27x_sysclks { + compatible = "marvell,pxa270-core-clocks"; + #clock-cells = <1>; + clocks = <&osc13mhz>; + clock-output-names = "run mode", "half-turbo mode", + "turbo mode", "cpu core", "system bus", "memory", "lcd"; + }; + + pxa2xx_clks: pxa2xx_clks at 41300004 { + compatible = "marvell,pxa-clocks"; + reg = <0x41300004 0x4>; + clocks = + <&clk_13mhz>, <&clk_13mhz>, <&clk_dummy>, <&clk_13mhz>, + <&clk_13mhz>, <&clk_14_857mhz>, <&clk_14_857mhz>, <&clk_14_857mhz>, + <&clk_14_682mhz>, <&clk_ostimer>, <&clk_48mhz>, <&clk_48mhz>, + <&clk_19_5mhz>, <&clk_48mhz>, <&clk_32_842mhz>, <&clk_13mhz>, + <&pxa27x_sysclks 6>, <&clk_48mhz>, <&clk_48mhz>, <&osc32_768khz>, + <&clk_dummy>, <&clk_19_5mhz>, <&pxa27x_sysclks 4>, <&clk_13mhz>, + <&pxa27x_sysclks 6>, <&clk_dummy>; + #clock-cells = <1>; + clock-output-names = + "pwm 0,2", "pwm 1,3", "ac97", "ssp2", + "ssp3,hwuart", "stuart", "ffuart", "btuart", + "i2s", "nssp,ostimer", "usb host,assp", "usb udc", + "mmc", "ficp", "i2c", "pwri2c", + "lcd", "msl", "usim", "keypad", + "im", "memstk", "memc", "ssp1", + "camera", "ac97conf"; + clock-indices = < + CKEN_PWM0 CKEN_PWM1 CKEN_AC97 CKEN_SSP2 + CKEN_SSP3 CKEN_STUART CKEN_FFUART CKEN_BTUART + CKEN_I2S CKEN_OSTIMER CKEN_USBHOST CKEN_USB + CKEN_MMC CKEN_FICP CKEN_I2C CKEN_PWRI2C + CKEN_LCD CKEN_MSL CKEN_USIM CKEN_KEYPAD
Quoted 8 lines
arch/arm/boot/dts/pxa27x.dtsi line 170
Quoted 6 lines
arch/arm/boot/dts/pxa27x.dtsi +5
-0+ CKEN_IM CKEN_MEMSTK 65 CKEN_SSP1 + CKEN_CAMERA CKEN_AC97CONF >; + }; + }; + };Maybe defining these clocks in pxa27x clock driver is better.
Agreed. After a long time trying to figure out the best DT binding for clocks it seems that defining the per-clock data in DTS is not the best way. The qcom msm and samsung exynos clock bindings and DTS data are good examples.
Regards,
Mike
Quoted 3 lines
Regards
Haojian
Robert Jarzmik
maintainerPATCH 2/4 dts: add devicetree bindings for pxa27x clocks
Quoted 7 lines · Mike Turquette
Quoting Haojian Zhuang (2014-07-02 23:14:33)
Quoted 1 line
Maybe defining these clocks in pxa27x clock driver is better.
Agreed. After a long time trying to figure out the best DT binding for clocks it seems that defining the per-clock data in DTS is not the best way. The qcom msm and samsung exynos clock bindings and DTS data are good examples.
Ah, I see. Would have been a great comment in the former RFC patch serie, sic ... Maybe a comment in the clock device-tree documentation would prevent others to do the same error ?
Well, it will take me some time to transform the dts data into code, especially if I want to have some genericity to handle all PXA variants.
I'll work on it in the next days/week.
Cheers.
Signature · 1 line
Robert
Robert Jarzmik
maintainerPATCH 3/4 arm: pxa: Transition pxa27x to clk framework
In reply to Robert JarzmikTransition 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.
--- arch/arm/Kconfig | 1 + arch/arm/mach-pxa/Makefile | 8 +- arch/arm/mach-pxa/pxa27x.c | 190 ++++----------------------------------------- 3 files changed, 21 insertions(+), 178 deletions(-)
arch/arm/Kconfig +1 -0
@@ -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
@@ -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 +16 -174
221 lines not on this page · raw message
Signature · 1 line
2.0.0.rc2
Robert Jarzmik
maintainerPATCH 4/4 clk: dts: document pxa27x clock binding
In reply to Robert JarzmikDocument 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*).
--- .../devicetree/bindings/clock/pxa-clock.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/pxa-clock.txt
Documentation/devicetree/bindings/clock/pxa-clock.txt new file +32 -0
@@ -0,0 +1,32 @@ +* Clock bindings for Marvell PXA chips + +Required properties: +- compatible: Should be "marvell,pxa-clocks" +- reg: Address and length of the CKEN register +- #clock-cells: Should be <1> +- clocks: the parent fixed rate clocks +- clock-indices: the bit index in the CKEN register gating the clock +- clock-outpout-names: the names of the clocks + +The clock consumer should specify the desired clock by having the clock +ID in its "clocks" phandle cell. + +Examples: + +pxa2xx_clks: pxa2xx_clks at 41300004 { + compatible = "marvell,pxa-clocks"; + clocks = <&clk_14_857mhz>, <&clk_14_857mhz> + #clock-cells = <1>; + clock-output-names = + "pxa27x-ffuart", "pxa27x-btuart"; + clock-indices = <CKEN_FFUART CKEN_BTUART> +}; + + +* Core clock bindings for Marvell PXA27x chips + +Required properties: +- compatible: Should be "marvell,pxa270-core-clocks" +- #clock-cells: Should be <1> +- clocks: the parent fixed rate clock, should be the 13MHz oscillator +- clock-outpout-names: the names of the 7 core clocks
Signature · 1 line
2.0.0.rc2
cover Migrate PXA27x platforms to clock framework
In reply to Robert JarzmikQuoted 16 lines · On Sunday 29 June 2014 20:32:20 Robert Jarzmik wrote:
As the RFC posted in [1] didn't meet an unrivaled success for review, I'm posting this serie for PXA27x transition to clock framework.
This transition is needed :
- to enable device-tree drivers port, as clocks are needed almost everywhere
- to enable the long term multi-platform kernel to support PXAAs I had said before, this serie aims at :
- 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 toclk-pxa-dt.c.
Quoted 3 lines
As this serie is holding the rest of the device-tree drivers port, I'd like it to be reviewed, even it's an old unsexy platform.
I have one basic question about this series: if pxa27x gets moved to used the common-clk framework but the others (pxa25x, pxa26x, pxa3xx, pxa93x) don't, does that imply that they become mutually exclusiv at compile-time?
If so, do you plan to first complete all of them before merging upstream, or do you intend to have one or more kernel releases that don't allow building a combined kernel for all pxa platforms? I don't object to doing the latter, but if that is the plan, you need to make that very clear in the changelog and have all the relevant maintainers agree to that.
Also (for my understanding) when you say that you plan to do pxa25x and pxa3xx next, does that include pxa26x and pxa93x? I assume it does as they are apparently minor revisions of the former, but it's not completely clear from your description.
Arnd
Robert Jarzmik
maintainercover Migrate PXA27x platforms to clock framework
Quoted 17 lines · Arnd Bergmann
Quoted 16 lines · On Sunday 29 June 2014 20:32:20 Robert Jarzmik wrote:
As the RFC posted in [1] didn't meet an unrivaled success for review, I'm posting this serie for PXA27x transition to clock framework.
This transition is needed :
- to enable device-tree drivers port, as clocks are needed almost everywhere
- to enable the long term multi-platform kernel to support PXAAs I had said before, this serie aims at :
- 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 toclk-pxa-dt.c.
Quoted 8 lines
Quoted 3 lines
As this serie is holding the rest of the device-tree drivers port, I'd like it to be reviewed, even it's an old unsexy platform.
I have one basic question about this series: if pxa27x gets moved to used the common-clk framework but the others (pxa25x, pxa26x, pxa3xx, pxa93x) don't, does that imply that they become mutually exclusiv at compile-time?
Unfortunately yes, they become exclusive.
The reason being that arch/arm/mach-pxa/clock.c defines the function "clk_enable()", which of course is also defined by the clock framework.
Quoted 3 lines
If so, do you plan to first complete all of them before merging upstream, or do you intend to have one or more kernel releases that don't allow building a combined kernel for all pxa platforms?
I intend to have first only pxa27x.
Then in a second stage pxa27x + pxa25x + pxa3xx.
Quoted 3 lines
I don't object to doing the latter, but if that is the plan, you need to make that very clear in the changelog and have all the relevant maintainers agree to that.
OK, that would be Haojian then, I think he maintains all PXA platforms.
Haojian, are you ok with that ? And BTW, does a combined kernel for PXA platforms even exists (mixing pxa3xx and pxa2xx for example) ?
Quoted 2 lines
Also (for my understanding) when you say that you plan to do pxa25x and pxa3xx next, does that include pxa26x and pxa93x?
I don't have the Technical Reference Manuals for these ones so the answer is no. And Google wasn't a great friend at providing them.
Quoted 2 lines
I assume it does as they are apparently minor revisions of the former, but it's not completely clear from your description.
My description doesn't mention them, as I have no information about them, nor any hardware to test on.
Cheers.
Signature · 1 line
Robert
cover Migrate PXA27x platforms to clock framework
Quoted 6 lines · On Monday 30 June 2014 20:38:49 Robert Jarzmik wrote:
Quoted 5 lines · Arnd Bergmann
Quoted 3 lines · On Sunday 29 June 2014 20:32:20 Robert Jarzmik wrote:
As this serie is holding the rest of the device-tree drivers port, I'd like it to be reviewed, even it's an old unsexy platform.
Quoted 8 lines
Quoted 4 lines
I have one basic question about this series: if pxa27x gets moved to used the common-clk framework but the others (pxa25x, pxa26x, pxa3xx, pxa93x) don't, does that imply that they become mutually exclusiv at compile-time?
Unfortunately yes, they become exclusive.
The reason being thatarch/arm/mach-pxa/clock.cdefines the function "clk_enable()", which of course is also defined by the clock framework.
Ok. Are you able to make it a compile-time decision whether the old or the new clock code is used?
That way, you can still build everything together (using the old code) while you are working on the other SoCs.
Quoted 6 lines
Quoted 3 lines
If so, do you plan to first complete all of them before merging upstream, or do you intend to have one or more kernel releases that don't allow building a combined kernel for all pxa platforms?
I intend to have first only pxa27x.
Then in a second stage pxa27x + pxa25x + pxa3xx.
Quoted 7 lines
Quoted 3 lines
I don't object to doing the latter, but if that is the plan, you need to make that very clear in the changelog and have all the relevant maintainers agree to that.
OK, that would be Haojian then, I think he maintains all PXA platforms.
Haojian, are you ok with that ? And BTW, does a combined kernel for PXA platforms even exists (mixing pxa3xx and pxa2xx for example) ?
You can select all machines at compile-time and get a clean build. I would also assume that it works fine.
Quoted 4 lines
Quoted 2 lines
Also (for my understanding) when you say that you plan to do pxa25x and pxa3xx next, does that include pxa26x and pxa93x?
I don't have the Technical Reference Manuals for these ones so the answer is no. And Google wasn't a great friend at providing them.
I only looked at the current source code, but pxa26x seems to be basically identical to pxa25x (no relevant code changes at all) and pxa93x uses the same code as pxa3xx, apparently the only difference is the addition of the communication processor.
Arnd
Haojian Zhuang
maintainercover Migrate PXA27x platforms to clock framework
In reply to Robert JarzmikQuoted 38 lines · Robert Jarzmik
Quoted 17 lines · Arnd Bergmann
Quoted 16 lines · On Sunday 29 June 2014 20:32:20 Robert Jarzmik wrote:
As the RFC posted in [1] didn't meet an unrivaled success for review, I'm posting this serie for PXA27x transition to clock framework.
This transition is needed :
- to enable device-tree drivers port, as clocks are needed almost everywhere
- to enable the long term multi-platform kernel to support PXAAs I had said before, this serie aims at :
- 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 toclk-pxa-dt.c.Quoted 8 lines
Quoted 3 lines
As this serie is holding the rest of the device-tree drivers port, I'd like it to be reviewed, even it's an old unsexy platform.
I have one basic question about this series: if pxa27x gets moved to used the common-clk framework but the others (pxa25x, pxa26x, pxa3xx, pxa93x) don't, does that imply that they become mutually exclusiv at compile-time?
Unfortunately yes, they become exclusive.
The reason being thatarch/arm/mach-pxa/clock.cdefines the function "clk_enable()", which of course is also defined by the clock framework.Quoted 3 lines
If so, do you plan to first complete all of them before merging upstream, or do you intend to have one or more kernel releases that don't allow building a combined kernel for all pxa platforms?
I intend to have first only pxa27x.
Then in a second stage pxa27x + pxa25x + pxa3xx.
Quoted 8 lines
Quoted 3 lines
I don't object to doing the latter, but if that is the plan, you need to make that very clear in the changelog and have all the relevant maintainers agree to that.
OK, that would be Haojian then, I think he maintains all PXA platforms.
Haojian, are you ok with that ? And BTW, does a combined kernel for PXA platforms even exists (mixing pxa3xx and pxa2xx for example) ?
It's acceptable to me that different silicons are queued in different stages. I only request that it won't break the compiler building & bootup.
But I think that the pxa clock driver may be shared among all PXA silicons except for the clock table. What's your opinion?
Quoted 5 lines
Quoted 2 lines
Also (for my understanding) when you say that you plan to do pxa25x and pxa3xx next, does that include pxa26x and pxa93x?
I don't have the Technical Reference Manuals for these ones so the answer is no. And Google wasn't a great friend at providing them.
Converting them into new clock driver may not rely on the reference manual.
Quoted 5 lines
Quoted 2 lines
I assume it does as they are apparently minor revisions of the former, but it's not completely clear from your description.
My description doesn't mention them, as I have no information about them, nor any hardware to test on.
We can request others to help testing in the mailing list.
Regards
Haojian
Robert Jarzmik
maintainercover Migrate PXA27x platforms to clock framework
Quoted 6 lines · Haojian Zhuang
Quoted 3 lines
Haojian, are you ok with that ? And BTW, does a combined kernel for PXA platforms even exists (mixing pxa3xx and pxa2xx for example) ?
It's acceptable to me that different silicons are queued in different stages. I only request that it won't break the compiler building & bootup.
OK.
Quoted 3 lines
But I think that the pxa clock driver may be shared among all PXA silicons except for the clock table. What's your opinion?
I don't think so because of the core clocks.
These ones are specific to each pxa, and so their computation is :
- pxa25x plays with CCCR and specific L, M and N2 multiplication tables
- pxa27x plays with CCCR and specific L, M and N2 multiplication tables
- pxa3xx plays with ASCR, MEMCLKCFG, and AC97 div
I don't see very well how a clock table could describe that. Do you have something specific in mind ?
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Also (for my understanding) when you say that you plan to do pxa25x and pxa3xx next, does that include pxa26x and pxa93x?
I don't have the Technical Reference Manuals for these ones so the answer is no. And Google wasn't a great friend at providing them.
Converting them into new clock driver may not rely on the reference manual.
Actually I went through the code and :
- pxa26x is only a superset of pxa25x with one more clock : pxa26x-gpio
- pxa93x is the same clock set as pxa3xx, right ?
So if I convert pxa25x, pxa27x and pxa3xx I'll cover everything, right ?
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
I assume it does as they are apparently minor revisions of the former, but it's not completely clear from your description.
My description doesn't mention them, as I have no information about them, nor any hardware to test on.
We can request others to help testing in the mailing list.
That's exactly what will enable pxa25x and pxa3xx. I have them converted in my tree, but I don't want to mix these patches in as I can't test them, and testing brings in bigger delays.
Cheers.
Signature · 1 line
Robert
Haojian Zhuang
maintainercover Migrate PXA27x platforms to clock framework
Quoted 13 lines · Robert Jarzmik
Quoted 6 lines · Haojian Zhuang
Quoted 3 lines
Haojian, are you ok with that ? And BTW, does a combined kernel for PXA platforms even exists (mixing pxa3xx and pxa2xx for example) ?
It's acceptable to me that different silicons are queued in different stages. I only request that it won't break the compiler building & bootup.
OK.
Quoted 3 lines
But I think that the pxa clock driver may be shared among all PXA silicons except for the clock table. What's your opinion?
Quoted 9 lines
I don't think so because of the core clocks.
These ones are specific to each pxa, and so their computation is :
- pxa25x plays with CCCR and specific L, M and N2 multiplication tables
- pxa27x plays with CCCR and specific L, M and N2 multiplication tables
- pxa3xx plays with ASCR, MEMCLKCFG, and AC97 divI don't see very well how a clock table could describe that. Do you have something specific in mind ?
As I remember, those registers bits are encoded. So we can define a clock mux that connected to those fixed clock dividers. Then the clock gate is the child of
the clock mux.
In DTS file, peripheral device node could specify a clock rate. In peripheral device
driver, it could also change the clock rate by clk_set_rate().
Quoted 14 lines
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Also (for my understanding) when you say that you plan to do pxa25x and pxa3xx next, does that include pxa26x and pxa93x?
I don't have the Technical Reference Manuals for these ones so the answer is no. And Google wasn't a great friend at providing them.
Converting them into new clock driver may not rely on the reference manual.
Actually I went through the code and :
- pxa26x is only a superset of pxa25x with one more clock : pxa26x-gpio
- pxa93x is the same clock set as pxa3xx, right ?
So if I convert pxa25x, pxa27x and pxa3xx I'll cover everything, right ?Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
I assume it does as they are apparently minor revisions of the former, but it's not completely clear from your description.
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
My description doesn't mention them, as I have no information about them, nor any hardware to test on.
We can request others to help testing in the mailing list.
That's exactly what will enable pxa25x and pxa3xx. I have them converted in my tree, but I don't want to mix these patches in as I can't test them, and testing brings in bigger delays.
Delay shouldn't be the block issue.
Regards
Haojian