* [PATCH RESEND v2 0/4] clk/exynos convert clock IDs to macros
From: Andrzej Hajda @ 2014-02-24 13:22 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrzej Hajda, Tomasz Figa, Kukjin Kim, Mike Turquette,
Kyungmin Park, moderated list:OPEN FIRMWARE AND...,
moderated list:ARM/S5P EXYNOS AR...
Hi,
This patch set converts dts files to use macros instead
of magic numbers or enums to describe clock bindings.
The patch set is rebased on the latest kgene/for-next branch.
The patches are generated by script.
Many clocks I have verified by hand.
I have also tested it successfully on exynos4 based board.
This is the 2nd version of the patchset.
Changes:
- corrected devicetree mailing list,
- added comments to include/dt-bindings/clock/exynos4.h for
clocks present only in particular chip,
- added tab alignement in headers,
- added comment to CLK_NR_CLKS,
- added copyright headers,
- split long lines in dts,
- corrected example in bindings/clock/exynos5250-clock.txt, to point
appropriate clocks.
Regards
Andrzej
Andrzej Hajda (4):
ARM: dts: exynos4: convert magic numbers to macros in clock bindings
ARM: dts: exynos5250: convert magic numbers to macros in clock
bindings
ARM: dts: exynos5420: convert magic numbers to macros in clock
bindings
ARM: dts: exynos5440: convert magic numbers to macros in clock
bindings
.../devicetree/bindings/clock/exynos4-clock.txt | 259 +--------------------
.../devicetree/bindings/clock/exynos5250-clock.txt | 163 +------------
.../devicetree/bindings/clock/exynos5420-clock.txt | 184 +--------------
.../devicetree/bindings/clock/exynos5440-clock.txt | 45 +---
arch/arm/boot/dts/exynos4.dtsi | 73 +++---
arch/arm/boot/dts/exynos4210.dtsi | 9 +-
arch/arm/boot/dts/exynos4x12.dtsi | 34 +--
arch/arm/boot/dts/exynos5250.dtsi | 105 +++++----
arch/arm/boot/dts/exynos5420.dtsi | 95 ++++----
arch/arm/boot/dts/exynos5440.dtsi | 33 +--
10 files changed, 207 insertions(+), 793 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH RESEND v2 1/4] ARM: dts: exynos4: convert magic numbers to macros in clock bindings
From: Andrzej Hajda @ 2014-02-24 13:22 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrzej Hajda, Tomasz Figa, Kukjin Kim, Mike Turquette,
Kyungmin Park, moderated list:OPEN FIRMWARE AND...,
moderated list:ARM/S5P EXYNOS AR...
In-Reply-To: <1393248180-17408-1-git-send-email-a.hajda@samsung.com>
The patch replaces magic numbers with macros defined in DT header
in exynos4 clock bindings.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
---
.../devicetree/bindings/clock/exynos4-clock.txt | 259 +--------------------
arch/arm/boot/dts/exynos4.dtsi | 73 +++---
arch/arm/boot/dts/exynos4210.dtsi | 9 +-
arch/arm/boot/dts/exynos4x12.dtsi | 34 +--
4 files changed, 69 insertions(+), 306 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
index a2ac2d9..f5a5b19 100644
--- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -15,259 +15,12 @@ Required Properties:
- #clock-cells: should be 1.
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume. Some of the clocks are available only on a particular
-Exynos4 SoC and this is specified where applicable.
-
-
- [Core Clocks]
-
- Clock ID SoC (if specific)
- -----------------------------------------------
-
- xxti 1
- xusbxti 2
- fin_pll 3
- fout_apll 4
- fout_mpll 5
- fout_epll 6
- fout_vpll 7
- sclk_apll 8
- sclk_mpll 9
- sclk_epll 10
- sclk_vpll 11
- arm_clk 12
- aclk200 13
- aclk100 14
- aclk160 15
- aclk133 16
- mout_mpll_user_t 17 Exynos4x12
- mout_mpll_user_c 18 Exynos4x12
- mout_core 19
- mout_apll 20
-
-
- [Clock Gate for Special Clocks]
-
- Clock ID SoC (if specific)
- -----------------------------------------------
-
- sclk_fimc0 128
- sclk_fimc1 129
- sclk_fimc2 130
- sclk_fimc3 131
- sclk_cam0 132
- sclk_cam1 133
- sclk_csis0 134
- sclk_csis1 135
- sclk_hdmi 136
- sclk_mixer 137
- sclk_dac 138
- sclk_pixel 139
- sclk_fimd0 140
- sclk_mdnie0 141 Exynos4412
- sclk_mdnie_pwm0 12 142 Exynos4412
- sclk_mipi0 143
- sclk_audio0 144
- sclk_mmc0 145
- sclk_mmc1 146
- sclk_mmc2 147
- sclk_mmc3 148
- sclk_mmc4 149
- sclk_sata 150 Exynos4210
- sclk_uart0 151
- sclk_uart1 152
- sclk_uart2 153
- sclk_uart3 154
- sclk_uart4 155
- sclk_audio1 156
- sclk_audio2 157
- sclk_spdif 158
- sclk_spi0 159
- sclk_spi1 160
- sclk_spi2 161
- sclk_slimbus 162
- sclk_fimd1 163 Exynos4210
- sclk_mipi1 164 Exynos4210
- sclk_pcm1 165
- sclk_pcm2 166
- sclk_i2s1 167
- sclk_i2s2 168
- sclk_mipihsi 169 Exynos4412
- sclk_mfc 170
- sclk_pcm0 171
- sclk_g3d 172
- sclk_pwm_isp 173 Exynos4x12
- sclk_spi0_isp 174 Exynos4x12
- sclk_spi1_isp 175 Exynos4x12
- sclk_uart_isp 176 Exynos4x12
- sclk_fimg2d 177
-
- [Peripheral Clock Gates]
-
- Clock ID SoC (if specific)
- -----------------------------------------------
-
- fimc0 256
- fimc1 257
- fimc2 258
- fimc3 259
- csis0 260
- csis1 261
- jpeg 262
- smmu_fimc0 263
- smmu_fimc1 264
- smmu_fimc2 265
- smmu_fimc3 266
- smmu_jpeg 267
- vp 268
- mixer 269
- tvenc 270 Exynos4210
- hdmi 271
- smmu_tv 272
- mfc 273
- smmu_mfcl 274
- smmu_mfcr 275
- g3d 276
- g2d 277
- rotator 278 Exynos4210
- mdma 279 Exynos4210
- smmu_g2d 280 Exynos4210
- smmu_rotator 281 Exynos4210
- smmu_mdma 282 Exynos4210
- fimd0 283
- mie0 284
- mdnie0 285 Exynos4412
- dsim0 286
- smmu_fimd0 287
- fimd1 288 Exynos4210
- mie1 289 Exynos4210
- dsim1 290 Exynos4210
- smmu_fimd1 291 Exynos4210
- pdma0 292
- pdma1 293
- pcie_phy 294
- sata_phy 295 Exynos4210
- tsi 296
- sdmmc0 297
- sdmmc1 298
- sdmmc2 299
- sdmmc3 300
- sdmmc4 301
- sata 302 Exynos4210
- sromc 303
- usb_host 304
- usb_device 305
- pcie 306
- onenand 307
- nfcon 308
- smmu_pcie 309
- gps 310
- smmu_gps 311
- uart0 312
- uart1 313
- uart2 314
- uart3 315
- uart4 316
- i2c0 317
- i2c1 318
- i2c2 319
- i2c3 320
- i2c4 321
- i2c5 322
- i2c6 323
- i2c7 324
- i2c_hdmi 325
- tsadc 326
- spi0 327
- spi1 328
- spi2 329
- i2s1 330
- i2s2 331
- pcm0 332
- i2s0 333
- pcm1 334
- pcm2 335
- pwm 336
- slimbus 337
- spdif 338
- ac97 339
- modemif 340
- chipid 341
- sysreg 342
- hdmi_cec 343
- mct 344
- wdt 345
- rtc 346
- keyif 347
- audss 348
- mipi_hsi 349 Exynos4210
- mdma2 350 Exynos4210
- pixelasyncm0 351
- pixelasyncm1 352
- fimc_lite0 353 Exynos4x12
- fimc_lite1 354 Exynos4x12
- ppmuispx 355 Exynos4x12
- ppmuispmx 356 Exynos4x12
- fimc_isp 357 Exynos4x12
- fimc_drc 358 Exynos4x12
- fimc_fd 359 Exynos4x12
- mcuisp 360 Exynos4x12
- gicisp 361 Exynos4x12
- smmu_isp 362 Exynos4x12
- smmu_drc 363 Exynos4x12
- smmu_fd 364 Exynos4x12
- smmu_lite0 365 Exynos4x12
- smmu_lite1 366 Exynos4x12
- mcuctl_isp 367 Exynos4x12
- mpwm_isp 368 Exynos4x12
- i2c0_isp 369 Exynos4x12
- i2c1_isp 370 Exynos4x12
- mtcadc_isp 371 Exynos4x12
- pwm_isp 372 Exynos4x12
- wdt_isp 373 Exynos4x12
- uart_isp 374 Exynos4x12
- asyncaxim 375 Exynos4x12
- smmu_ispcx 376 Exynos4x12
- spi0_isp 377 Exynos4x12
- spi1_isp 378 Exynos4x12
- pwm_isp_sclk 379 Exynos4x12
- spi0_isp_sclk 380 Exynos4x12
- spi1_isp_sclk 381 Exynos4x12
- uart_isp_sclk 382 Exynos4x12
- tmu_apbif 383
-
- [Mux Clocks]
-
- Clock ID SoC (if specific)
- -----------------------------------------------
-
- mout_fimc0 384
- mout_fimc1 385
- mout_fimc2 386
- mout_fimc3 387
- mout_cam0 388
- mout_cam1 389
- mout_csis0 390
- mout_csis1 391
- mout_g3d0 392
- mout_g3d1 393
- mout_g3d 394
- aclk400_mcuisp 395 Exynos4x12
-
- [Div Clocks]
-
- Clock ID SoC (if specific)
- -----------------------------------------------
-
- div_isp0 450 Exynos4x12
- div_isp1 451 Exynos4x12
- div_mcuisp0 452 Exynos4x12
- div_mcuisp1 453 Exynos4x12
- div_aclk200 454 Exynos4x12
- div_aclk400_mcuisp 455 Exynos4x12
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos4.h header and can be used in device
+tree sources.
Example 1: An example of a clock controller node is listed below.
@@ -285,6 +38,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
- clocks = <&clock 314>, <&clock 153>;
+ clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index 08452e1..28b5ec7 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -19,6 +19,7 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/clock/exynos4.h>
#include "skeleton.dtsi"
/ {
@@ -119,7 +120,7 @@
compatible = "samsung,exynos4210-fimc";
reg = <0x11800000 0x1000>;
interrupts = <0 84 0>;
- clocks = <&clock 256>, <&clock 128>;
+ clocks = <&clock CLK_FIMC0>, <&clock CLK_SCLK_FIMC0>;
clock-names = "fimc", "sclk_fimc";
samsung,power-domain = <&pd_cam>;
samsung,sysreg = <&sys_reg>;
@@ -130,7 +131,7 @@
compatible = "samsung,exynos4210-fimc";
reg = <0x11810000 0x1000>;
interrupts = <0 85 0>;
- clocks = <&clock 257>, <&clock 129>;
+ clocks = <&clock CLK_FIMC1>, <&clock CLK_SCLK_FIMC1>;
clock-names = "fimc", "sclk_fimc";
samsung,power-domain = <&pd_cam>;
samsung,sysreg = <&sys_reg>;
@@ -141,7 +142,7 @@
compatible = "samsung,exynos4210-fimc";
reg = <0x11820000 0x1000>;
interrupts = <0 86 0>;
- clocks = <&clock 258>, <&clock 130>;
+ clocks = <&clock CLK_FIMC2>, <&clock CLK_SCLK_FIMC2>;
clock-names = "fimc", "sclk_fimc";
samsung,power-domain = <&pd_cam>;
samsung,sysreg = <&sys_reg>;
@@ -152,7 +153,7 @@
compatible = "samsung,exynos4210-fimc";
reg = <0x11830000 0x1000>;
interrupts = <0 87 0>;
- clocks = <&clock 259>, <&clock 131>;
+ clocks = <&clock CLK_FIMC3>, <&clock CLK_SCLK_FIMC3>;
clock-names = "fimc", "sclk_fimc";
samsung,power-domain = <&pd_cam>;
samsung,sysreg = <&sys_reg>;
@@ -163,7 +164,7 @@
compatible = "samsung,exynos4210-csis";
reg = <0x11880000 0x4000>;
interrupts = <0 78 0>;
- clocks = <&clock 260>, <&clock 134>;
+ clocks = <&clock CLK_CSIS0>, <&clock CLK_SCLK_CSIS0>;
clock-names = "csis", "sclk_csis";
bus-width = <4>;
samsung,power-domain = <&pd_cam>;
@@ -178,7 +179,7 @@
compatible = "samsung,exynos4210-csis";
reg = <0x11890000 0x4000>;
interrupts = <0 80 0>;
- clocks = <&clock 261>, <&clock 135>;
+ clocks = <&clock CLK_CSIS1>, <&clock CLK_SCLK_CSIS1>;
clock-names = "csis", "sclk_csis";
bus-width = <2>;
samsung,power-domain = <&pd_cam>;
@@ -194,7 +195,7 @@
compatible = "samsung,s3c2410-wdt";
reg = <0x10060000 0x100>;
interrupts = <0 43 0>;
- clocks = <&clock 345>;
+ clocks = <&clock CLK_WDT>;
clock-names = "watchdog";
status = "disabled";
};
@@ -203,7 +204,7 @@
compatible = "samsung,s3c6410-rtc";
reg = <0x10070000 0x100>;
interrupts = <0 44 0>, <0 45 0>;
- clocks = <&clock 346>;
+ clocks = <&clock CLK_RTC>;
clock-names = "rtc";
status = "disabled";
};
@@ -212,7 +213,7 @@
compatible = "samsung,s5pv210-keypad";
reg = <0x100A0000 0x100>;
interrupts = <0 109 0>;
- clocks = <&clock 347>;
+ clocks = <&clock CLK_KEYIF>;
clock-names = "keypad";
status = "disabled";
};
@@ -221,7 +222,7 @@
compatible = "samsung,exynos4210-sdhci";
reg = <0x12510000 0x100>;
interrupts = <0 73 0>;
- clocks = <&clock 297>, <&clock 145>;
+ clocks = <&clock CLK_SDMMC0>, <&clock CLK_SCLK_MMC0>;
clock-names = "hsmmc", "mmc_busclk.2";
status = "disabled";
};
@@ -230,7 +231,7 @@
compatible = "samsung,exynos4210-sdhci";
reg = <0x12520000 0x100>;
interrupts = <0 74 0>;
- clocks = <&clock 298>, <&clock 146>;
+ clocks = <&clock CLK_SDMMC1>, <&clock CLK_SCLK_MMC1>;
clock-names = "hsmmc", "mmc_busclk.2";
status = "disabled";
};
@@ -239,7 +240,7 @@
compatible = "samsung,exynos4210-sdhci";
reg = <0x12530000 0x100>;
interrupts = <0 75 0>;
- clocks = <&clock 299>, <&clock 147>;
+ clocks = <&clock CLK_SDMMC2>, <&clock CLK_SCLK_MMC2>;
clock-names = "hsmmc", "mmc_busclk.2";
status = "disabled";
};
@@ -248,7 +249,7 @@
compatible = "samsung,exynos4210-sdhci";
reg = <0x12540000 0x100>;
interrupts = <0 76 0>;
- clocks = <&clock 300>, <&clock 148>;
+ clocks = <&clock CLK_SDMMC3>, <&clock CLK_SCLK_MMC3>;
clock-names = "hsmmc", "mmc_busclk.2";
status = "disabled";
};
@@ -257,7 +258,7 @@
compatible = "samsung,exynos4210-ehci";
reg = <0x12580000 0x100>;
interrupts = <0 70 0>;
- clocks = <&clock 304>;
+ clocks = <&clock CLK_USB_HOST>;
clock-names = "usbhost";
status = "disabled";
};
@@ -266,7 +267,7 @@
compatible = "samsung,exynos4210-ohci";
reg = <0x12590000 0x100>;
interrupts = <0 70 0>;
- clocks = <&clock 304>;
+ clocks = <&clock CLK_USB_HOST>;
clock-names = "usbhost";
status = "disabled";
};
@@ -276,7 +277,7 @@
reg = <0x13400000 0x10000>;
interrupts = <0 94 0>;
samsung,power-domain = <&pd_mfc>;
- clocks = <&clock 273>;
+ clocks = <&clock CLK_MFC>;
clock-names = "mfc";
status = "disabled";
};
@@ -285,7 +286,7 @@
compatible = "samsung,exynos4210-uart";
reg = <0x13800000 0x100>;
interrupts = <0 52 0>;
- clocks = <&clock 312>, <&clock 151>;
+ clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
status = "disabled";
};
@@ -294,7 +295,7 @@
compatible = "samsung,exynos4210-uart";
reg = <0x13810000 0x100>;
interrupts = <0 53 0>;
- clocks = <&clock 313>, <&clock 152>;
+ clocks = <&clock CLK_UART1>, <&clock CLK_SCLK_UART1>;
clock-names = "uart", "clk_uart_baud0";
status = "disabled";
};
@@ -303,7 +304,7 @@
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
- clocks = <&clock 314>, <&clock 153>;
+ clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
status = "disabled";
};
@@ -312,7 +313,7 @@
compatible = "samsung,exynos4210-uart";
reg = <0x13830000 0x100>;
interrupts = <0 55 0>;
- clocks = <&clock 315>, <&clock 154>;
+ clocks = <&clock CLK_UART3>, <&clock CLK_SCLK_UART3>;
clock-names = "uart", "clk_uart_baud0";
status = "disabled";
};
@@ -323,7 +324,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x13860000 0x100>;
interrupts = <0 58 0>;
- clocks = <&clock 317>;
+ clocks = <&clock CLK_I2C0>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_bus>;
@@ -336,7 +337,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x13870000 0x100>;
interrupts = <0 59 0>;
- clocks = <&clock 318>;
+ clocks = <&clock CLK_I2C1>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_bus>;
@@ -349,7 +350,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x13880000 0x100>;
interrupts = <0 60 0>;
- clocks = <&clock 319>;
+ clocks = <&clock CLK_I2C2>;
clock-names = "i2c";
status = "disabled";
};
@@ -360,7 +361,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x13890000 0x100>;
interrupts = <0 61 0>;
- clocks = <&clock 320>;
+ clocks = <&clock CLK_I2C3>;
clock-names = "i2c";
status = "disabled";
};
@@ -371,7 +372,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x138A0000 0x100>;
interrupts = <0 62 0>;
- clocks = <&clock 321>;
+ clocks = <&clock CLK_I2C4>;
clock-names = "i2c";
status = "disabled";
};
@@ -382,7 +383,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x138B0000 0x100>;
interrupts = <0 63 0>;
- clocks = <&clock 322>;
+ clocks = <&clock CLK_I2C5>;
clock-names = "i2c";
status = "disabled";
};
@@ -393,7 +394,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x138C0000 0x100>;
interrupts = <0 64 0>;
- clocks = <&clock 323>;
+ clocks = <&clock CLK_I2C6>;
clock-names = "i2c";
status = "disabled";
};
@@ -404,7 +405,7 @@
compatible = "samsung,s3c2440-i2c";
reg = <0x138D0000 0x100>;
interrupts = <0 65 0>;
- clocks = <&clock 324>;
+ clocks = <&clock CLK_I2C7>;
clock-names = "i2c";
status = "disabled";
};
@@ -417,7 +418,7 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 327>, <&clock 159>;
+ clocks = <&clock CLK_SPI0>, <&clock CLK_SCLK_SPI0>;
clock-names = "spi", "spi_busclk0";
pinctrl-names = "default";
pinctrl-0 = <&spi0_bus>;
@@ -432,7 +433,7 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 328>, <&clock 160>;
+ clocks = <&clock CLK_SPI1>, <&clock CLK_SCLK_SPI1>;
clock-names = "spi", "spi_busclk0";
pinctrl-names = "default";
pinctrl-0 = <&spi1_bus>;
@@ -447,7 +448,7 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 329>, <&clock 161>;
+ clocks = <&clock CLK_SPI2>, <&clock CLK_SCLK_SPI2>;
clock-names = "spi", "spi_busclk0";
pinctrl-names = "default";
pinctrl-0 = <&spi2_bus>;
@@ -458,7 +459,7 @@
compatible = "samsung,exynos4210-pwm";
reg = <0x139D0000 0x1000>;
interrupts = <0 37 0>, <0 38 0>, <0 39 0>, <0 40 0>, <0 41 0>;
- clocks = <&clock 336>;
+ clocks = <&clock CLK_PWM>;
clock-names = "timers";
#pwm-cells = <2>;
status = "disabled";
@@ -475,7 +476,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x12680000 0x1000>;
interrupts = <0 35 0>;
- clocks = <&clock 292>;
+ clocks = <&clock CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -486,7 +487,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x12690000 0x1000>;
interrupts = <0 36 0>;
- clocks = <&clock 293>;
+ clocks = <&clock CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -497,7 +498,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x12850000 0x1000>;
interrupts = <0 34 0>;
- clocks = <&clock 279>;
+ clocks = <&clock CLK_MDMA>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -511,7 +512,7 @@
reg = <0x11c00000 0x20000>;
interrupt-names = "fifo", "vsync", "lcd_sys";
interrupts = <11 0>, <11 1>, <11 2>;
- clocks = <&clock 140>, <&clock 283>;
+ clocks = <&clock CLK_SCLK_FIMD0>, <&clock CLK_FIMD0>;
clock-names = "sclk_fimd", "fimd";
samsung,power-domain = <&pd_lcd0>;
status = "disabled";
diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
index 48ecd7a..cb0e768d 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -53,7 +53,7 @@
reg = <0x10050000 0x800>;
interrupt-parent = <&mct_map>;
interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
- clocks = <&clock 3>, <&clock 344>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
mct_map: mct-map {
@@ -109,7 +109,7 @@
interrupt-parent = <&combiner>;
reg = <0x100C0000 0x100>;
interrupts = <2 4>;
- clocks = <&clock 383>;
+ clocks = <&clock CLK_TMU_APBIF>;
clock-names = "tmu_apbif";
status = "disabled";
};
@@ -118,13 +118,14 @@
compatible = "samsung,s5pv210-g2d";
reg = <0x12800000 0x1000>;
interrupts = <0 89 0>;
- clocks = <&clock 177>, <&clock 277>;
+ clocks = <&clock CLK_SCLK_FIMG2D>, <&clock CLK_G2D>;
clock-names = "sclk_fimg2d", "fimg2d";
status = "disabled";
};
camera {
- clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+ clocks = <&clock CLK_SCLK_CAM0>, <&clock CLK_SCLK_CAM1>,
+ <&clock CLK_PIXELASYNCM0>, <&clock CLK_PIXELASYNCM1>;
clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1";
fimc_0: fimc@11800000 {
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index 5c412aa..e0eb6bb 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -47,7 +47,7 @@
reg = <0x10050000 0x800>;
interrupt-parent = <&mct_map>;
interrupts = <0>, <1>, <2>, <3>, <4>;
- clocks = <&clock 3>, <&clock 344>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
mct_map: mct-map {
@@ -97,13 +97,14 @@
compatible = "samsung,exynos4212-g2d";
reg = <0x10800000 0x1000>;
interrupts = <0 89 0>;
- clocks = <&clock 177>, <&clock 277>;
+ clocks = <&clock CLK_SCLK_FIMG2D>, <&clock CLK_G2D>;
clock-names = "sclk_fimg2d", "fimg2d";
status = "disabled";
};
camera {
- clocks = <&clock 132>, <&clock 133>, <&clock 351>, <&clock 352>;
+ clocks = <&clock CLK_SCLK_CAM0>, <&clock CLK_SCLK_CAM1>,
+ <&clock CLK_PIXELASYNCM0>, <&clock CLK_PIXELASYNCM1>;
clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", "pxl_async1";
fimc_0: fimc@11800000 {
@@ -145,7 +146,7 @@
reg = <0x12390000 0x1000>;
interrupts = <0 105 0>;
samsung,power-domain = <&pd_isp>;
- clocks = <&clock 353>;
+ clocks = <&clock CLK_FIMC_LITE0>;
clock-names = "flite";
status = "disabled";
};
@@ -155,7 +156,7 @@
reg = <0x123A0000 0x1000>;
interrupts = <0 106 0>;
samsung,power-domain = <&pd_isp>;
- clocks = <&clock 354>;
+ clocks = <&clock CLK_FIMC_LITE1>;
clock-names = "flite";
status = "disabled";
};
@@ -165,12 +166,19 @@
reg = <0x12000000 0x260000>;
interrupts = <0 90 0>, <0 95 0>;
samsung,power-domain = <&pd_isp>;
- clocks = <&clock 353>, <&clock 354>, <&clock 355>,
- <&clock 356>, <&clock 17>, <&clock 357>,
- <&clock 358>, <&clock 359>, <&clock 360>,
- <&clock 450>,<&clock 451>, <&clock 452>,
- <&clock 453>, <&clock 176>, <&clock 13>,
- <&clock 454>, <&clock 395>, <&clock 455>;
+ clocks = <&clock CLK_FIMC_LITE0>,
+ <&clock CLK_FIMC_LITE1>, <&clock CLK_PPMUISPX>,
+ <&clock CLK_PPMUISPMX>,
+ <&clock CLK_MOUT_MPLL_USER_T>,
+ <&clock CLK_FIMC_ISP>, <&clock CLK_FIMC_DRC>,
+ <&clock CLK_FIMC_FD>, <&clock CLK_MCUISP>,
+ <&clock CLK_DIV_ISP0>,<&clock CLK_DIV_ISP1>,
+ <&clock CLK_DIV_MCUISP0>,
+ <&clock CLK_DIV_MCUISP1>,
+ <&clock CLK_SCLK_UART_ISP>,
+ <&clock CLK_ACLK200>, <&clock CLK_DIV_ACLK200>,
+ <&clock CLK_ACLK400_MCUISP>,
+ <&clock CLK_DIV_ACLK400_MCUISP>;
clock-names = "lite0", "lite1", "ppmuispx",
"ppmuispmx", "mpll", "isp",
"drc", "fd", "mcuisp",
@@ -190,7 +198,7 @@
i2c1_isp: i2c-isp@12140000 {
compatible = "samsung,exynos4212-i2c-isp";
reg = <0x12140000 0x100>;
- clocks = <&clock 370>;
+ clocks = <&clock CLK_I2C1_ISP>;
clock-names = "i2c_isp";
#address-cells = <1>;
#size-cells = <0>;
@@ -205,7 +213,7 @@
#address-cells = <1>;
#size-cells = <0>;
fifo-depth = <0x80>;
- clocks = <&clock 301>, <&clock 149>;
+ clocks = <&clock CLK_SDMMC4>, <&clock CLK_SCLK_MMC4>;
clock-names = "biu", "ciu";
status = "disabled";
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH RESEND v2 2/4] ARM: dts: exynos5250: convert magic numbers to macros in clock bindings
From: Andrzej Hajda @ 2014-02-24 13:22 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrzej Hajda, Tomasz Figa, Kukjin Kim, Mike Turquette,
Kyungmin Park, moderated list:OPEN FIRMWARE AND...,
moderated list:ARM/S5P EXYNOS AR...
In-Reply-To: <1393248180-17408-1-git-send-email-a.hajda@samsung.com>
The patch replaces magic numbers with macros defined in DT header
in exynos5250 clock bindings.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
---
.../devicetree/bindings/clock/exynos5250-clock.txt | 163 +--------------------
arch/arm/boot/dts/exynos5250.dtsi | 105 ++++++-------
2 files changed, 60 insertions(+), 208 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 72ce617..536eacd 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -13,163 +13,12 @@ Required Properties:
- #clock-cells: should be 1.
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume.
-
-
- [Core Clocks]
-
- Clock ID
- ----------------------------
-
- fin_pll 1
-
- [Clock Gate for Special Clocks]
-
- Clock ID
- ----------------------------
-
- sclk_cam_bayer 128
- sclk_cam0 129
- sclk_cam1 130
- sclk_gscl_wa 131
- sclk_gscl_wb 132
- sclk_fimd1 133
- sclk_mipi1 134
- sclk_dp 135
- sclk_hdmi 136
- sclk_pixel 137
- sclk_audio0 138
- sclk_mmc0 139
- sclk_mmc1 140
- sclk_mmc2 141
- sclk_mmc3 142
- sclk_sata 143
- sclk_usb3 144
- sclk_jpeg 145
- sclk_uart0 146
- sclk_uart1 147
- sclk_uart2 148
- sclk_uart3 149
- sclk_pwm 150
- sclk_audio1 151
- sclk_audio2 152
- sclk_spdif 153
- sclk_spi0 154
- sclk_spi1 155
- sclk_spi2 156
- div_i2s1 157
- div_i2s2 158
- sclk_hdmiphy 159
- div_pcm0 160
-
-
- [Peripheral Clock Gates]
-
- Clock ID
- ----------------------------
-
- gscl0 256
- gscl1 257
- gscl2 258
- gscl3 259
- gscl_wa 260
- gscl_wb 261
- smmu_gscl0 262
- smmu_gscl1 263
- smmu_gscl2 264
- smmu_gscl3 265
- mfc 266
- smmu_mfcl 267
- smmu_mfcr 268
- rotator 269
- jpeg 270
- mdma1 271
- smmu_rotator 272
- smmu_jpeg 273
- smmu_mdma1 274
- pdma0 275
- pdma1 276
- sata 277
- usbotg 278
- mipi_hsi 279
- sdmmc0 280
- sdmmc1 281
- sdmmc2 282
- sdmmc3 283
- sromc 284
- usb2 285
- usb3 286
- sata_phyctrl 287
- sata_phyi2c 288
- uart0 289
- uart1 290
- uart2 291
- uart3 292
- uart4 293
- i2c0 294
- i2c1 295
- i2c2 296
- i2c3 297
- i2c4 298
- i2c5 299
- i2c6 300
- i2c7 301
- i2c_hdmi 302
- adc 303
- spi0 304
- spi1 305
- spi2 306
- i2s1 307
- i2s2 308
- pcm1 309
- pcm2 310
- pwm 311
- spdif 312
- ac97 313
- hsi2c0 314
- hsi2c1 315
- hs12c2 316
- hs12c3 317
- chipid 318
- sysreg 319
- pmu 320
- cmu_top 321
- cmu_core 322
- cmu_mem 323
- tzpc0 324
- tzpc1 325
- tzpc2 326
- tzpc3 327
- tzpc4 328
- tzpc5 329
- tzpc6 330
- tzpc7 331
- tzpc8 332
- tzpc9 333
- hdmi_cec 334
- mct 335
- wdt 336
- rtc 337
- tmu 338
- fimd1 339
- mie1 340
- dsim0 341
- dp 342
- mixer 343
- hdmi 344
- g2d 345
- mdma0 346
- smmu_mdma0 347
-
-
- [Clock Muxes]
-
- Clock ID
- ----------------------------
- mout_hdmi 1024
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5250.h header and can be used in device
+tree sources.
Example 1: An example of a clock controller node is listed below.
@@ -187,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
- clocks = <&clock 314>, <&clock 153>;
+ clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 8f6300f..987cfbe 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -17,6 +17,7 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/clock/exynos5250.h>
#include "exynos5.dtsi"
#include "exynos5250-pinctrl.dtsi"
@@ -90,7 +91,8 @@
compatible = "samsung,exynos5250-audss-clock";
reg = <0x03810000 0x0C>;
#clock-cells = <1>;
- clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
+ <&clock CLK_SCLK_AUDIO0>, <&clock CLK_DIV_PCM0>;
clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
};
@@ -115,7 +117,7 @@
interrupt-parent = <&mct_map>;
interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
<4 0>, <5 0>;
- clocks = <&clock 1>, <&clock 335>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
mct_map: mct-map {
@@ -176,7 +178,7 @@
compatible = "samsung,exynos5250-wdt";
reg = <0x101D0000 0x100>;
interrupts = <0 42 0>;
- clocks = <&clock 336>;
+ clocks = <&clock CLK_WDT>;
clock-names = "watchdog";
samsung,syscon-phandle = <&pmu_system_controller>;
};
@@ -185,7 +187,7 @@
compatible = "samsung,exynos5250-g2d";
reg = <0x10850000 0x1000>;
interrupts = <0 91 0>;
- clocks = <&clock 345>;
+ clocks = <&clock CLK_G2D>;
clock-names = "fimg2d";
};
@@ -194,12 +196,12 @@
reg = <0x11000000 0x10000>;
interrupts = <0 96 0>;
samsung,power-domain = <&pd_mfc>;
- clocks = <&clock 266>;
+ clocks = <&clock CLK_MFC>;
clock-names = "mfc";
};
rtc@101E0000 {
- clocks = <&clock 337>;
+ clocks = <&clock CLK_RTC>;
clock-names = "rtc";
status = "disabled";
};
@@ -208,27 +210,27 @@
compatible = "samsung,exynos5250-tmu";
reg = <0x10060000 0x100>;
interrupts = <0 65 0>;
- clocks = <&clock 338>;
+ clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
};
serial@12C00000 {
- clocks = <&clock 289>, <&clock 146>;
+ clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
};
serial@12C10000 {
- clocks = <&clock 290>, <&clock 147>;
+ clocks = <&clock CLK_UART1>, <&clock CLK_SCLK_UART1>;
clock-names = "uart", "clk_uart_baud0";
};
serial@12C20000 {
- clocks = <&clock 291>, <&clock 148>;
+ clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};
serial@12C30000 {
- clocks = <&clock 292>, <&clock 149>;
+ clocks = <&clock CLK_UART3>, <&clock CLK_SCLK_UART3>;
clock-names = "uart", "clk_uart_baud0";
};
@@ -236,7 +238,7 @@
compatible = "samsung,exynos5-sata-ahci";
reg = <0x122F0000 0x1ff>;
interrupts = <0 115 0>;
- clocks = <&clock 277>, <&clock 143>;
+ clocks = <&clock CLK_SATA>, <&clock CLK_SCLK_SATA>;
clock-names = "sata", "sclk_sata";
};
@@ -251,7 +253,7 @@
interrupts = <0 56 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 294>;
+ clocks = <&clock CLK_I2C0>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_bus>;
@@ -264,7 +266,7 @@
interrupts = <0 57 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 295>;
+ clocks = <&clock CLK_I2C1>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_bus>;
@@ -277,7 +279,7 @@
interrupts = <0 58 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 296>;
+ clocks = <&clock CLK_I2C2>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c2_bus>;
@@ -290,7 +292,7 @@
interrupts = <0 59 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 297>;
+ clocks = <&clock CLK_I2C3>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c3_bus>;
@@ -303,7 +305,7 @@
interrupts = <0 60 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 298>;
+ clocks = <&clock CLK_I2C4>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c4_bus>;
@@ -316,7 +318,7 @@
interrupts = <0 61 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 299>;
+ clocks = <&clock CLK_I2C5>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c5_bus>;
@@ -329,7 +331,7 @@
interrupts = <0 62 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 300>;
+ clocks = <&clock CLK_I2C6>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c6_bus>;
@@ -342,7 +344,7 @@
interrupts = <0 63 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 301>;
+ clocks = <&clock CLK_I2C7>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c7_bus>;
@@ -355,7 +357,7 @@
interrupts = <0 64 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 302>;
+ clocks = <&clock CLK_I2C_HDMI>;
clock-names = "i2c";
status = "disabled";
};
@@ -365,7 +367,7 @@
reg = <0x121D0000 0x100>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 288>;
+ clocks = <&clock CLK_SATA_PHYI2C>;
clock-names = "i2c";
status = "disabled";
};
@@ -380,7 +382,7 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 304>, <&clock 154>;
+ clocks = <&clock CLK_SPI0>, <&clock CLK_SCLK_SPI0>;
clock-names = "spi", "spi_busclk0";
pinctrl-names = "default";
pinctrl-0 = <&spi0_bus>;
@@ -396,7 +398,7 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 305>, <&clock 155>;
+ clocks = <&clock CLK_SPI1>, <&clock CLK_SCLK_SPI1>;
clock-names = "spi", "spi_busclk0";
pinctrl-names = "default";
pinctrl-0 = <&spi1_bus>;
@@ -412,7 +414,7 @@
dma-names = "tx", "rx";
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 306>, <&clock 156>;
+ clocks = <&clock CLK_SPI2>, <&clock CLK_SCLK_SPI2>;
clock-names = "spi", "spi_busclk0";
pinctrl-names = "default";
pinctrl-0 = <&spi2_bus>;
@@ -424,7 +426,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x12200000 0x1000>;
- clocks = <&clock 280>, <&clock 139>;
+ clocks = <&clock CLK_SDMMC0>, <&clock CLK_SCLK_MMC0>;
clock-names = "biu", "ciu";
fifo-depth = <0x80>;
status = "disabled";
@@ -436,7 +438,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x12210000 0x1000>;
- clocks = <&clock 281>, <&clock 140>;
+ clocks = <&clock CLK_SDMMC1>, <&clock CLK_SCLK_MMC1>;
clock-names = "biu", "ciu";
fifo-depth = <0x80>;
status = "disabled";
@@ -448,7 +450,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x12220000 0x1000>;
- clocks = <&clock 282>, <&clock 141>;
+ clocks = <&clock CLK_SDMMC2>, <&clock CLK_SCLK_MMC2>;
clock-names = "biu", "ciu";
fifo-depth = <0x80>;
status = "disabled";
@@ -460,7 +462,7 @@
interrupts = <0 78 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 283>, <&clock 142>;
+ clocks = <&clock CLK_SDMMC3>, <&clock CLK_SCLK_MMC3>;
clock-names = "biu", "ciu";
fifo-depth = <0x80>;
status = "disabled";
@@ -490,7 +492,7 @@
dmas = <&pdma1 12
&pdma1 11>;
dma-names = "tx", "rx";
- clocks = <&clock 307>, <&clock 157>;
+ clocks = <&clock CLK_I2S1>, <&clock CLK_DIV_I2S1>;
clock-names = "iis", "i2s_opclk0";
pinctrl-names = "default";
pinctrl-0 = <&i2s1_bus>;
@@ -503,7 +505,7 @@
dmas = <&pdma0 12
&pdma0 11>;
dma-names = "tx", "rx";
- clocks = <&clock 308>, <&clock 158>;
+ clocks = <&clock CLK_I2S2>, <&clock CLK_DIV_I2S2>;
clock-names = "iis", "i2s_opclk0";
pinctrl-names = "default";
pinctrl-0 = <&i2s2_bus>;
@@ -511,7 +513,7 @@
usb@12000000 {
compatible = "samsung,exynos5250-dwusb3";
- clocks = <&clock 286>;
+ clocks = <&clock CLK_USB3>;
clock-names = "usbdrd30";
#address-cells = <1>;
#size-cells = <1>;
@@ -528,7 +530,7 @@
usb3_phy: usbphy@12100000 {
compatible = "samsung,exynos5250-usb3phy";
reg = <0x12100000 0x100>;
- clocks = <&clock 1>, <&clock 286>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_USB3>;
clock-names = "ext_xtal", "usbdrd30";
#address-cells = <1>;
#size-cells = <1>;
@@ -544,7 +546,7 @@
reg = <0x12110000 0x100>;
interrupts = <0 71 0>;
- clocks = <&clock 285>;
+ clocks = <&clock CLK_USB2>;
clock-names = "usbhost";
};
@@ -553,14 +555,14 @@
reg = <0x12120000 0x100>;
interrupts = <0 71 0>;
- clocks = <&clock 285>;
+ clocks = <&clock CLK_USB2>;
clock-names = "usbhost";
};
usb2_phy: usbphy@12130000 {
compatible = "samsung,exynos5250-usb2phy";
reg = <0x12130000 0x100>;
- clocks = <&clock 1>, <&clock 285>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_USB2>;
clock-names = "ext_xtal", "usbhost";
#address-cells = <1>;
#size-cells = <1>;
@@ -577,7 +579,7 @@
reg = <0x12dd0000 0x100>;
samsung,pwm-outputs = <0>, <1>, <2>, <3>;
#pwm-cells = <3>;
- clocks = <&clock 311>;
+ clocks = <&clock CLK_PWM>;
clock-names = "timers";
};
@@ -592,7 +594,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x121A0000 0x1000>;
interrupts = <0 34 0>;
- clocks = <&clock 275>;
+ clocks = <&clock CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -603,7 +605,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x121B0000 0x1000>;
interrupts = <0 35 0>;
- clocks = <&clock 276>;
+ clocks = <&clock CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -614,7 +616,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x10800000 0x1000>;
interrupts = <0 33 0>;
- clocks = <&clock 346>;
+ clocks = <&clock CLK_MDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -625,7 +627,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x11C10000 0x1000>;
interrupts = <0 124 0>;
- clocks = <&clock 271>;
+ clocks = <&clock CLK_MDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -638,7 +640,7 @@
reg = <0x13e00000 0x1000>;
interrupts = <0 85 0>;
samsung,power-domain = <&pd_gsc>;
- clocks = <&clock 256>;
+ clocks = <&clock CLK_GSCL0>;
clock-names = "gscl";
};
@@ -647,7 +649,7 @@
reg = <0x13e10000 0x1000>;
interrupts = <0 86 0>;
samsung,power-domain = <&pd_gsc>;
- clocks = <&clock 257>;
+ clocks = <&clock CLK_GSCL1>;
clock-names = "gscl";
};
@@ -656,7 +658,7 @@
reg = <0x13e20000 0x1000>;
interrupts = <0 87 0>;
samsung,power-domain = <&pd_gsc>;
- clocks = <&clock 258>;
+ clocks = <&clock CLK_GSCL2>;
clock-names = "gscl";
};
@@ -665,7 +667,7 @@
reg = <0x13e30000 0x1000>;
interrupts = <0 88 0>;
samsung,power-domain = <&pd_gsc>;
- clocks = <&clock 259>;
+ clocks = <&clock CLK_GSCL3>;
clock-names = "gscl";
};
@@ -673,8 +675,9 @@
compatible = "samsung,exynos4212-hdmi";
reg = <0x14530000 0x70000>;
interrupts = <0 95 0>;
- clocks = <&clock 344>, <&clock 136>, <&clock 137>,
- <&clock 159>, <&clock 1024>;
+ clocks = <&clock CLK_HDMI>, <&clock CLK_SCLK_HDMI>,
+ <&clock CLK_SCLK_PIXEL>, <&clock CLK_SCLK_HDMIPHY>,
+ <&clock CLK_MOUT_HDMI>;
clock-names = "hdmi", "sclk_hdmi", "sclk_pixel",
"sclk_hdmiphy", "mout_hdmi";
};
@@ -683,7 +686,7 @@
compatible = "samsung,exynos5250-mixer";
reg = <0x14450000 0x10000>;
interrupts = <0 94 0>;
- clocks = <&clock 343>, <&clock 136>;
+ clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>;
clock-names = "mixer", "sclk_hdmi";
};
@@ -694,14 +697,14 @@
};
dp-controller@145B0000 {
- clocks = <&clock 342>;
+ clocks = <&clock CLK_DP>;
clock-names = "dp";
phys = <&dp_phy>;
phy-names = "dp";
};
fimd@14400000 {
- clocks = <&clock 133>, <&clock 339>;
+ clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
clock-names = "sclk_fimd", "fimd";
};
@@ -709,7 +712,7 @@
compatible = "samsung,exynos-adc-v1";
reg = <0x12D10000 0x100>, <0x10040718 0x4>;
interrupts = <0 106 0>;
- clocks = <&clock 303>;
+ clocks = <&clock CLK_ADC>;
clock-names = "adc";
#io-channel-cells = <1>;
io-channel-ranges;
--
1.8.3.2
^ permalink raw reply related
* [PATCH RESEND v2 3/4] ARM: dts: exynos5420: convert magic numbers to macros in clock bindings
From: Andrzej Hajda @ 2014-02-24 13:22 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrzej Hajda, Tomasz Figa, Kukjin Kim, Mike Turquette,
Kyungmin Park, moderated list:OPEN FIRMWARE AND...,
moderated list:ARM/S5P EXYNOS AR...
In-Reply-To: <1393248180-17408-1-git-send-email-a.hajda@samsung.com>
The patch replaces magic numbers with macros defined in DT header
in exynos5420 clock bindings.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
---
.../devicetree/bindings/clock/exynos5420-clock.txt | 184 +--------------------
arch/arm/boot/dts/exynos5420.dtsi | 95 +++++------
2 files changed, 55 insertions(+), 224 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 458f347..ca88c97 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -13,184 +13,12 @@ Required Properties:
- #clock-cells: should be 1.
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume.
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
-
- [Core Clocks]
-
- Clock ID
- ----------------------------
-
- fin_pll 1
-
- [Clock Gate for Special Clocks]
-
- Clock ID
- ----------------------------
- sclk_uart0 128
- sclk_uart1 129
- sclk_uart2 130
- sclk_uart3 131
- sclk_mmc0 132
- sclk_mmc1 133
- sclk_mmc2 134
- sclk_spi0 135
- sclk_spi1 136
- sclk_spi2 137
- sclk_i2s1 138
- sclk_i2s2 139
- sclk_pcm1 140
- sclk_pcm2 141
- sclk_spdif 142
- sclk_hdmi 143
- sclk_pixel 144
- sclk_dp1 145
- sclk_mipi1 146
- sclk_fimd1 147
- sclk_maudio0 148
- sclk_maupcm0 149
- sclk_usbd300 150
- sclk_usbd301 151
- sclk_usbphy300 152
- sclk_usbphy301 153
- sclk_unipro 154
- sclk_pwm 155
- sclk_gscl_wa 156
- sclk_gscl_wb 157
- sclk_hdmiphy 158
-
- [Peripheral Clock Gates]
-
- Clock ID
- ----------------------------
-
- aclk66_peric 256
- uart0 257
- uart1 258
- uart2 259
- uart3 260
- i2c0 261
- i2c1 262
- i2c2 263
- i2c3 264
- i2c4 265
- i2c5 266
- i2c6 267
- i2c7 268
- i2c_hdmi 269
- tsadc 270
- spi0 271
- spi1 272
- spi2 273
- keyif 274
- i2s1 275
- i2s2 276
- pcm1 277
- pcm2 278
- pwm 279
- spdif 280
- i2c8 281
- i2c9 282
- i2c10 283
- aclk66_psgen 300
- chipid 301
- sysreg 302
- tzpc0 303
- tzpc1 304
- tzpc2 305
- tzpc3 306
- tzpc4 307
- tzpc5 308
- tzpc6 309
- tzpc7 310
- tzpc8 311
- tzpc9 312
- hdmi_cec 313
- seckey 314
- mct 315
- wdt 316
- rtc 317
- tmu 318
- tmu_gpu 319
- pclk66_gpio 330
- aclk200_fsys2 350
- mmc0 351
- mmc1 352
- mmc2 353
- sromc 354
- ufs 355
- aclk200_fsys 360
- tsi 361
- pdma0 362
- pdma1 363
- rtic 364
- usbh20 365
- usbd300 366
- usbd301 377
- aclk400_mscl 380
- mscl0 381
- mscl1 382
- mscl2 383
- smmu_mscl0 384
- smmu_mscl1 385
- smmu_mscl2 386
- aclk333 400
- mfc 401
- smmu_mfcl 402
- smmu_mfcr 403
- aclk200_disp1 410
- dsim1 411
- dp1 412
- hdmi 413
- aclk300_disp1 420
- fimd1 421
- smmu_fimd1 422
- aclk166 430
- mixer 431
- aclk266 440
- rotator 441
- mdma1 442
- smmu_rotator 443
- smmu_mdma1 444
- aclk300_jpeg 450
- jpeg 451
- jpeg2 452
- smmu_jpeg 453
- aclk300_gscl 460
- smmu_gscl0 461
- smmu_gscl1 462
- gscl_wa 463
- gscl_wb 464
- gscl0 465
- gscl1 466
- clk_3aa 467
- aclk266_g2d 470
- sss 471
- slim_sss 472
- mdma0 473
- aclk333_g2d 480
- g2d 481
- aclk333_432_gscl 490
- smmu_3aa 491
- smmu_fimcl0 492
- smmu_fimcl1 493
- smmu_fimcl3 494
- fimc_lite3 495
- aclk_g3d 500
- g3d 501
- smmu_mixer 502
-
- Mux ID
- ----------------------------
-
- mout_hdmi 640
-
- Divider ID
- ----------------------------
-
- dout_pixel 768
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5420.h header and can be used in device
+tree sources.
Example 1: An example of a clock controller node is listed below.
@@ -208,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
compatible = "samsung,exynos4210-uart";
reg = <0x13820000 0x100>;
interrupts = <0 54 0>;
- clocks = <&clock 259>, <&clock 130>;
+ clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 45e2e65..e3329af 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -13,6 +13,7 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/clock/exynos5420.h>
#include "exynos5.dtsi"
#include "exynos5420-pinctrl.dtsi"
@@ -119,7 +120,8 @@
compatible = "samsung,exynos5420-audss-clock";
reg = <0x03810000 0x0C>;
#clock-cells = <1>;
- clocks = <&clock 1>, <&clock 5>, <&clock 148>, <&clock 149>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_FOUT_EPLL>,
+ <&clock CLK_SCLK_MAUDIO0>, <&clock CLK_SCLK_MAUPCM0>;
clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in";
};
@@ -127,7 +129,7 @@
compatible = "samsung,mfc-v7";
reg = <0x11000000 0x10000>;
interrupts = <0 96 0>;
- clocks = <&clock 401>;
+ clocks = <&clock CLK_MFC>;
clock-names = "mfc";
};
@@ -137,7 +139,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x12200000 0x2000>;
- clocks = <&clock 351>, <&clock 132>;
+ clocks = <&clock CLK_MMC0>, <&clock CLK_SCLK_MMC0>;
clock-names = "biu", "ciu";
fifo-depth = <0x40>;
status = "disabled";
@@ -149,7 +151,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x12210000 0x2000>;
- clocks = <&clock 352>, <&clock 133>;
+ clocks = <&clock CLK_MMC1>, <&clock CLK_SCLK_MMC1>;
clock-names = "biu", "ciu";
fifo-depth = <0x40>;
status = "disabled";
@@ -161,7 +163,7 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0x12220000 0x1000>;
- clocks = <&clock 353>, <&clock 134>;
+ clocks = <&clock CLK_MMC2>, <&clock CLK_SCLK_MMC2>;
clock-names = "biu", "ciu";
fifo-depth = <0x40>;
status = "disabled";
@@ -175,7 +177,7 @@
interrupt-parent = <&mct_map>;
interrupts = <0>, <1>, <2>, <3>, <4>, <5>, <6>, <7>,
<8>, <9>, <10>, <11>;
- clocks = <&clock 1>, <&clock 315>;
+ clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MCT>;
clock-names = "fin_pll", "mct";
mct_map: mct-map {
@@ -269,7 +271,7 @@
};
rtc@101E0000 {
- clocks = <&clock 317>;
+ clocks = <&clock CLK_RTC>;
clock-names = "rtc";
status = "disabled";
};
@@ -296,7 +298,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x121A0000 0x1000>;
interrupts = <0 34 0>;
- clocks = <&clock 362>;
+ clocks = <&clock CLK_PDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -307,7 +309,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x121B0000 0x1000>;
interrupts = <0 35 0>;
- clocks = <&clock 363>;
+ clocks = <&clock CLK_PDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -318,7 +320,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x10800000 0x1000>;
interrupts = <0 33 0>;
- clocks = <&clock 473>;
+ clocks = <&clock CLK_MDMA0>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -329,7 +331,7 @@
compatible = "arm,pl330", "arm,primecell";
reg = <0x11C10000 0x1000>;
interrupts = <0 124 0>;
- clocks = <&clock 442>;
+ clocks = <&clock CLK_MDMA1>;
clock-names = "apb_pclk";
#dma-cells = <1>;
#dma-channels = <8>;
@@ -360,7 +362,7 @@
dmas = <&pdma1 12
&pdma1 11>;
dma-names = "tx", "rx";
- clocks = <&clock 275>, <&clock 138>;
+ clocks = <&clock CLK_I2S1>, <&clock CLK_SCLK_I2S1>;
clock-names = "iis", "i2s_opclk0";
pinctrl-names = "default";
pinctrl-0 = <&i2s1_bus>;
@@ -373,7 +375,7 @@
dmas = <&pdma0 12
&pdma0 11>;
dma-names = "tx", "rx";
- clocks = <&clock 276>, <&clock 139>;
+ clocks = <&clock CLK_I2S2>, <&clock CLK_SCLK_I2S2>;
clock-names = "iis", "i2s_opclk0";
pinctrl-names = "default";
pinctrl-0 = <&i2s2_bus>;
@@ -391,7 +393,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&spi0_bus>;
- clocks = <&clock 271>, <&clock 135>;
+ clocks = <&clock CLK_SPI0>, <&clock CLK_SCLK_SPI0>;
clock-names = "spi", "spi_busclk0";
status = "disabled";
};
@@ -407,7 +409,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&spi1_bus>;
- clocks = <&clock 272>, <&clock 136>;
+ clocks = <&clock CLK_SPI1>, <&clock CLK_SCLK_SPI1>;
clock-names = "spi", "spi_busclk0";
status = "disabled";
};
@@ -423,28 +425,28 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&spi2_bus>;
- clocks = <&clock 273>, <&clock 137>;
+ clocks = <&clock CLK_SPI2>, <&clock CLK_SCLK_SPI2>;
clock-names = "spi", "spi_busclk0";
status = "disabled";
};
serial@12C00000 {
- clocks = <&clock 257>, <&clock 128>;
+ clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
};
serial@12C10000 {
- clocks = <&clock 258>, <&clock 129>;
+ clocks = <&clock CLK_UART1>, <&clock CLK_SCLK_UART1>;
clock-names = "uart", "clk_uart_baud0";
};
serial@12C20000 {
- clocks = <&clock 259>, <&clock 130>;
+ clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
};
serial@12C30000 {
- clocks = <&clock 260>, <&clock 131>;
+ clocks = <&clock CLK_UART3>, <&clock CLK_SCLK_UART3>;
clock-names = "uart", "clk_uart_baud0";
};
@@ -453,7 +455,7 @@
reg = <0x12dd0000 0x100>;
samsung,pwm-outputs = <0>, <1>, <2>, <3>;
#pwm-cells = <3>;
- clocks = <&clock 279>;
+ clocks = <&clock CLK_PWM>;
clock-names = "timers";
};
@@ -464,7 +466,7 @@
};
dp-controller@145B0000 {
- clocks = <&clock 412>;
+ clocks = <&clock CLK_DP1>;
clock-names = "dp";
phys = <&dp_phy>;
phy-names = "dp";
@@ -472,7 +474,7 @@
fimd@14400000 {
samsung,power-domain = <&disp_pd>;
- clocks = <&clock 147>, <&clock 421>;
+ clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
clock-names = "sclk_fimd", "fimd";
};
@@ -480,7 +482,7 @@
compatible = "samsung,exynos-adc-v2";
reg = <0x12D10000 0x100>, <0x10040720 0x4>;
interrupts = <0 106 0>;
- clocks = <&clock 270>;
+ clocks = <&clock CLK_TSADC>;
clock-names = "adc";
#io-channel-cells = <1>;
io-channel-ranges;
@@ -493,7 +495,7 @@
interrupts = <0 56 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 261>;
+ clocks = <&clock CLK_I2C0>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c0_bus>;
@@ -506,7 +508,7 @@
interrupts = <0 57 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 262>;
+ clocks = <&clock CLK_I2C1>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_bus>;
@@ -519,7 +521,7 @@
interrupts = <0 58 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 263>;
+ clocks = <&clock CLK_I2C2>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c2_bus>;
@@ -532,7 +534,7 @@
interrupts = <0 59 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 264>;
+ clocks = <&clock CLK_I2C3>;
clock-names = "i2c";
pinctrl-names = "default";
pinctrl-0 = <&i2c3_bus>;
@@ -547,7 +549,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c4_hs_bus>;
- clocks = <&clock 265>;
+ clocks = <&clock CLK_I2C4>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -560,7 +562,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c5_hs_bus>;
- clocks = <&clock 266>;
+ clocks = <&clock CLK_I2C5>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -573,7 +575,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c6_hs_bus>;
- clocks = <&clock 267>;
+ clocks = <&clock CLK_I2C6>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -586,7 +588,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c7_hs_bus>;
- clocks = <&clock 268>;
+ clocks = <&clock CLK_I2C7>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -599,7 +601,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c8_hs_bus>;
- clocks = <&clock 281>;
+ clocks = <&clock CLK_I2C8>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -612,7 +614,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c9_hs_bus>;
- clocks = <&clock 282>;
+ clocks = <&clock CLK_I2C9>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -625,7 +627,7 @@
#size-cells = <0>;
pinctrl-names = "default";
pinctrl-0 = <&i2c10_hs_bus>;
- clocks = <&clock 283>;
+ clocks = <&clock CLK_I2C10>;
clock-names = "hsi2c";
status = "disabled";
};
@@ -634,8 +636,9 @@
compatible = "samsung,exynos4212-hdmi";
reg = <0x14530000 0x70000>;
interrupts = <0 95 0>;
- clocks = <&clock 413>, <&clock 143>, <&clock 768>,
- <&clock 158>, <&clock 640>;
+ clocks = <&clock CLK_HDMI>, <&clock CLK_SCLK_HDMI>,
+ <&clock CLK_DOUT_PIXEL>, <&clock CLK_SCLK_HDMIPHY>,
+ <&clock CLK_MOUT_HDMI>;
clock-names = "hdmi", "sclk_hdmi", "sclk_pixel",
"sclk_hdmiphy", "mout_hdmi";
status = "disabled";
@@ -645,7 +648,7 @@
compatible = "samsung,exynos5420-mixer";
reg = <0x14450000 0x10000>;
interrupts = <0 94 0>;
- clocks = <&clock 431>, <&clock 143>;
+ clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>;
clock-names = "mixer", "sclk_hdmi";
};
@@ -653,7 +656,7 @@
compatible = "samsung,exynos5-gsc";
reg = <0x13e00000 0x1000>;
interrupts = <0 85 0>;
- clocks = <&clock 465>;
+ clocks = <&clock CLK_GSCL0>;
clock-names = "gscl";
samsung,power-domain = <&gsc_pd>;
};
@@ -662,7 +665,7 @@
compatible = "samsung,exynos5-gsc";
reg = <0x13e10000 0x1000>;
interrupts = <0 86 0>;
- clocks = <&clock 466>;
+ clocks = <&clock CLK_GSCL1>;
clock-names = "gscl";
samsung,power-domain = <&gsc_pd>;
};
@@ -676,7 +679,7 @@
compatible = "samsung,exynos5420-tmu";
reg = <0x10060000 0x100>;
interrupts = <0 65 0>;
- clocks = <&clock 318>;
+ clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
};
@@ -684,7 +687,7 @@
compatible = "samsung,exynos5420-tmu";
reg = <0x10064000 0x100>;
interrupts = <0 183 0>;
- clocks = <&clock 318>;
+ clocks = <&clock CLK_TMU>;
clock-names = "tmu_apbif";
};
@@ -692,7 +695,7 @@
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x10068000 0x100>, <0x1006c000 0x4>;
interrupts = <0 184 0>;
- clocks = <&clock 318>, <&clock 318>;
+ clocks = <&clock CLK_TMU>, <&clock CLK_TMU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
};
@@ -700,7 +703,7 @@
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x1006c000 0x100>, <0x100a0000 0x4>;
interrupts = <0 185 0>;
- clocks = <&clock 318>, <&clock 319>;
+ clocks = <&clock CLK_TMU>, <&clock CLK_TMU_GPU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
};
@@ -708,7 +711,7 @@
compatible = "samsung,exynos5420-tmu-ext-triminfo";
reg = <0x100a0000 0x100>, <0x10068000 0x4>;
interrupts = <0 215 0>;
- clocks = <&clock 319>, <&clock 318>;
+ clocks = <&clock CLK_TMU_GPU>, <&clock CLK_TMU>;
clock-names = "tmu_apbif", "tmu_triminfo_apbif";
};
@@ -716,7 +719,7 @@
compatible = "samsung,exynos5420-wdt";
reg = <0x101D0000 0x100>;
interrupts = <0 42 0>;
- clocks = <&clock 316>;
+ clocks = <&clock CLK_WDT>;
clock-names = "watchdog";
samsung,syscon-phandle = <&pmu_system_controller>;
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH RESEND v2 4/4] ARM: dts: exynos5440: convert magic numbers to macros in clock bindings
From: Andrzej Hajda @ 2014-02-24 13:23 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Andrzej Hajda, Tomasz Figa, Kukjin Kim, Mike Turquette,
Kyungmin Park, moderated list:OPEN FIRMWARE AND...,
moderated list:ARM/S5P EXYNOS AR...
In-Reply-To: <1393248180-17408-1-git-send-email-a.hajda@samsung.com>
The patch replaces magic numbers with macros defined in DT header
in exynos5440 clock bindings.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
---
.../devicetree/bindings/clock/exynos5440-clock.txt | 45 +++-------------------
arch/arm/boot/dts/exynos5440.dtsi | 33 ++++++++--------
2 files changed, 23 insertions(+), 55 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
index 9955dc9..5f7005f 100644
--- a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
@@ -12,45 +12,12 @@ Required Properties:
- #clock-cells: should be 1.
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume.
-
-
- [Core Clocks]
-
- Clock ID
- ----------------------------
-
- xtal 1
- arm_clk 2
-
- [Peripheral Clock Gates]
-
- Clock ID
- ----------------------------
-
- spi_baud 16
- pb0_250 17
- pr0_250 18
- pr1_250 19
- b_250 20
- b_125 21
- b_200 22
- sata 23
- usb 24
- gmac0 25
- cs250 26
- pb0_250_o 27
- pr0_250_o 28
- pr1_250_o 29
- b_250_o 30
- b_125_o 31
- b_200_o 32
- sata_o 33
- usb_o 34
- gmac0_o 35
- cs250_o 36
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5440.h header and can be used in device
+tree sources.
Example: An example of a clock controller node is listed below.
diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
index 02a0a12..75c7b89 100644
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@ -9,6 +9,7 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/clock/exynos5440.h>
#include "skeleton.dtsi"
/ {
@@ -105,7 +106,7 @@
compatible = "samsung,exynos4210-uart";
reg = <0xB0000 0x1000>;
interrupts = <0 2 0>;
- clocks = <&clock 21>, <&clock 21>;
+ clocks = <&clock CLK_B_125>, <&clock CLK_B_125>;
clock-names = "uart", "clk_uart_baud0";
};
@@ -113,7 +114,7 @@
compatible = "samsung,exynos4210-uart";
reg = <0xC0000 0x1000>;
interrupts = <0 3 0>;
- clocks = <&clock 21>, <&clock 21>;
+ clocks = <&clock CLK_B_125>, <&clock CLK_B_125>;
clock-names = "uart", "clk_uart_baud0";
};
@@ -125,7 +126,7 @@
#size-cells = <0>;
samsung,spi-src-clk = <0>;
num-cs = <1>;
- clocks = <&clock 21>, <&clock 16>;
+ clocks = <&clock CLK_B_125>, <&clock CLK_SPI_BAUD>;
clock-names = "spi", "spi_busclk0";
};
@@ -161,7 +162,7 @@
interrupts = <0 5 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 21>;
+ clocks = <&clock CLK_B_125>;
clock-names = "i2c";
};
@@ -171,7 +172,7 @@
interrupts = <0 6 0>;
#address-cells = <1>;
#size-cells = <0>;
- clocks = <&clock 21>;
+ clocks = <&clock CLK_B_125>;
clock-names = "i2c";
};
@@ -179,7 +180,7 @@
compatible = "samsung,s3c2410-wdt";
reg = <0x110000 0x1000>;
interrupts = <0 1 0>;
- clocks = <&clock 21>;
+ clocks = <&clock CLK_B_125>;
clock-names = "watchdog";
};
@@ -190,7 +191,7 @@
interrupts = <0 31 4>;
interrupt-names = "macirq";
phy-mode = "sgmii";
- clocks = <&clock 25>;
+ clocks = <&clock CLK_GMAC0>;
clock-names = "stmmaceth";
};
@@ -206,7 +207,7 @@
compatible = "samsung,s3c6410-rtc";
reg = <0x130000 0x1000>;
interrupts = <0 17 0>, <0 16 0>;
- clocks = <&clock 21>;
+ clocks = <&clock CLK_B_125>;
clock-names = "rtc";
};
@@ -214,7 +215,7 @@
compatible = "samsung,exynos5440-tmu";
reg = <0x160118 0x230>, <0x160368 0x10>;
interrupts = <0 58 0>;
- clocks = <&clock 21>;
+ clocks = <&clock CLK_B_125>;
clock-names = "tmu_apbif";
};
@@ -222,7 +223,7 @@
compatible = "samsung,exynos5440-tmu";
reg = <0x16011C 0x230>, <0x160368 0x10>;
interrupts = <0 58 0>;
- clocks = <&clock 21>;
+ clocks = <&clock CLK_B_125>;
clock-names = "tmu_apbif";
};
@@ -230,7 +231,7 @@
compatible = "samsung,exynos5440-tmu";
reg = <0x160120 0x230>, <0x160368 0x10>;
interrupts = <0 58 0>;
- clocks = <&clock 21>;
+ clocks = <&clock CLK_B_125>;
clock-names = "tmu_apbif";
};
@@ -238,7 +239,7 @@
compatible = "snps,exynos5440-ahci";
reg = <0x210000 0x10000>;
interrupts = <0 30 0>;
- clocks = <&clock 23>;
+ clocks = <&clock CLK_SATA>;
clock-names = "sata";
};
@@ -246,7 +247,7 @@
compatible = "samsung,exynos5440-ohci";
reg = <0x220000 0x1000>;
interrupts = <0 29 0>;
- clocks = <&clock 24>;
+ clocks = <&clock CLK_USB>;
clock-names = "usbhost";
};
@@ -254,7 +255,7 @@
compatible = "samsung,exynos5440-ehci";
reg = <0x221000 0x1000>;
interrupts = <0 29 0>;
- clocks = <&clock 24>;
+ clocks = <&clock CLK_USB>;
clock-names = "usbhost";
};
@@ -264,7 +265,7 @@
0x270000 0x1000
0x271000 0x40>;
interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
- clocks = <&clock 28>, <&clock 27>;
+ clocks = <&clock CLK_PR0_250_O>, <&clock CLK_PB0_250_O>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
@@ -285,7 +286,7 @@
0x272000 0x1000
0x271040 0x40>;
interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
- clocks = <&clock 29>, <&clock 27>;
+ clocks = <&clock CLK_PR1_250_O>, <&clock CLK_PB0_250_O>;
clock-names = "pcie", "pcie_bus";
#address-cells = <3>;
#size-cells = <2>;
--
1.8.3.2
^ permalink raw reply related
* [PATCH V8 0/2] Exynos5250 SATA Support
From: Yuvaraj Kumar C D @ 2014-02-24 13:32 UTC (permalink / raw)
To: kishon, kgene.kim, linux-kernel, linux-arm-kernel, devicetree,
linux-doc
Cc: grant.likely, rob.herring, swarren, mark.rutland,
Yuvaraj Kumar C D
This patch series enable the SATA support on Exynos5250 based boards.
It incorporates the generic phy framework to deal with sata phy.
Yuvaraj Kumar C D (2):
PHY: Exynos: Add Exynos5250 SATA PHY driver
ARM: dts: Enable ahci sata and sata phy
.../devicetree/bindings/ata/exynos-sata-phy.txt | 14 --
.../devicetree/bindings/ata/exynos-sata.txt | 25 +-
.../devicetree/bindings/phy/samsung-phy.txt | 36 +++
arch/arm/boot/dts/exynos5250-arndale.dts | 11 +
arch/arm/boot/dts/exynos5250-smdk5250.dts | 8 +-
arch/arm/boot/dts/exynos5250.dtsi | 17 +-
drivers/phy/Kconfig | 15 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-exynos5250-sata.c | 251 ++++++++++++++++++++
9 files changed, 345 insertions(+), 33 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
create mode 100644 drivers/phy/phy-exynos5250-sata.c
--
1.7.10.4
^ permalink raw reply
* [PATCH V8 1/2] PHY: Exynos: Add Exynos5250 SATA PHY driver
From: Yuvaraj Kumar C D @ 2014-02-24 13:32 UTC (permalink / raw)
To: kishon, kgene.kim, linux-kernel, linux-arm-kernel, devicetree,
linux-doc
Cc: grant.likely, rob.herring, swarren, mark.rutland,
Yuvaraj Kumar C D, Girish K S, Vasanth Ananthan
In-Reply-To: <1393248775-3283-1-git-send-email-yuvaraj.cd@samsung.com>
This patch adds the SATA PHY driver for Exynos5250.Exynos5250 SATA
PHY comprises of CMU and TRSV blocks which are of I2C register Map.
So this patch also adds a i2c client driver, which is used configure
the CMU and TRSV block of exynos5250 SATA PHY.
This patch incorporates the generic PHY framework to deal with SATA
PHY.
This patch depends on the below patch for the sata functionality
[1].ata: ahci_platform: Manage SATA PHY
by Roger Quadros <rogerq@ti.com>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Signed-off-by: Girish K S <ks.giri@samsung.com>
Signed-off-by: Vasanth Ananthan <vasanth.a@samsung.com>
---
Changes from V7:
1.Used BIT macro and made CONFIG_PHY_EXYNOS5250_SATA
depends on HAS_IOMEM and OF.
Changes from V6:
1.Removed phy-exynos5250-sata-i2c.c,as it is not required
after moving to of_find_i2c_device_by_node().
2.Changed struct __iomem *pmureg to struct regmap *pmureg.
3.Changed the wait_for_reg_status() to return 0 or -EFAULT.
Changes from V5:
1.Rebased on latest generic PHY framework for-next tree.
2.Minor nits such as indentations.
Changes from V4:
1.Made Exynos5250 SATA PHY driver by default selects
CONFIG_I2C and CONFIG_I2C_S3C2410, as SATA PHY driver
depends on I2C.
2.struct i2c_driver sataphy_i2c_driver made static which
was earlier global type.
3.Renamed the files to phy-exynos5250-sata.c and
phy-exynos5250-sata-i2c.c and CONFIG_EXYNOS5250_SATA_PHY
to CONFIG_PHY_EXYNOS5250_SATA.
Changes from V3:
1.Moved devm_phy_create before to devm_phy_provider_register.
Changes from V2:
1.Removed of_match_table
2.Moved to syscon interface for PMU handling.
Changes from V1:
1.Adapted to latest version of Generic PHY framework
2.Removed exynos_sata_i2c_remove function.
drivers/phy/Kconfig | 15 +++
drivers/phy/Makefile | 1 +
drivers/phy/phy-exynos5250-sata.c | 251 +++++++++++++++++++++++++++++++++++++
3 files changed, 267 insertions(+)
create mode 100644 drivers/phy/phy-exynos5250-sata.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index afa2354..7c92e77 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -64,4 +64,19 @@ config BCM_KONA_USB2_PHY
help
Enable this to support the Broadcom Kona USB 2.0 PHY.
+config PHY_EXYNOS5250_SATA
+ tristate "Exynos5250 Sata SerDes/PHY driver"
+ depends on SOC_EXYNOS5250
+ depends on HAS_IOMEM
+ depends on OF
+ select GENERIC_PHY
+ select I2C
+ select I2C_S3C2410
+ select MFD_SYSCON
+ help
+ Enable this to support SATA SerDes/Phy found on Samsung's
+ Exynos5250 based SoCs.This SerDes/Phy supports SATA 1.5 Gb/s,
+ SATA 3.0 Gb/s, SATA 6.0 Gb/s speeds. It supports one SATA host
+ port to accept one SATA device.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index b57c253..0d03822 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_PHY_EXYNOS5250_SATA) += phy-exynos5250-sata.o
diff --git a/drivers/phy/phy-exynos5250-sata.c b/drivers/phy/phy-exynos5250-sata.c
new file mode 100644
index 0000000..8ccd305
--- /dev/null
+++ b/drivers/phy/phy-exynos5250-sata.c
@@ -0,0 +1,251 @@
+/*
+ * Samsung SATA SerDes(PHY) driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Authors: Girish K S <ks.giri@samsung.com>
+ * Yuvaraj Kumar C D <yuvaraj.cd@samsung.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/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/spinlock.h>
+#include <linux/mfd/syscon.h>
+
+#define SATAPHY_CONTROL_OFFSET 0x0724
+#define EXYNOS5_SATAPHY_PMU_ENABLE BIT(0)
+#define EXYNOS5_SATA_RESET 0x4
+#define RESET_GLOBAL_RST_N BIT(0)
+#define RESET_CMN_RST_N BIT(1)
+#define RESET_CMN_BLOCK_RST_N BIT(2)
+#define RESET_CMN_I2C_RST_N BIT(3)
+#define RESET_TX_RX_PIPE_RST_N BIT(4)
+#define RESET_TX_RX_BLOCK_RST_N BIT(5)
+#define RESET_TX_RX_I2C_RST_N (BIT(6) | BIT(7))
+#define LINK_RESET 0xf0000
+#define EXYNOS5_SATA_MODE0 0x10
+#define SATA_SPD_GEN3 BIT(1)
+#define EXYNOS5_SATA_CTRL0 0x14
+#define CTRL0_P0_PHY_CALIBRATED_SEL BIT(9)
+#define CTRL0_P0_PHY_CALIBRATED BIT(8)
+#define EXYNOS5_SATA_PHSATA_CTRLM 0xe0
+#define PHCTRLM_REF_RATE BIT(1)
+#define PHCTRLM_HIGH_SPEED BIT(0)
+#define EXYNOS5_SATA_PHSATA_STATM 0xf0
+#define PHSTATM_PLL_LOCKED BIT(0)
+
+#define PHY_PLL_TIMEOUT (usecs_to_jiffies(1000))
+
+struct exynos_sata_phy {
+ struct phy *phy;
+ struct clk *phyclk;
+ void __iomem *regs;
+ struct regmap *pmureg;
+ struct i2c_client *client;
+};
+
+static int wait_for_reg_status(void __iomem *base, u32 reg, u32 checkbit,
+ u32 status)
+{
+ unsigned long timeout = jiffies + PHY_PLL_TIMEOUT;
+
+ while (time_before(jiffies, timeout)) {
+ if ((readl(base + reg) & checkbit) == status)
+ return 0;
+ }
+
+ return -EFAULT;
+}
+
+static int exynos_sata_phy_power_on(struct phy *phy)
+{
+ struct exynos_sata_phy *sata_phy = phy_get_drvdata(phy);
+
+ return regmap_update_bits(sata_phy->pmureg, SATAPHY_CONTROL_OFFSET,
+ EXYNOS5_SATAPHY_PMU_ENABLE, true);
+
+}
+
+static int exynos_sata_phy_power_off(struct phy *phy)
+{
+ struct exynos_sata_phy *sata_phy = phy_get_drvdata(phy);
+
+ return regmap_update_bits(sata_phy->pmureg, SATAPHY_CONTROL_OFFSET,
+ EXYNOS5_SATAPHY_PMU_ENABLE, false);
+
+}
+
+static int exynos_sata_phy_init(struct phy *phy)
+{
+ u32 val = 0;
+ int ret = 0;
+ u8 buf[] = { 0x3a, 0x0b };
+ struct exynos_sata_phy *sata_phy = phy_get_drvdata(phy);
+
+ ret = regmap_update_bits(sata_phy->pmureg, SATAPHY_CONTROL_OFFSET,
+ EXYNOS5_SATAPHY_PMU_ENABLE, true);
+ if (ret != 0)
+ dev_err(&sata_phy->phy->dev, "phy init failed\n");
+
+ writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
+ val |= RESET_GLOBAL_RST_N | RESET_CMN_RST_N | RESET_CMN_BLOCK_RST_N
+ | RESET_CMN_I2C_RST_N | RESET_TX_RX_PIPE_RST_N
+ | RESET_TX_RX_BLOCK_RST_N | RESET_TX_RX_I2C_RST_N;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
+ val |= LINK_RESET;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
+ val |= RESET_CMN_RST_N;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
+ val &= ~PHCTRLM_REF_RATE;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
+
+ /* High speed enable for Gen3 */
+ val = readl(sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
+ val |= PHCTRLM_HIGH_SPEED;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_PHSATA_CTRLM);
+
+ val = readl(sata_phy->regs + EXYNOS5_SATA_CTRL0);
+ val |= CTRL0_P0_PHY_CALIBRATED_SEL | CTRL0_P0_PHY_CALIBRATED;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_CTRL0);
+
+ val = readl(sata_phy->regs + EXYNOS5_SATA_MODE0);
+ val |= SATA_SPD_GEN3;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_MODE0);
+
+ ret = i2c_master_send(sata_phy->client, buf, sizeof(buf));
+ if (ret < 0)
+ return ret;
+
+ /* release cmu reset */
+ val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
+ val &= ~RESET_CMN_RST_N;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
+
+ val = readl(sata_phy->regs + EXYNOS5_SATA_RESET);
+ val |= RESET_CMN_RST_N;
+ writel(val, sata_phy->regs + EXYNOS5_SATA_RESET);
+
+ ret = wait_for_reg_status(sata_phy->regs,
+ EXYNOS5_SATA_PHSATA_STATM,
+ PHSTATM_PLL_LOCKED, 1);
+ if (ret < 0)
+ dev_err(&sata_phy->phy->dev,
+ "PHY PLL locking failed\n");
+ return ret;
+}
+
+static struct phy_ops exynos_sata_phy_ops = {
+ .init = exynos_sata_phy_init,
+ .power_on = exynos_sata_phy_power_on,
+ .power_off = exynos_sata_phy_power_off,
+ .owner = THIS_MODULE,
+};
+
+static int exynos_sata_phy_probe(struct platform_device *pdev)
+{
+ struct exynos_sata_phy *sata_phy;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct phy_provider *phy_provider;
+ struct device_node *node;
+ int ret = 0;
+
+ sata_phy = devm_kzalloc(dev, sizeof(*sata_phy), GFP_KERNEL);
+ if (!sata_phy)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+ sata_phy->regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(sata_phy->regs))
+ return PTR_ERR(sata_phy->regs);
+
+ sata_phy->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
+ "samsung,syscon-phandle");
+ if (IS_ERR(sata_phy->pmureg)) {
+ dev_err(dev, "syscon regmap lookup failed.\n");
+ return PTR_ERR(sata_phy->pmureg);
+ }
+
+ node = of_parse_phandle(dev->of_node,
+ "samsung,exynos-sataphy-i2c-phandle", 0);
+ if (!node)
+ return -EINVAL;
+
+ sata_phy->client = of_find_i2c_device_by_node(node);
+ if (!sata_phy->client)
+ return -EPROBE_DEFER;
+
+ dev_set_drvdata(dev, sata_phy);
+
+ sata_phy->phyclk = devm_clk_get(dev, "sata_phyctrl");
+ if (IS_ERR(sata_phy->phyclk)) {
+ dev_err(dev, "failed to get clk for PHY\n");
+ return PTR_ERR(sata_phy->phyclk);
+ }
+
+ ret = clk_prepare_enable(sata_phy->phyclk);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable source clk\n");
+ return ret;
+ }
+
+ sata_phy->phy = devm_phy_create(dev, &exynos_sata_phy_ops, NULL);
+ if (IS_ERR(sata_phy->phy)) {
+ clk_disable_unprepare(sata_phy->phyclk);
+ dev_err(dev, "failed to create PHY\n");
+ return PTR_ERR(sata_phy->phy);
+ }
+
+ phy_set_drvdata(sata_phy->phy, sata_phy);
+
+ phy_provider = devm_of_phy_provider_register(dev,
+ of_phy_simple_xlate);
+ if (IS_ERR(phy_provider)) {
+ clk_disable_unprepare(sata_phy->phyclk);
+ return PTR_ERR(phy_provider);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id exynos_sata_phy_of_match[] = {
+ { .compatible = "samsung,exynos5250-sata-phy" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_sata_phy_of_match);
+
+static struct platform_driver exynos_sata_phy_driver = {
+ .probe = exynos_sata_phy_probe,
+ .driver = {
+ .of_match_table = exynos_sata_phy_of_match,
+ .name = "samsung,sata-phy",
+ .owner = THIS_MODULE,
+ }
+};
+module_platform_driver(exynos_sata_phy_driver);
+
+MODULE_DESCRIPTION("Samsung SerDes PHY driver");
+MODULE_LICENSE("GPL V2");
+MODULE_AUTHOR("Girish K S <ks.giri@samsung.com>");
+MODULE_AUTHOR("Yuvaraj C D <yuvaraj.cd@samsung.com>");
--
1.7.10.4
^ permalink raw reply related
* [PATCH V8 2/2] ARM: dts: Enable ahci sata and sata phy
From: Yuvaraj Kumar C D @ 2014-02-24 13:32 UTC (permalink / raw)
To: kishon, kgene.kim, linux-kernel, linux-arm-kernel, devicetree,
linux-doc
Cc: grant.likely, rob.herring, swarren, mark.rutland,
Yuvaraj Kumar C D
In-Reply-To: <1393248775-3283-1-git-send-email-yuvaraj.cd@samsung.com>
This patch adds dt entry for ahci sata controller and its
corresponding phy controller.phy node has been added w.r.t
new generic phy framework.
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
---
Changes since V7:syscon-phandle name updated.
Changes since V6:none
Changes since V5:none
Changes since V4:
1.Used the new phandle "sata_phy_i2c" in the DT entry.
2.Updated binding document.
Changes since V3:
1.Moved the binding info to the /bindings/phy/
Changes since V2:
1.Used syscon interface to PMU handling.
2.Changed "sata-phy-i2c" to "exynos-sataphy-i2c".
Changes since V1:
1.Minor changes to node name convention.
2.Updated binding document.
.../devicetree/bindings/ata/exynos-sata-phy.txt | 14 --------
.../devicetree/bindings/ata/exynos-sata.txt | 25 +++++++++-----
.../devicetree/bindings/phy/samsung-phy.txt | 36 ++++++++++++++++++++
arch/arm/boot/dts/exynos5250-arndale.dts | 11 ++++++
arch/arm/boot/dts/exynos5250-smdk5250.dts | 8 ++---
arch/arm/boot/dts/exynos5250.dtsi | 17 ++++++---
6 files changed, 78 insertions(+), 33 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
deleted file mode 100644
index 37824fa..0000000
--- a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* Samsung SATA PHY Controller
-
-SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
-Each SATA PHY controller should have its own node.
-
-Required properties:
-- compatible : compatible list, contains "samsung,exynos5-sata-phy"
-- reg : <registers mapping>
-
-Example:
- sata@ffe07000 {
- compatible = "samsung,exynos5-sata-phy";
- reg = <0xffe07000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt b/Documentation/devicetree/bindings/ata/exynos-sata.txt
index 0849f10..b2adb1f 100644
--- a/Documentation/devicetree/bindings/ata/exynos-sata.txt
+++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt
@@ -4,14 +4,21 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
-- compatible : compatible list, contains "samsung,exynos5-sata"
-- interrupts : <interrupt mapping for SATA IRQ>
-- reg : <registers mapping>
-- samsung,sata-freq : <frequency in MHz>
+- compatible : compatible list, contains "samsung,exynos5-sata"
+- interrupts : <interrupt mapping for SATA IRQ>
+- reg : <registers mapping>
+- samsung,sata-freq : <frequency in MHz>
+- phys : as mentioned in phy-bindings.txt
+- phy-names : as mentioned in phy-bindings.txt
Example:
- sata@ffe08000 {
- compatible = "samsung,exynos5-sata";
- reg = <0xffe08000 0x1000>;
- interrupts = <115>;
- };
+ sata@122f0000 {
+ compatible = "snps,dwc-ahci";
+ samsung,sata-freq = <66>;
+ reg = <0x122f0000 0x1ff>;
+ interrupts = <0 115 0>;
+ clocks = <&clock 277>, <&clock 143>;
+ clock-names = "sata", "sclk_sata";
+ phys = <&sata_phy>;
+ phy-names = "sata-phy";
+ };
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..a937f75 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,39 @@ Required properties:
- compatible : should be "samsung,exynos5250-dp-video-phy";
- reg : offset and length of the Display Port PHY register set;
- #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung SATA PHY Controller
+---------------------------
+
+SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
+Each SATA PHY controller should have its own node.
+
+Required properties:
+- compatible : compatible list, contains "samsung,exynos5250-sata-phy"
+- reg : offset and length of the SATA PHY register set;
+- #phy-cells : from the generic phy bindings;
+
+Example:
+ sata_phy: sata-phy@12170000 {
+ compatible = "samsung,exynos5250-sata-phy";
+ reg = <0x12170000 0x1ff>;
+ clocks = <&clock 287>;
+ clock-names = "sata_phyctrl";
+ #phy-cells = <0>;
+ samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>;
+ samsung,syscon-phandle = <&pmu_syscon>;
+ };
+
+Device-Tree bindings for sataphy i2c client driver
+--------------------------------------------------
+
+Required properties:
+compatible: Should be "samsung,exynos-sataphy-i2c"
+- reg: I2C address of the sataphy i2c device.
+
+Example:
+
+ sata_phy_i2c:sata-phy@38 {
+ compatible = "samsung,exynos-sataphy-i2c";
+ reg = <0x38>;
+ };
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
index 457112d..e0245a3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -371,6 +371,17 @@
};
};
+ i2c@121D0000 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <40000>;
+ samsung,i2c-slave-addr = <0x38>;
+
+ sata_phy_i2c:sata-phy@38 {
+ compatible = "samsung,exynos-sataphy-i2c";
+ reg = <0x38>;
+ };
+ };
+
mmc_0: mmc@12200000 {
status = "okay";
num-slots = <1>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 3e69837..e52eed8 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -96,16 +96,12 @@
samsung,i2c-slave-addr = <0x38>;
status = "okay";
- sata-phy {
- compatible = "samsung,sata-phy";
+ sata_phy_i2c:sata-phy@38 {
+ compatible = "samsung,exynos-sataphy-i2c";
reg = <0x38>;
};
};
- sata@122F0000 {
- samsung,sata-freq = <66>;
- };
-
i2c@12C80000 {
samsung,i2c-sda-delay = <100>;
samsung,i2c-max-bus-freq = <66000>;
diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index a76a189..8544199 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -46,6 +46,7 @@
i2c6 = &i2c_6;
i2c7 = &i2c_7;
i2c8 = &i2c_8;
+ i2c9 = &i2c_9;
pinctrl0 = &pinctrl_0;
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
@@ -233,16 +234,24 @@
};
sata@122F0000 {
- compatible = "samsung,exynos5-sata-ahci";
+ compatible = "snps,dwc-ahci";
+ samsung,sata-freq = <66>;
reg = <0x122F0000 0x1ff>;
interrupts = <0 115 0>;
clocks = <&clock 277>, <&clock 143>;
clock-names = "sata", "sclk_sata";
+ phys = <&sata_phy>;
+ phy-names = "sata-phy";
};
- sata-phy@12170000 {
- compatible = "samsung,exynos5-sata-phy";
+ sata_phy: sata-phy@12170000 {
+ compatible = "samsung,exynos5250-sata-phy";
reg = <0x12170000 0x1ff>;
+ clocks = <&clock 287>;
+ clock-names = "sata_phyctrl";
+ #phy-cells = <0>;
+ samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>;
+ samsung,syscon-phandle = <&pmu_system_controller>;
};
i2c_0: i2c@12C60000 {
@@ -360,7 +369,7 @@
status = "disabled";
};
- i2c@121D0000 {
+ i2c_9: i2c@121D0000 {
compatible = "samsung,exynos5-sata-phy-i2c";
reg = <0x121D0000 0x100>;
#address-cells = <1>;
--
1.7.10.4
^ permalink raw reply related
* Re: SPDX-License-Identifier
From: Theodore Ts'o @ 2014-02-24 13:41 UTC (permalink / raw)
To: Michal Simek
Cc: Greg Kroah-Hartman, Felipe Balbi, Subbaraya Sundeep Bhatta,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Subbaraya Sundeep Bhatta,
devicetree-u79uwXL29TY76Z2rM5mHXA, Wolfgang Denk
In-Reply-To: <530B1B25.5090601-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
On Mon, Feb 24, 2014 at 11:12:53AM +0100, Michal Simek wrote:
> > But of course, I'm not a lawyer, and if your company has is paying for
> > the development of the driver, the Golden Rule applies (he who has the
> > Gold, makes the Rules), and each of our respective corporate lawyers
> > may have different opinions about what might happen if the question
> > was ever to be adjudicated in court.
>
> Aren't all these points already answered by SPDX project?
> I believe that they should know how this should be handled properly.
The SPDX can not give legal advice; not to you, and not to your
company. One lawyer might believe that
/*
* SPDX-License-Identifier: GPL-2.0
*/
Might be sufficient. Others might believe you need to do:
/*
* Copyright Ty Coon, 2012.
*
* SPDX-License-Identifier: GPL-2.0
*/
Still others might believe you need at the very least:
/*
* Copyright Ty Coon, 2012.
*
* All Rights Reserved.
*
* SPDX-License-Identifier: GPL-2.0
*/
As far as I know, there is no case law on point about whether or not
SPDX-License-Identifier has legal significance, or whether the court
would consider that to be a valid copyright permission statement. So
any "answers" made by any lawyer would be guesses. Of course, an
guess by a lawyer which is retained by *you* or your company and fully
informed with the unique parameters of your situation would constitute
legal advice. Anything else, including anything any of us could say
on this mailing list, would be biovating. :-)
Cheers,
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V8 1/2] PHY: Exynos: Add Exynos5250 SATA PHY driver
From: Kishon Vijay Abraham I @ 2014-02-24 13:56 UTC (permalink / raw)
To: Yuvaraj Kumar C D, kgene.kim, linux-kernel, linux-arm-kernel,
devicetree, linux-doc
Cc: mark.rutland, Yuvaraj Kumar C D, swarren, Girish K S,
Vasanth Ananthan, rob.herring, grant.likely
In-Reply-To: <1393248775-3283-2-git-send-email-yuvaraj.cd@samsung.com>
Hi,
On Monday 24 February 2014 07:02 PM, Yuvaraj Kumar C D wrote:
> This patch adds the SATA PHY driver for Exynos5250.Exynos5250 SATA
> PHY comprises of CMU and TRSV blocks which are of I2C register Map.
> So this patch also adds a i2c client driver, which is used configure
We no longer have i2c client driver here.
> the CMU and TRSV block of exynos5250 SATA PHY.
>
> This patch incorporates the generic PHY framework to deal with SATA
> PHY.
It should be rephrased to have *uses* generic PHY framework. However I feel we
can do away with this line.
>
> This patch depends on the below patch for the sata functionality
> [1].ata: ahci_platform: Manage SATA PHY
> by Roger Quadros <rogerq@ti.com>
hasn't this patch merged yet?
Thanks
Kishon
^ permalink raw reply
* Re: SPDX-License-Identifier
From: Michal Simek @ 2014-02-24 14:03 UTC (permalink / raw)
To: Theodore Ts'o, Greg Kroah-Hartman, Felipe Balbi,
Subbaraya Sundeep Bhatta, linux-usb, linux-kernel,
Subbaraya Sundeep Bhatta, devicetree, Wolfgang Denk
In-Reply-To: <20140224134150.GB25357@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]
On 02/24/2014 02:41 PM, Theodore Ts'o wrote:
> On Mon, Feb 24, 2014 at 11:12:53AM +0100, Michal Simek wrote:
>>> But of course, I'm not a lawyer, and if your company has is paying for
>>> the development of the driver, the Golden Rule applies (he who has the
>>> Gold, makes the Rules), and each of our respective corporate lawyers
>>> may have different opinions about what might happen if the question
>>> was ever to be adjudicated in court.
>>
>> Aren't all these points already answered by SPDX project?
>> I believe that they should know how this should be handled properly.
>
> The SPDX can not give legal advice; not to you, and not to your
> company. One lawyer might believe that
>
> /*
> * SPDX-License-Identifier: GPL-2.0
> */
>
> Might be sufficient. Others might believe you need to do:
>
> /*
> * Copyright Ty Coon, 2012.
> *
> * SPDX-License-Identifier: GPL-2.0
> */
>
> Still others might believe you need at the very least:
>
> /*
> * Copyright Ty Coon, 2012.
> *
> * All Rights Reserved.
> *
> * SPDX-License-Identifier: GPL-2.0
> */
Aren't these differences already present in the header?
>
> As far as I know, there is no case law on point about whether or not
> SPDX-License-Identifier has legal significance, or whether the court
> would consider that to be a valid copyright permission statement. So
> any "answers" made by any lawyer would be guesses. Of course, an
> guess by a lawyer which is retained by *you* or your company and fully
> informed with the unique parameters of your situation would constitute
> legal advice. Anything else, including anything any of us could say
> on this mailing list, would be biovating. :-)
I think make sense to wait for Wolfgang about his experience because
I believe he has considered it before u-boot change.
BTW: Isn't this a good topic for kernel-summit? :-)
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: STi reset controller support
From: srinivas kandagatla @ 2014-02-24 14:03 UTC (permalink / raw)
To: Philipp Zabel, Maxime Coquelin
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, linux-doc, linux-kernel, stephen.gallimore,
Grant Likely, Rob Herring, Arnd Bergmann, Rob Landley, Kumar Gala,
Olof Johansson, linux-arm-kernel
In-Reply-To: <1393237988.3091.14.camel@pizza.hi.pengutronix.de>
Thanks Philipp for your comments,
On 24/02/14 10:33, Philipp Zabel wrote:
>> > Did Srini's explanations convinced you?
>> >
>> > If so, could you queue the series for v3.15?
> to be honest, I'm not comfortable with this explanation. If the
> "powerdown" bits only gate the clocks to those modules, calling it a
> reset control is clearly the wrong abstraction. If that is the case,
> couldn't you handle those bits via the clock framework?
I just had a re-look at the IPs specs for more information on where
these power-down signals are actually terminating on the IP side.
For example: ST-Synopsis Ethernet GMAC IP has two pins
power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
the software to either put the IP in powerdown or bring it out of
powerdown state.
The IP itself drives power_down_ack to indicate when the power down
request is successfully finished. For power_down/power_up request the IP
will change the internal state accordingly including powering up/down
its internal blocks and/or clock gating.
> If on the other hand these powerdown bits also trigger reset machinery,
> such that asserting and deasserting that bit will change the module's
> internal state, I could be convinced to queue them like this.
This is true with ST IPs, these lines change the state of the IP as
described above. Reset framework seems to fits in very well with this
behavior rather than power-domains or clock framework.
Thanks,
srini
^ permalink raw reply
* Re: [PATCH v11] gpio: add a driver for the Synopsys DesignWare APB GPIO block
From: delicious quinoa @ 2014-02-24 14:20 UTC (permalink / raw)
To: Linus Walleij
Cc: Linus Walleij, linux-kernel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org, Jamie Iles,
devicetree@vger.kernel.org, Mark Rutland, Grant Likely,
Rob Herring, Steffen Trumtrar, Sebastian Hesselbarth,
Heiko Stuebner, Alan Tull, Dinh Nguyen, Yves Vandervennet
In-Reply-To: <CACRpkdbkcuByEh_pasBoAQpXwa479iTuWLPPQW1TLRapbqjE7Q@mail.gmail.com>
On Mon, Feb 24, 2014 at 6:20 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Feb 12, 2014 at 5:17 PM, delicious quinoa
> <delicious.quinoa@gmail.com> wrote:
>
>> I am wondering about the change in usage of
>> irq_find_mapping/irq_create_mapping. It seems like all the GPIO
>> drivers that use irq domains do it the way I was doing it
>
> It is a well known problems that the kernel contain many bad
> examples. When in doubt ask for a good example to be provided.
>
> In gpio-omap.c you will find that this is done in the probe()
> path.
>
>> (that's
>> where I got the idea in the first place): irq_create_mapping is used
>> in the to_irq() function. I guess this is a general direction all the
>> other drivers will be encouraged to go in also?
>
> Yes. The reason is that it should be possible to reques an IRQ
> from an irqchip no matter whether the gpio_to_irq() function
> was called first, as the APIs are orthogonal.
>
> Yours,
> Linus Walleij
Hi Linus,
Thanks, I made these changes and can see them working for me.
The thing that is currently holding me up is that the DesignWare IP
can be configured to have one irq exiting for the many gpios on port A
or one gpio exiting for each gpio. I am trying to figure out how to
support both cases with the simplest code. Currently support works
for the one irq case.
Alan
^ permalink raw reply
* Re: [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Kishon Vijay Abraham I @ 2014-02-24 14:24 UTC (permalink / raw)
To: Roger Quadros, Heikki Krogerus, Felipe Balbi
Cc: devicetree, george.cherian, linux-doc, linux-usb, linux-kernel,
linux-omap, linux-arm-kernel
In-Reply-To: <530B277A.3030900@ti.com>
Hi,
On Monday 24 February 2014 04:35 PM, Roger Quadros wrote:
> On 02/24/2014 11:51 AM, Kishon Vijay Abraham I wrote:
>> Hi Roger,
>>
>> On Friday 21 February 2014 05:59 PM, Roger Quadros wrote:
>>> On 02/21/2014 02:25 PM, Kishon Vijay Abraham I wrote:
>>>> Hi Roger,
>>>>
>>>> On Wednesday 19 February 2014 06:07 PM, Roger Quadros wrote:
>>>>> Hi,
>>>>>
>>>>> On 02/12/2014 11:46 AM, Kishon Vijay Abraham I wrote:
>>>>>> On Wednesday 29 January 2014 08:17 PM, Heikki Krogerus wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tue, Jan 28, 2014 at 10:30:36AM -0600, Felipe Balbi wrote:
>>>>>>>> On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote:
>>>>>>>>> On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote:
>>>>>>>>> For the controller drivers the PHYs are just a resource like any
>>>>>>>>> other. The controller drivers can't have any responsibility of
>>>>>>>>> them. They should not care if PHY drivers are available for them or
>>>>>>>>> not, or even if the PHY framework is available or not.
>>>>>>>>
>>>>>>>> huh? If memory isn't available you don't continue probing, right ? If
>>>>>>>> your IORESOURCE_MEM is missing, you also don't continue probing, if your
>>>>>>>> IRQ line is missing, you bail too. Those are also nothing but resources
>>>>>>>> to the driver, what you're asking here is to treat PHY as a _different_
>>>>>>>> resource; which might be fine, but we need to make sure we don't
>>>>>>>> continue probing when a PHY is missing in a platform that certainly
>>>>>>>> needs a PHY.
>>>>>>>
>>>>>>> Yes, true. In my head I was comparing the PHY only to resources like
>>>>>>> gpios, clocks, dma channels, etc. that are often optional to the
>>>>>>> drivers.
>>>>>>>
>>>>>>>>>>>> But I really want to see the argument against using no-op. As far as I
>>>>>>>>>>>> could see, everybody needs a PHY driver one way or another, some
>>>>>>>>>>>> platforms just haven't sent any PHY driver upstream and have their own
>>>>>>>>>>>> hacked up solution to avoid using the PHY layer.
>>>>>>>>>>>
>>>>>>>>>>> Not true in our case. Platforms using Intel's SoCs and chip sets may
>>>>>>>>>>> or may not have controllable USB PHY. Quite often they don't. The
>>>>>>>>>>> Baytrails have usually ULPI PHY for USB2, but that does not mean they
>>>>>>>>>>> provide any vendor specific functions or any need for a driver in any
>>>>>>>>>>> case.
>>>>>>>>>>
>>>>>>>>>> that's different from what I heard.
>>>>>>>>>
>>>>>>>>> I don't know where you got that impression, but it's not true. The
>>>>>>>>> Baytrail SoCs for example don't have internal USB PHYs, which means
>>>>>>>>> the manufacturers using it can select what they want. So we have
>>>>>>>>> boards where PHY driver(s) is needed and boards where it isn't.
>>>>>>>>
>>>>>>>> alright, that explains it ;-) So you have external USB2 and USB3 PHYs ?
>>>>>>>> You have an external PIPE3 interface ? That's quite an achievement,
>>>>>>>> kudos to your HW designers. Getting timing closure on PIPE3 is a
>>>>>>>> difficult task.
>>>>>>>
>>>>>>> No, only the USB2 PHY is external. I'm giving you wrong information,
>>>>>>> I'm sorry about that. Need to concentrate on what I'm writing.
>>>>>>>
>>>>>>> <snip>
>>>>>>>
>>>>>>>>> This is really good to get. We have some projects where we are dealing
>>>>>>>>> with more embedded environments, like IVI, where the kernel should be
>>>>>>>>> stripped of everything useless. Since the PHYs are autonomous, we
>>>>>>>>> should be able to disable the PHY libraries/frameworks.
>>>>>>>>
>>>>>>>> hmmm, in that case it's a lot easier to treat. We can use
>>>>>>>> ERR_PTR(-ENXIO) as an indication that the framework is disabled, or
>>>>>>>> something like that.
>>>>>>>>
>>>>>>>> The difficult is really reliably supporting e.g. OMAP5 (which won't work
>>>>>>>> without a PHY) and your BayTrail with autonomous PHYs. What can we use
>>>>>>>> as an indication ?
>>>>>>>
>>>>>>> OMAP has it's own glue driver, so shouldn't it depend on the PHY
>>>>>>> layer?
>>>>>>
>>>>>> right, but the PHY is connected to the dwc3 core and not to the glue.
>>>>>>>
>>>>>>>> I mean, I need to know that a particular platform depends on a PHY
>>>>>>>> driver before I decide to return -EPROBE_DEFER or just assume the PHY
>>>>>>>> isn't needed ;-)
>>>>>>>
>>>>>>> I don't think dwc3 (core) should care about that. The PHY layer needs
>>>>>>> to tell us that. If the PHY driver that the platform depends is not
>>>>>>> available yet, the PHY layer returns -EPROBE_DEFER and dwc3 ends up
>>>>>>> returning -EPROBE_DEFER.
>>>>>>
>>>>>> I don't think the PHY layer can 'reliably' tell if PHY driver is available or
>>>>>> not. Consider when the phy_provider_register fails, there is no way to know if
>>>>>> PHY driver is available or not. There are a few cases where PHY layer returns
>>>>>> -EPROBE_DEFER but none of them can tell for sure that PHY driver is either
>>>>>> available and failed or not available at all. It would be best for us to leave
>>>>>> that to the platforms if we want to be sure if the platform needs a PHY or not.
>>>>>>
>>>>>
>>>>> Just to summarize this thread on what we need
>>>>
>>>> Thanks for summarizing.
>>>>>
>>>>> 1) dwc3 core shouldn't worry about platform specific stuff i.e. PHY needed or not.
>>>>> It should be as generic as possible.
>>>>>
>>>>> 2) dwc3 core should continue probe even if PHY layer is not enabled, as not all platforms need it.
>>>>>
>>>>> 3) dwc3 core should continue probe if PHY device is not available. (-ENODEV?)
>>>>>
>>>>> 4) dwc3 core should error out on any error condition if PHY device is available and caused some error,
>>>>> e.g. init error.
>>>>>
>>>>> 5) dwc3 core should return EPROBE_DEFER if PHY device is available but device driver is not yet loaded.
>>>>>
>>>>> 6) platform glue should do the necessary sanity checks for availability of all resources like PHY device, PHY layer, etc, before populating the dwc3 device. e.g. in OMAP5 case we could check if both usb2 and usb3 PHY
>>>>> nodes are available in the DT and PHY layer is enabled, from dwc3-omap.c? In J6 case we could check that at least usb2 phy node is there for the High-Speed only controller, and so on.
>>>>
>>>> The PHY is connected to the dwc3 core. So I'm not sure if we should be doing
>>>> checks for PHY in the glue layer.
>>>
>>> Sorry, I didn't get you. My reasoning was that since OMAP platform has this strict requirement of requiring
>>> explicit PHY control in order to work, we must do the sanity checks in OMAP specific code and not in the dwc3 core code. It has nothing to do with how hardware is laid out.
>>
>> What kind of sanity check do you think can be done in OMAP code? We don't use
>> any of the PHY API's in glue code. If we add the same PHY APIs in glue code it
>> will be duplication of the same code without much value besides breaking the
>> design guideline of the software to be modelled similar to hardware.
>>
>
> I wasn't saying about using PHY APIs in glue code, but just doing the basic sanity checks like
> presence of PHY layer, the required USB PHY DT nodes and the required drivers for the platform.
hmm.. instead of doing sanity checks we can just select them in Kconfig like
what I suggested before no? We could check if there is a phandle on the child
dwc3 node though.
Thanks
Kishon
^ permalink raw reply
* Re: SPDX-License-Identifier
From: Greg Kroah-Hartman @ 2014-02-24 14:26 UTC (permalink / raw)
To: Michal Simek
Cc: Theodore Ts'o, Felipe Balbi, Subbaraya Sundeep Bhatta,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Subbaraya Sundeep Bhatta,
devicetree-u79uwXL29TY76Z2rM5mHXA, Wolfgang Denk
In-Reply-To: <530B512D.8090308-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
On Mon, Feb 24, 2014 at 03:03:25PM +0100, Michal Simek wrote:
>
> BTW: Isn't this a good topic for kernel-summit? :-)
No, lawyers don't go to the summit, developers do.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support
From: Nishanth Menon @ 2014-02-24 14:38 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree, Mike Turquette, linux-doc, Viresh Kumar, linux-pm,
Rafael J. Wysocki, linux-kernel, cpufreq, MyungJoo Ham,
linux-omap, linux-arm-kernel
In-Reply-To: <20140224015826.GU25940@sirena.org.uk>
On 02/23/2014 07:58 PM, Mark Brown wrote:
> On Tue, Feb 18, 2014 at 02:32:20PM -0600, Nishanth Menon wrote:
>
>> The current regulator model provides the basic building blocks for the
>> transitions, however SoC drivers specific to each of these devices, be
>> it cpufreq/devfreq have to replicate the logic for functionality.
>
>> To simply the logic, we can hence introduce a layer that takes care
>> of the mundane transition logic, registration mechanisms to provide
>> the "user drivers" such as cpufreq/devfreq a generic interface, whose
>> details are abstracted by the device tree description for the SoC on
>> which the driver operates on.
>
> This doesn't really provide a picture of what the generic interface
> that's being offered is and...
I should have probably picked up part of the cover letter[1] and
elaborated further in the commit message here.
Intent here is to allow drivers such as cpufreq-cpu0 to be reused on
platforms such as TI's OMAP derivatives, and other SoCs which differ
only by the sequence involved in voltage scale operations. So, this
patch provides a framework for registering the underlying
implementation of the SoC specific voltage change methodology.
Overall the sequence takes place after this patch is as follows:
a) voltage domain drivers such as those of TI or others register with
voltage domain with devm_voltdm_register.
b) cpufreq-cpu0/devfreq drivers:
of_pm_voltdm_notifier_register(introduced as part of patch #1) to
register notifiers around clk of interest. This request is linked to
the specific voltage domain using phandle in device tree.
c) when cpufreq-cpu0/devfreq does a clk_set_rate, the common clock
framework triggers notifiers in voltage domain core which in turn,
invokes the corresponding handlers for the voltage domain driver
ensuring the right dvfs sequence specific to the SoC is triggered.
With this patch, the logic for a SoC specific voltage domain
intricacies can now be abstracted out to the voltage domain layer.
This allows reuse of the logic by multiple drivers such as
devfreq/cpufreq and allows these to remain consistent with very
minimal SoC(if any at all) specific implementations in them.
Among the other obvious alternatives to this approach are:
a) To duplicate the logic multiple times for various drivers such as
devfreq/cpufreq and try to ensure the logic sequences are proper.
basically, create cpufreq-abb-omap, cpufreq-avs-omap,
devfreq-abb-omap, devfreq-avs-omap etc..
b) introduce a specific API for voltage change (something like
pm_dev_scale_opp_frequency or the equivalent).
>
>> drivers/power/voltdm/Kconfig | 5 +
>> drivers/power/voltdm/Makefile | 3 +
>> drivers/power/voltdm/core.c | 347 +++++++++++++++++++++++--
>> drivers/power/voltdm/voltage_domain_private.h | 86 ++++++
>> 4 files changed, 424 insertions(+), 17 deletions(-)
>
> ...the diffstat doesn't make it obvious what the external interface is
> either. It would be much easier to review this with a clearer picture
> of what it's aiming to implement.
The drivers such as cpufreq/devfreq has the same interface introduced
by patch #1 in this series of_pm_voltdm_notifier_register/unregister
which is exposed by include/linux/pm_voltage_domain.h
Underlying implementation of the SoC specific voltage change
methodology can now be isolated by voltage domain driver using
voltage_domain_private.h and services provided by core.c
>
>> + voltdm_np = of_parse_phandle(np, prop_name, 0);
>> + if (voltdm_np) {
>> + ret = of_parse_phandle_with_args(np, prop_name, "#voltdm-cells",
>> + 0, args);
>> + if (ret)
>> + return ERR_PTR(ret);
>
> There seems to be some DT stuff going on here, is the interface DT only?
>
yes. i will make that clear in the documentation.
[1] http://marc.info/?l=linux-kernel&m=139275560531711&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCHv1 1/6] HSI: add Device Tree support for HSI clients
From: Mark Rutland @ 2014-02-24 15:09 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Linus Walleij, Shubhrajyoti Datta,
Carlos Chinea, Tony Lindgren, grant.likely@linaro.org,
rob.herring@calxeda.com, Pawel Moll, Stephen Warren, Ian Campbell,
Rob Landley, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
Pali Rohár,
Ивайло Димитров,
Joni Lapilainen, Aaro Koskinen
In-Reply-To: <1393199401-27197-2-git-send-email-sre@debian.org>
On Sun, Feb 23, 2014 at 11:49:56PM +0000, Sebastian Reichel wrote:
> Add new method hsi_add_clients_from_dt, which can be used
> to initialize HSI clients from a device tree node.
>
> The patch also documents the DT binding for trivial HSI
> clients.
>
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
> .../devicetree/bindings/hsi/trivial-devices.txt | 36 +++++++++++
> drivers/hsi/hsi.c | 70 +++++++++++++++++++++-
> include/dt-bindings/hsi/hsi.h | 17 ++++++
> include/linux/hsi/hsi.h | 2 +
> 4 files changed, 124 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/hsi/trivial-devices.txt
> create mode 100644 include/dt-bindings/hsi/hsi.h
It would be nice if we had a general HSI binding document that explains
what HSI is and how HSI bus devices and clients are expected too look.
Does HSI have an addressing scheme, or does each port have a single
device?
>
> diff --git a/Documentation/devicetree/bindings/hsi/trivial-devices.txt b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
> new file mode 100644
> index 0000000..1ace14a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hsi/trivial-devices.txt
> @@ -0,0 +1,36 @@
> +This is a list of trivial hsi client devices that have simple
> +device tree bindings, consisting only of a compatible field
> +and the optional hsi configuration.
> +
> +If a device needs more specific bindings, such as properties to
> +describe some aspect of it, there needs to be a specific binding
> +document for it just like any other devices.
Might this make more sense as a hsi-clients binding doc? I assume these
properties could be applied to non-trivial devices?
> +
> +Optional HSI configuration properties:
> +
> +- hsi,mode Bit transmission mode (STREAM or FRAME)
> + The first value is used for RX and the second one for
> + TX configuration. If only one value is provided it will
> + be used for RX and TX.
> + The assignments may be found in header file
> + <dt-bindings/hsi/hsi.h>.
Why not have hsi,rx-mode and hsi,tx-mode? I'll certainly get confused as
to which cell is tx and which is rx with the current binding.
Having separate tx-* and rx-* versions of the remaining properties would
be good too.
I note that the defines are called HSI_MODE_STREAM and HSI_MODE_FRAME,
not STREAM and FRAME as the binding document implies. Please refer to
exact names.
It may make more sense to use a string here and for the other
properties. They're easier for humans to read, and they survive
decompilation (so you get _much_ better error messages).
> +- hsi,channels Number of channels to use [1..16]
> + The first value is used for RX and the second one for
> + TX configuration. If only one value is provided it will
> + be used for RX and TX.
> +- hsi,speed Max bit transmission speed (Kbit/s)
> + The first value is used for RX and the second one for
> + TX configuration. If only one value is provided it will
> + be used for RX and TX.
> +- hsi,flow RX flow type (SYNCHRONIZED or PIPELINE)
> + The assignments may be found in header file
> + <dt-bindings/hsi/hsi.h>.
> +- hsi,arb_mode Arbitration mode for TX frame (Round robin, priority)
> + The assignments may be found in header file
> + <dt-bindings/hsi/hsi.h>.
s/_/-/ in property names please.
> +
> +This is the list of trivial client devices:
> +
> +Compatible Description
> +========== =============
> +hsi-char HSI character device
What exactly is a HSI character device?
This seems more like a Linux abstraction than a real class of device.
Cheers,
Mark.
^ permalink raw reply
* Re: [PATCHv1 3/6] HSI: hsi-char: add Device Tree support
From: Mark Rutland @ 2014-02-24 15:13 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Linus Walleij, Shubhrajyoti Datta,
Carlos Chinea, Tony Lindgren, grant.likely@linaro.org,
rob.herring@calxeda.com, Pawel Moll, Stephen Warren, Ian Campbell,
Rob Landley, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
Pali Rohár,
Ивайло Димитров,
Joni Lapilainen, Aaro Koskinen
In-Reply-To: <1393199401-27197-4-git-send-email-sre@debian.org>
On Sun, Feb 23, 2014 at 11:49:58PM +0000, Sebastian Reichel wrote:
> Add of_match_table to hsi_char driver, so that it can
> be referenced from Device Tree.
>
> Signed-off-by: Sebastian Reichel <sre@debian.org>
> ---
> drivers/hsi/clients/hsi_char.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/hsi/clients/hsi_char.c b/drivers/hsi/clients/hsi_char.c
> index e61e5f9..7f64bed 100644
> --- a/drivers/hsi/clients/hsi_char.c
> +++ b/drivers/hsi/clients/hsi_char.c
> @@ -42,6 +42,7 @@
> #include <linux/stat.h>
> #include <linux/hsi/hsi.h>
> #include <linux/hsi/hsi_char.h>
> +#include <linux/of_device.h>
>
> #define HSC_DEVS 16 /* Num of channels */
> #define HSC_MSGS 4
> @@ -758,12 +759,22 @@ static int hsc_remove(struct device *dev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id hsi_char_of_match[] = {
> + { .compatible = "ssi-char", },
This string is undocumented.
> + { .compatible = "hsi-char", },
I'm not sure either string makes sense though; this feels like a binding
for the sake of the driver rather than describing the device and
allowing the driver to pick it up if it makes sense to do so.
What exactly is a "ssi-char" device or a "hsi-char" device?
Cheers,
Mark.
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: STi reset controller support
From: Philipp Zabel @ 2014-02-24 15:16 UTC (permalink / raw)
To: srinivas kandagatla
Cc: Maxime Coquelin, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Russell King, kernel-F5mvAk5X5gdBDgjK7y7TUQ, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stephen.gallimore-qxv4g6HH51o, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <530B514A.4070209-qxv4g6HH51o@public.gmane.org>
Hi Srinivas,
Am Montag, den 24.02.2014, 14:03 +0000 schrieb srinivas kandagatla:
> Thanks Philipp for your comments,
>
> On 24/02/14 10:33, Philipp Zabel wrote:
> >> > Did Srini's explanations convinced you?
> >> >
> >> > If so, could you queue the series for v3.15?
> > to be honest, I'm not comfortable with this explanation. If the
> > "powerdown" bits only gate the clocks to those modules, calling it a
> > reset control is clearly the wrong abstraction. If that is the case,
> > couldn't you handle those bits via the clock framework?
> I just had a re-look at the IPs specs for more information on where
> these power-down signals are actually terminating on the IP side.
>
> For example: ST-Synopsis Ethernet GMAC IP has two pins
> power_down_req[IN] and power_down_ack[OUT]. power_down_req is used by
> the software to either put the IP in powerdown or bring it out of
> powerdown state.
Now I'm a bit confused. There is no mention of GMAC in your patches,
and for ETH[01] they contain only the SOFTRESET bits. I have no issue
with the SOFTRESETs.
> The IP itself drives power_down_ack to indicate when the power down
> request is successfully finished. For power_down/power_up request the IP
> will change the internal state accordingly including powering up/down
> its internal blocks and/or clock gating.
>
> > If on the other hand these powerdown bits also trigger reset machinery,
> > such that asserting and deasserting that bit will change the module's
> > internal state, I could be convinced to queue them like this.
> This is true with ST IPs, these lines change the state of the IP as
> described above. Reset framework seems to fits in very well with this
> behavior rather than power-domains or clock framework.
If you put the IP in power down when it is idle, and then power it up
again, will the IP registers have kept their previous state?
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] arm/xen: Don't use xen DMA ops when the device is protected by an IOMMU
From: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r @ 2014-02-24 15:16 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Ian Campbell, Julien Grall, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.DEB.2.02.1402241214570.4471-7Z66fg9igcxYtxbxJUhB2Dgeux46jI+i@public.gmane.org>
On Mon, Feb 24, 2014 at 12:19:11PM +0000, Stefano Stabellini wrote:
> CC'ing Greg.
>
> On Thu, 20 Feb 2014, Ian Campbell wrote:
> > On Thu, 2014-02-20 at 16:21 +0000, Julien Grall wrote:
> > > Only Xen is able to know if a device can safely avoid to use xen-swiotlb.
> > > This patch introduce a new property "protected-devices" for the hypervisor
> > > node which list device which the IOMMU are been correctly programmed by Xen.
> > >
> > > During Linux boot, Xen specific code will create an hash table which
> > > contains all these devices. The hash table will be used in need_xen_dma_ops
> > > to check if the Xen DMA ops needs to be used for the current device.
> >
> > Is it out of the question to find a field within struct device itself to
> > store this e.g. in struct device_dma_parameters perhaps and avoid the
> > need for a hashtable lookup.
> >
> > device->iommu_group might be another option, if we can create our own
> > group?
>
> I agree that a field in struct device would be ideal.
> Greg, get_maintainer.pl points at you as main maintainer of device.h, do
> you have an opinion on this?
I need a whole lot more context here please. With a patch would be even
better so that I know exactly what you are referring to...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 4/8] Documentation: add the document for the SPI NOR framework
From: Konstantin Tokarev @ 2014-02-24 15:17 UTC (permalink / raw)
To: Huang Shijie, dwmw2@infradead.org
Cc: angus.clark@st.com, computersforpeace@gmail.com,
b44548@freescale.com, linux-doc@vger.kernel.org,
broonie@linaro.org, b18965@freescale.com,
linux-spi@vger.kernel.org, devicetree@vger.kernel.org,
linux-mtd@lists.infradead.org, pekon@ti.com, sourav.poddar@ti.com,
shawn.guo@linaro.org, lee.jones@linaro.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1393238262-8622-5-git-send-email-b32955@freescale.com>
24.02.2014, 15:26, "Huang Shijie" <b32955@freescale.com>:
> This patch adds the document for the SPI NOR framework.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
> Documentation/mtd/spi-nor.txt | 59 +++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 59 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/mtd/spi-nor.txt
>
> diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt
> new file mode 100644
> index 0000000..b9585f8
> --- /dev/null
> +++ b/Documentation/mtd/spi-nor.txt
> @@ -0,0 +1,59 @@
> + SPI NOR framework
> + ============================================
> +
> +Part I - why we need this framework?
> +-------------------------------------
> +
> +The SPI bus controller only deals with the byte stream.
> +Some controller does not works like a SPI bus controller, it works
> +like a SPI NOR controller instead, such as the Freescale's QuadSPI controller.
> +
> +The Freescale's QuadSPI controller should knows the NOR commands to
> +find the right LUT sequence. Unfortunately, the old code can not meet
> +this requirement.
should know
> +
> +Part II - How does the framework work?
> +-------------------------------------
> +
> +This framework just adds a new layer between the MTD and the SPI bus driver.
> +With this new layer, the SPI NOR controller driver does not depend on the
> +m25p80 code anymore.
> +
> + Before this framework, the layer is like:
> +
> + MTD
> + ------------------------
> + m25p80
> + ------------------------
> + SPI bus driver
> + ------------------------
> + SPI NOR chip
> +
> + After this framework, the layer is like:
> + MTD
> + ------------------------
> + SPI NOR framework
> + ------------------------
> + m25p80
> + ------------------------
> + SPI bus driver
> + ------------------------
> + SPI NOR chip
> +
> + With the SPI NOR controller driver(Freescale QuadSPI), it looks like:
> + MTD
> + ------------------------
> + SPI NOR framework
> + ------------------------
> + fsl-quadSPI
> + ------------------------
> + SPI NOR chip
> +
> +Part III - How can the drivers use the framework
> +-------------------------------------
> +
> +The main API is the spi_nor_scan(). Before you call the hook, you should
> +initialize the necessary fields for spi_nor{}.
> +Please see the drivers/mtd/spi-nor/spi-nor.c for detail.
> +Please also reference to the fsl-quadspi.c when you want to write a new driver
> +for a SPI NOR controller.
> --
> 1.7.2.rc3
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
Regards,
Konstantin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v3 0/9] imx-drm dt bindings
From: Philipp Zabel @ 2014-02-24 15:36 UTC (permalink / raw)
To: Russell King - ARM Linux, Greg Kroah-Hartman
Cc: devel, devicetree, dri-devel, kernel, Grant Likely,
linux-arm-kernel
In-Reply-To: <1392723370-4772-1-git-send-email-p.zabel@pengutronix.de>
Am Dienstag, den 18.02.2014, 12:36 +0100 schrieb Philipp Zabel:
> Hi,
>
> here is an updated and more complete version of the imx-drm DT binding
> series. These patches apply on top of Russell's second preview of the
> imx-drm cleanup series on v3.14-rc2. I have added device tree bindings
> between IPU and the encoders as documented in
> Documentation/devicetree/bindings/media/video-interfaces.txt
> and used those to determine the possible_crtcs and mux_id.
>
> The crtc cookie is replaced with a the port device tree node,
> which is unique and therefore allows to get rid of the di_id
> comparison. Storing the multiplexer input numbers in the device
> tree removes the need to know the ipu_id. This should also allow
> to replace IPU2 with LCDIF on i.MX6 Solo more easily.
>
> In v3 also connections between display interface ports and encoders are
> used to find all necessary components, so that only the display interfaces
> have to be configured in the imx-drm node. This allows to move the imx-drm
> node into the SoC level dtsi. I've also updated the existing i.MX51 and
> i.MX53 device trees this time and updated/added the devicetree binding
> documentation.
>
> Patch 2/9 adds a temporary copy of the v4l2_of parser functions. Those
> are going to be moved to some place where they can be used by drm drivers,
> eventually, so those local copies can be dropped again.
Russell has sent a pull request for the imx-drm component support series
now, and we're at v3.13-rc4 already. This patch series still applies on
top of
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git imx-drm-staging
I'd appreciate some feedback on this. Or shall I resend without the RFC?
regards
Philipp
> regards
> Philipp
>
> Lucas Stach (1):
> staging: imx-drm-core: don't request probe deferral in
> imx_drm_encoder_parse_of
>
> Philipp Zabel (8):
> staging: imx-drm: Add temporary copies of v4l2-of parsing functions
> staging: imx-drm-core: Use OF graph to find components and connections
> between encoder and crtcs
> staging: imx-drm: Document updated imx-drm device tree bindings
> staging: imx-drm: Document imx-hdmi device tree bindings
> ARM: dts: imx51: Add IPU ports and endpoints, move imx-drm node to
> dtsi
> ARM: dts: imx53: Add IPU DI ports and endpoints, move imx-drm node to
> dtsi
> ARM: dts: imx6qdl: Add IPU DI ports and endpoints, move imx-drm node
> to dtsi
> staging: imx-drm: Update TODO
>
> .../bindings/staging/imx-drm/fsl-imx-drm.txt | 48 ++++-
> .../devicetree/bindings/staging/imx-drm/hdmi.txt | 53 +++++
> .../devicetree/bindings/staging/imx-drm/ldb.txt | 20 +-
> arch/arm/boot/dts/imx51-apf51dev.dts | 11 +-
> arch/arm/boot/dts/imx51-babbage.dts | 28 ++-
> arch/arm/boot/dts/imx51.dtsi | 22 ++-
> arch/arm/boot/dts/imx53-m53evk.dts | 17 +-
> arch/arm/boot/dts/imx53-mba53.dts | 15 +-
> arch/arm/boot/dts/imx53-qsb.dts | 17 +-
> arch/arm/boot/dts/imx53.dtsi | 64 +++++-
> arch/arm/boot/dts/imx6dl.dtsi | 22 +--
> arch/arm/boot/dts/imx6q-sabresd.dts | 4 -
> arch/arm/boot/dts/imx6q.dtsi | 124 +++++++++++-
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 6 -
> arch/arm/boot/dts/imx6qdl.dtsi | 138 ++++++++++++-
> drivers/staging/imx-drm/Makefile | 2 +-
> drivers/staging/imx-drm/TODO | 5 -
> drivers/staging/imx-drm/imx-drm-core.c | 217 ++++++++++++++-------
> drivers/staging/imx-drm/imx-drm-of.c | 132 +++++++++++++
> drivers/staging/imx-drm/imx-drm.h | 11 +-
> drivers/staging/imx-drm/imx-hdmi.c | 2 +-
> drivers/staging/imx-drm/imx-ldb.c | 4 +-
> drivers/staging/imx-drm/ipuv3-crtc.c | 47 ++++-
> 23 files changed, 842 insertions(+), 167 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
> create mode 100644 drivers/staging/imx-drm/imx-drm-of.c
>
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Nicolin Chen @ 2014-02-24 15:47 UTC (permalink / raw)
To: Mark Brown
Cc: mark.rutland, devicetree, brian.austin, pawel.moll,
ijc+devicetree, linux-doc, lgirdwood, Paul.Handrigan,
linux-kernel, robh+dt, rob, galak, grant.likely, alsa-devel
In-Reply-To: <20140224113011.GE25940@sirena.org.uk>
On Mon, Feb 24, 2014 at 08:30:11PM +0900, Mark Brown wrote:
> On Mon, Feb 24, 2014 at 02:55:29PM +0800, Nicolin Chen wrote:
> > This patch adds support for the Cirrus Logic CS42888 Audio CODEC that
> > has four 24-bit A/D and eight 24-bit D/A converters.
>
> Looks generally good, some fairly small nits below.
I'll revise all of them.
Thank you.
Nicolin
----
>
> > [ CS42888 supports both I2C and SPI control ports. As initial patch,
> > this patch only adds the support for I2C. ]
>
> > 5 files changed, 795 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/sound/cs42888.txt
> > create mode 100644 sound/soc/codecs/cs42888.c
> > create mode 100644 sound/soc/codecs/cs42888.h
>
> Given that we're starting to split out separate bus drivers for the I2C
> and SPI CODECs (look at the recent submissions from Lars-Peter) it'd be
> good to start this off with a separate bus driver for I2C even if the
> SPI one is still to be done - that way the Kconfig stuff for machine
> drivers is all in place and doesn't need updating.
>
> > + - clocks : phandle to the clock source for MCLK
> > +
> > + - clock-names : must contain "mclk".
>
> These should really be lists though there's only one documented element
> so it's purely a documentation update.
>
> > + /* Disable auto-mute */
> > + regmap_update_bits(cs42888->regmap, CS42888_TXCTL,
> > + CS42888_TXCTL_AMUTE | CS42888_TXCTL_DAC_SZC_MASK,
> > + CS42888_TXCTL_DAC_SZC_SR);
>
> Does this interfere with the manual mute controls or is it a separate
> thing? If it plays nicely with the manual controls it's probably better
> to leave it enabled since it improves performance in some benchmarks
> (that's why hardware tends to have the feature).
>
> > + /*
> > + * We haven't marked the chip revision as volatile due to
> > + * sharing a register with the right input volume; explicitly
> > + * bypass the cache to read it.
> > + */
> > + regcache_cache_bypass(cs42888->regmap, true);
>
> The other option here is to just not provide a default so that the first
> time it's read it goes to hardware. It doesn't make much difference
> either way though.
>
> > +static int cs42888_i2c_remove(struct i2c_client *i2c_client)
> > +{
> > + snd_soc_unregister_codec(&i2c_client->dev);
> > + return 0;
> > +}
>
> The driver ought to disable runtime PM, the clock and the regulators here.
>
> > + /*
> > + * In case the device was put to hard reset during sleep,
> > + * we need to wait 500ns here before any I2C communication
> > + */
> > + mdelay(5);
>
> Do we need 500ns or 5ms?
>
> > + regcache_sync(cs42888->regmap);
>
> Should really check the return value here.
>
> > + if (!IS_ERR(cs42888->clk))
> > + clk_disable_unprepare(cs42888->clk);
>
> Does the device work without MCLK?
^ permalink raw reply
* Re: [PATCH] ASoC: cs42888: Add codec driver support
From: Nicolin Chen @ 2014-02-24 15:47 UTC (permalink / raw)
To: Austin, Brian
Cc: Mark Brown, Handrigan, Paul, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
rob@landley.net, Liam Girdwood, grant.likely@linaro.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org
In-Reply-To: <B745DBDD-8A64-4B98-819B-72F8AFF602DE@cirrus.com>
On Mon, Feb 24, 2014 at 03:52:24PM +0000, Austin, Brian wrote:
>
> >
> >> + /* Disable auto-mute */
> >> + regmap_update_bits(cs42888->regmap, CS42888_TXCTL,
> >> + CS42888_TXCTL_AMUTE | CS42888_TXCTL_DAC_SZC_MASK,
> >> + CS42888_TXCTL_DAC_SZC_SR);
> >
> > Does this interfere with the manual mute controls or is it a separate
> > thing? If it plays nicely with the manual controls it's probably better
> > to leave it enabled since it improves performance in some benchmarks
> > (that's why hardware tends to have the feature).
>
> Auto-Mute should be enabled by default.
>
> >
> >> + if (!IS_ERR(cs42888->clk))
> >> + clk_disable_unprepare(cs42888->clk);
> >
> > Does the device work without MCLK?
> Yes, MCLK is required. If you can’t get the clock you should error out.
>
>
Will refine it as you suggest.
Thank you for the comments.
Nicolin Chen
^ permalink raw reply
* Re: [RFC PATCH v3 1/9] staging: imx-drm-core: don't request probe deferral in imx_drm_encoder_parse_of
From: Russell King - ARM Linux @ 2014-02-24 15:49 UTC (permalink / raw)
To: Philipp Zabel
Cc: devel, devicetree, David Airlie, Greg Kroah-Hartman, dri-devel,
kernel, Grant Likely, Shawn Guo, linux-arm-kernel, Lucas Stach
In-Reply-To: <1392723370-4772-2-git-send-email-p.zabel@pengutronix.de>
On Tue, Feb 18, 2014 at 12:36:02PM +0100, Philipp Zabel wrote:
> From: Lucas Stach <l.stach@pengutronix.de>
>
> Since imx_drm_encoder_parse_of is called from the encoder bind callbacks,
> it is too late to request probe deferral. Rather the core should make sure
> that the crtcs are bound before the encoders, after all needed components
> are probed.
Why is it too late? -EPROBE_DEFER from this point will cause the driver
initialisation to correctly unwind and return -EPROBE_DEFER to the
last-to-be-added component.
> This fixes probe failure when using the LDB on i.MX6.
More details please.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox