Re: [01/19] pinctrl: exynos: Add support for Exynos5433
Hi Chanwoo,
On Thursday 27 November 2014 01:04 PM, Chanwoo Choi wrote:
This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi-
functional input/output port pins and 135 memory port pins. There are 41 general
port groups and 2 memory port groups.
Cc: Tomasz Figa
Cc: Thomas Abraham
Cc: Linus Walleij
Signed-off-by: Chanwoo Choi
Acked-by: Geunsik Lim
Acked-by: Inki Dae
---
drivers/pinctrl/samsung/pinctrl-exynos.c | 163 ++
drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
3 files changed, 166 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 8e3e0c0..bd4c4ec 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1268,6 +1268,169 @@ struct samsung_pin_ctrl exynos5420_pin_ctrl[] = {
},
};
+/* pin banks of exynos5433 pin-controller - ALIVE */
+static struct samsung_pin_bank exynos5433_pin_banks0[] = {
+ EXYNOS_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
+ EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
+ EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
+ EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
+};
+
+/* pin banks of exynos5433 pin-controller - AUD */
+static struct samsung_pin_bank exynos5433_pin_banks1[] = {
+ EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
+ EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
+};
+
+/* pin banks of exynos5433 pin-controller - CPIF */
+static struct samsung_pin_bank exynos5433_pin_banks2[] = {
+ EXYNOS_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - eSE */
+static struct samsung_pin_bank exynos5433_pin_banks3[] = {
+ EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - FINGER */
+static struct samsung_pin_bank exynos5433_pin_banks4[] = {
+ EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - FSYS */
+static struct samsung_pin_bank exynos5433_pin_banks5[] = {
+ EXYNOS_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
+ EXYNOS_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
+ EXYNOS_PIN_BANK_EINTG(5, 0x040, "gpr0", 0x08),
+ EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr1", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpr2", 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpr3", 0x14),
+};
+
+/* pin banks of exynos5433 pin-controller - IMEM */
+static struct samsung_pin_bank exynos5433_pin_banks6[] = {
+ EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpf0", 0x00),
Is this complete?
+};
+
+/* pin banks of exynos5433 pin-controller - NFC */
+static struct samsung_pin_bank exynos5433_pin_banks7[] = {
+ EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj0", 0x00),
+};
+
+/* pin banks of exynos5433 pin-controller - PERIC */
+static struct samsung_pin_bank exynos5433_pin_banks8[] = {
+ EXYNOS_PIN_BANK_EINTG(6, 0x000, "gpv7", 0x00),
+ EXYNOS_PIN_BANK_EINTG(5, 0x020, "gpb0", 0x04),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpc0", 0x08),
+ EXYNOS_PIN_BANK_EINTG(2, 0x060, "gpc1", 0x0c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x080, "gpc2", 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpc3", 0x14),
+ EXYNOS_PIN_BANK_EINTG(2, 0x0c0, "gpg0", 0x18),
+ EXYNOS_PIN_BANK_EINTG(4, 0x0e0, "gpd0", 0x1c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x100, "gpd1", 0x20),
+ EXYNOS_PIN_BANK_EINTG(8, 0x120, "gpd2", 0x24),
+ EXYNOS_PIN_BANK_EINTG(5, 0x140, "gpd4", 0x28),
+ EXYNOS_PIN_BANK_EINTG(2, 0x160, "gpd8", 0x2c),
+ EXYNOS_PIN_BANK_EINTG(7, 0x180, "gpd6", 0x30),
+ EXYNOS_PIN_BANK_EINTG(3, 0x1a0, "gpd7", 0x34),
+ EXYNOS_PIN_BANK_EINTG(5, 0x1c0, "gpg1", 0x38),
+ EXYNOS_PIN_BANK_EINTG(2, 0x1e0, "gpg2", 0x3c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x200, "gpg3", 0x40),
+};
+
+/* pin banks of exynos5433 pin-controller - TOUCH */
+static struct samsung_pin_bank exynos5433_pin_banks9[] = {
+ EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj1", 0x00),
+};
+
+/*
+ * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
+ * four gpio/pin-mux/pinconfig controllers.
four? I can see you added 10.
Thanks,
Pankaj Dubey
+ */
+struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
+ {
+ /* pin-controller instance 0 data */
+ .pin_banks = exynos5433_pin_banks0,
+ .nr_banks = ARRAY_SIZE(exynos5433_pin_banks0),
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .suspend= exynos_pinctrl_suspend,
+ .resume = exynos_pinctrl_resume,
+ .label = "exynos5433-gpio-ctrl0",
+ }, {
+ /* pin-controller instance 1 data */
+ .pin_banks = exynos5433_pin_banks1,
+ .nr_banks = ARRAY_SIZE(exynos5433_pin_banks1),
+ .eint_gpio_init = exynos_eint_gpio_init,
+
Re: [PATCH 16/19] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On 27/11/14 07:35, Chanwoo Choi wrote:
> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC
> based on Octal core CPUs (quad Cortex-A57 and quad Cortex-A53).
>
> Cc: Kukjin Kim
> Cc: Mark Rutland
> Cc: Arnd Bergmann
> Cc: Olof Johansson
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Chanwoo Choi
> Acked-by: Inki Dae
> Acked-by: Geunsik Lim
> ---
> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698
> +
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 523 +++
> 2 files changed, 1221 insertions(+)
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
>
[...]
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> new file mode 100644
> index 000..3d8b576
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
[...]
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 13 0xff01>,
> +<1 14 0xff01>,
> +<1 11 0xff01>,
> +<1 10 0xff01>;
This is wrong. Timer interrupts for both A53 and A57 are level triggered.
> + clock-frequency = <2400>;
Please go and fix your firmware. Really...
> + use-clocksource-only;
> + use-physical-timer;
> + };
Well, that's a total NAK. Neither of these properties are part of the
binding, and we've already established that none of that would never be
valid on arm64.
I suggest you finally do what we've been asking for years, which is to
fix your boot ROM by adding the 5 lines of assembly code that are needed
instead of repeatedly post the same bogus DT files.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [01/19] pinctrl: exynos: Add support for Exynos5433
Hi Pankaj,
On 11/27/2014 07:26 PM, Pankaj Dubey wrote:
> Hi Chanwoo,
>
> On Thursday 27 November 2014 01:04 PM, Chanwoo Choi wrote:
>> This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228
>> multi-
>> functional input/output port pins and 135 memory port pins. There are 41
>> general
>> port groups and 2 memory port groups.
>>
>> Cc: Tomasz Figa
>> Cc: Thomas Abraham
>> Cc: Linus Walleij
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Geunsik Lim
>> Acked-by: Inki Dae
>>
>> ---
>> drivers/pinctrl/samsung/pinctrl-exynos.c | 163
>> ++
>> drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
>> drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
>> 3 files changed, 166 insertions(+)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index 8e3e0c0..bd4c4ec 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -1268,6 +1268,169 @@ struct samsung_pin_ctrl exynos5420_pin_ctrl[] = {
>> },
>> };
>>
>> +/* pin banks of exynos5433 pin-controller - ALIVE */
>> +static struct samsung_pin_bank exynos5433_pin_banks0[] = {
>> +EXYNOS_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
>> +EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
>> +EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
>> +EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - AUD */
>> +static struct samsung_pin_bank exynos5433_pin_banks1[] = {
>> +EXYNOS_PIN_BANK_EINTG(7, 0x000, "gpz0", 0x00),
>> +EXYNOS_PIN_BANK_EINTG(4, 0x020, "gpz1", 0x04),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - CPIF */
>> +static struct samsung_pin_bank exynos5433_pin_banks2[] = {
>> +EXYNOS_PIN_BANK_EINTG(2, 0x000, "gpv6", 0x00),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - eSE */
>> +static struct samsung_pin_bank exynos5433_pin_banks3[] = {
>> +EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj2", 0x00),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - FINGER */
>> +static struct samsung_pin_bank exynos5433_pin_banks4[] = {
>> +EXYNOS_PIN_BANK_EINTG(4, 0x000, "gpd5", 0x00),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - FSYS */
>> +static struct samsung_pin_bank exynos5433_pin_banks5[] = {
>> +EXYNOS_PIN_BANK_EINTG(6, 0x000, "gph1", 0x00),
>> +EXYNOS_PIN_BANK_EINTG(7, 0x020, "gpr4", 0x04),
>> +EXYNOS_PIN_BANK_EINTG(5, 0x040, "gpr0", 0x08),
>> +EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr1", 0x0c),
>> +EXYNOS_PIN_BANK_EINTG(2, 0x080, "gpr2", 0x10),
>> +EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpr3", 0x14),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - IMEM */
>> +static struct samsung_pin_bank exynos5433_pin_banks6[] = {
>> +EXYNOS_PIN_BANK_EINTG(8, 0x000, "gpf0", 0x00),
>
> Is this complete?
Exynos5433 has gpf1~gpf5. But, This patch did not include gpf1~gpf5.
because gpf1~gpf5 of Exynos5433 has different offset of EINT register.
gpf1~gpf5 is included in IMEM (0x1109) part But,EINT register of gpf1~gpf5
is included in ALIVE (0x1058) part. So, I'll consider how to support
gpf1~gpf5 gpios.
>
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - NFC */
>> +static struct samsung_pin_bank exynos5433_pin_banks7[] = {
>> +EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj0", 0x00),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - PERIC */
>> +static struct samsung_pin_bank exynos5433_pin_banks8[] = {
>> +EXYNOS_PIN_BANK_EINTG(6, 0x000, "gpv7", 0x00),
>> +EXYNOS_PIN_BANK_EINTG(5, 0x020, "gpb0", 0x04),
>> +EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpc0", 0x08),
>> +EXYNOS_PIN_BANK_EINTG(2, 0x060, "gpc1", 0x0c),
>> +EXYNOS_PIN_BANK_EINTG(6, 0x080, "gpc2", 0x10),
>> +EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpc3", 0x14),
>> +EXYNOS_PIN_BANK_EINTG(2, 0x0c0, "gpg0", 0x18),
>> +EXYNOS_PIN_BANK_EINTG(4, 0x0e0, "gpd0", 0x1c),
>> +EXYNOS_PIN_BANK_EINTG(6, 0x100, "gpd1", 0x20),
>> +EXYNOS_PIN_BANK_EINTG(8, 0x120, "gpd2", 0x24),
>> +EXYNOS_PIN_BANK_EINTG(5, 0x140, "gpd4", 0x28),
>> +EXYNOS_PIN_BANK_EINTG(2, 0x160, "gpd8", 0x2c),
>> +EXYNOS_PIN_BANK_EINTG(7, 0x180, "gpd6", 0x30),
>> +EXYNOS_PIN_BANK_EINTG(3, 0x1a0, "gpd7", 0x34),
>> +EXYNOS_PIN_BANK_EINTG(5, 0x1c0, "gpg1", 0x38),
>> +EXYNOS_PIN_BANK_EINTG(2, 0x1e0, "gpg2", 0x3c),
>> +EXYNOS_PIN_BANK_EINTG(8, 0x200, "gpg3", 0x40),
>> +};
>> +
>> +/* pin banks of exynos5433 pin-controller - TOUCH */
>> +static struct samsung_pin_bank exynos5433_pin_banks9[] = {
>> +EXYNOS_PIN_BANK_EINTG(3, 0x000, "gpj1", 0x00),
>> +};
>> +
>> +/*
>> + * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
>> + * four gpio/pin-mux/pinconfig controllers.
>
> four? I can see you added 10.
You're right. I'll fix it.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord.
Re: [PATCH 16/19] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
On Thu, Nov 27, 2014 at 07:35:13AM +, Chanwoo Choi wrote:
> This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC
> based on Octal core CPUs (quad Cortex-A57 and quad Cortex-A53).
>
> Cc: Kukjin Kim
> Cc: Mark Rutland
> Cc: Arnd Bergmann
> Cc: Olof Johansson
> Cc: Catalin Marinas
> Cc: Will Deacon
> Signed-off-by: Chanwoo Choi
> Acked-by: Inki Dae
> Acked-by: Geunsik Lim
> ---
> arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698
> +
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 523 +++
> 2 files changed, 1221 insertions(+)
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
> create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
[...]
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> new file mode 100644
> index 000..3d8b576
> --- /dev/null
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -0,0 +1,523 @@
> +/*
> + * Samsung's Exynos5433 SoC device tree source
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + *
> + * Samsung's Exynos5433 SoC device nodes are listed in this file. Exynos5433
> + * based board files can include this file and provide values for board
> specfic
> + * bindings.
> + *
> + * Note: This file does not include device nodes for all the controllers in
> + * Exynos5433 SoC. As device tree coverage for Exynos5433 increases,
> additional
> + * nodes can be added to this file.
> + *
> + * 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 "skeleton.dtsi"
> +#include
> +
Just to check: no memory reservations required for any reason?
There also don't appear to be any memory nodes. Typically if that's
filled in by the bootloader/FW we'd have an empty node (or one with a
zero size entry) and a comment regarding the FW.
> +/ {
> + compatible = "samsung,exynos5433";
> + #address-cells = <1>;
> + #size-cells = <1>;
Not two, on both counts? The CPUs can address more than 32 bits.
Is there nothing in the physical address space above 0x?
[...]
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@100 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + enable-method = "psci";
While the CPU nodes have enable-methods, I didn't spot a PSCI node
anywhere, so this dts cannot possibly have been used to bring up an SMP
system.
How has this dts been tested?
What PSCI revision have you implemented? Have have you tested it?
I take it from the presence of GICH/GICV in the gic node that CPUs enter
the kernel at EL2?
> + reg = <0x0 0x100>;
> + clock-frequency = <105000>;
What uses this?
> + };
[...]
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + fixed-rate-clocks {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + xusbxti: clock@0 {
> + compatible = "fixed-clock";
> + clock-output-names = "xusbxti";
> + #clock-cells = <0>;
> + };
> + };
Get rid of the fixed-rate-clocks container node. It's pointless and
messy. Given you only have one there's no need for the bogus
unit-address either.
> +
> + cmu_top: clock-controller@0x1003{
s/@0x/@/ -- a unit-address should not have the leading '0x'. Please
apply that to the rest of the file.
> + compatible = "samsung,exynos5433-cmu-top";
> + reg = <0x1003 0x0c04>;
> + #clock-cells = <1>;
> + };
[...]
> + mct@101c {
> + compatible = "samsung,exynos4210-mct";
> + reg = <0x101c 0x800>;
> + interrupts = <0 102 0>, <0 103 0>, <0 104 0>, <0 105
> 0>,
> + <0 106 0>, <0 107 0>, <0 108 0>, <0 109>,
> + <0 110 0>, <0 111 0>, <0 112 0>, <0 113 0>;
> + clocks = <&cmu_top CLK_FIN_PLL>, <&cmu_peris
> CLK_PCLK_MCT>;
> + clock-names = "fin_pll", "mct";
> + };
Hase this block had no changes whatsoever since its use in Exynos4210?
Do we not need a "samsung,exynos5433-mct" comaptible string too?
> +
> + gic:interrupt-controller@11001000 {
> + compatible = "a
Re: [PATCH 15/19] arm64: exynos5433: Enable ARMv8-based Exynos5433 SoC support
On Thu, Nov 27, 2014 at 07:35:12AM +, Chanwoo Choi wrote: > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index f4536e0..8a5e8a0 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -152,6 +152,16 @@ config ARCH_EXYNOS > help > This enables support for Samsung Exynos SoC family > > +config ARCH_EXYNOS5433 > + bool "ARMv8 based Samsung Exynos5433" > + select ARCH_EXYNOS > + select COMMON_CLK_SAMSUNG > + select PINCTRL > + select PINCTRL_EXYNOS > + > + help > + This enables support for Samsung Exynos5433 SoC family Please update defconfig as well to include this. We aim for the arm64 defconfig to build all the supported SoCs. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/7] regulator: Parse ena_gpio in core, add GPIO to max77686
Hi, The patchset generalizes the ena_gpio bindings and finally adds GPIO support to the max77686 driver. Adding GPIO to max77686 allows removal of fixed regulators from DTS which duplicate the description of hardware. Rationale behind adding ena-gpios to regulator core === Drivers often add custom DTS properties for parsing the GPIO for regulator enable control. Some of them don't have to do this in a special custom way and would work with a generic approach (e.g. S5M8767, S2MPS1x, MAX77686). As such drivers have to do this on their own, multiple different bindings are added and each driver duplicates similar code. Add a generic binding so the regulator core will do this work for drivers. This should offload some work from drivers and also limit creation of new custom properties for GPIO control. Changes since v3 1. Regulator cleanup patches were applied by Mark, drop them. 2. Re-work idea by adding generic ena-gpios binding. Changes since v2 Re-work the board file support removal after Javier's comments: use new DT style parsing. This imposes a lot of changes. 1. Add "of_compatible" for regulator drivers. 2. Provide backward compatibility if such "of_compatible" is not present. The driver will search for regulators node and use it as dev->of_node. Everything should be bisect-friendly. 3. New patches: 1, 2, 3, 5, 13 and 14. 4. Because of new style DT parsing it is much easier to put "gpio" properties in regulators top node (not in each regulator). This will be also new-gpio-lib friendly. Changes since v1 1. Add patch: 1/8 "regulator: max77686: Consistently index opmode array by rdev id". 2. Remove patch "regulator: max77686: Make regulator_desc array const" (applied). 3. Re-work patches removing from regulators board file support (2/8 and 3/8). Parse regulators with of_regulator_match() at once, remove num_regulators. 4. Patch 4/8: Add depends on OF to mfd/Kconfig. Add Javier's reviewed-by. 5. Patch 5/8: Add Javier's reviewed-by. 6. Patch 6/8: Add depends on GPIOLIB to regulator/Kconfig. Rename "external control" to "GPIO control" and "ext_control_gpios" to simpler "gpios". I tried to use new GPIO API but it ended with more problems https://lkml.org/lkml/2014/10/29/239 Patchset is rebased on next-20141114. Best regards, Krzysztof Krzysztof Kozlowski (7): mfd: max77686/802: Remove support for board files regulator: dt-bindings: Document the ena-gpios property regulator: of: Parse ena-gpios property from DTS regulator: Use ena_gpio supplied with generic regulator bindings regulator: max77686: Add GPIO control mfd/regulator: dt-bindings: max77686: Document gpio properties ARM: dts: exynos4412-trats: Switch max77686 regulators to GPIO control Documentation/devicetree/bindings/mfd/max77686.txt | 14 +++- .../devicetree/bindings/regulator/regulator.txt| 4 + arch/arm/boot/dts/exynos4412-trats2.dts| 25 ++ drivers/mfd/Kconfig| 1 + drivers/mfd/max77686.c | 23 -- drivers/regulator/core.c | 96 -- drivers/regulator/max77686.c | 58 +++-- drivers/regulator/of_regulator.c | 11 +++ include/linux/mfd/max77686-private.h | 1 - include/linux/mfd/max77686.h | 28 --- include/linux/regulator/driver.h | 5 ++ include/linux/regulator/machine.h | 13 +++ 12 files changed, 178 insertions(+), 101 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 6/7] mfd/regulator: dt-bindings: max77686: Document gpio properties
Document usage of ena-gpios properties which turn on external/GPIO
control over regulator.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/mfd/max77686.txt | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt
b/Documentation/devicetree/bindings/mfd/max77686.txt
index 75fdfaf41831..93c4cd07ffc8 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -37,8 +37,12 @@ to get matched with their hardware counterparts as follow:
Regulators which can be turned off during system suspend:
-LDOn : 2, 6-8, 10-12, 14-16,
-BUCKn : 1-4.
- Use standard regulator bindings for it ('regulator-off-in-suspend').
+ Regulators which can be configured for GPIO enable control:
+ -LDOn : 20, 21, 22
+ -BUCKn : 8, 9
+ Use standard regulator bindings for these ('regulator-off-in-suspend',
+ 'ena-gpios').
Example:
@@ -65,4 +69,12 @@ Example:
regulator-always-on;
regulator-boot-on;
};
+
+ buck9_reg {
+ regulator-compatible = "BUCK9";
+ regulator-name = "CAM_ISP_CORE_1.2V";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <120>;
+ ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>;
+ };
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/19] clk: samsung: Add binding documentation for Exynos5433 clock controller
On Thu, Nov 27, 2014 at 07:34:59AM +, Chanwoo Choi wrote: > This patch add binding documentation for Exynos5433 clock controller. > Exynos5433 has various clock domains So, this documentation explains > the detailed clock domains ans usage guide. > > Cc: Sylwester Nawrocki > Cc: Tomasz Figa > Signed-off-by: Chanwoo Choi > Acked-by: Inki Dae > Acked-by: Geunsik Lim > --- > .../devicetree/bindings/clock/exynos5433-clock.txt | 106 > + > 1 file changed, 106 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/clock/exynos5433-clock.txt > > diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt > b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt > new file mode 100644 > index 000..72cd0ba > --- /dev/null > +++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt > @@ -0,0 +1,106 @@ > +* Samsung Exynos5433 CMU (Clock Management Units) > + > +The Exynos5433 clock controller generates and supplies clock to various > +controllers within the Exynos5433 SoC. > + > +Required Properties: > + > +- compatible: should be one of the following. > + - "samsung,exynos5433-cmu-top" - clock controller compatible for CMU_TOP > +which generates clocks for > IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS > +domains and bus clocks. > + - "samsung,exynos5433-cmu-cpif" - clock controller compatible for CMU_CPIF > +which generates clocks for LLI (Low Latency Interface) IP. > + - "samsung,exynos5433-cmu-mif" - clock controller compatible for CMU_MIF > +which generates clocks for DRAM Memory Controller domain. > + - "samsung,exynos5433-cmu-peric" - clock controller compatible for > CMU_PERIC > +which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs. > + - "samsung,exynos5433-cmu-peris" - clock controller compatible for > CMU_PERIS > +which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs. > + - "samsung,exynos5433-cmu-fsys" - clock controller compatible for CMU_FSYS > +which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs. > + > +- reg: physical base address of the controller and length of memory mapped > + region. > + > +- #clock-cells: should be 1. > + > +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/exynos5433.h header and can be used in device > +tree sources. That header should be added as part of this patch, otehrwise this is incomplete. Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property
Document new properties for regulators (ena-gpios and ena-gpio-open-drain) for enabling control over GPIO. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/regulator/regulator.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index 4e7ed762b3bb..dad57b3badc7 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -30,6 +30,10 @@ Optional properties: - regulator-off-in-suspend: regulator should be off in suspend state. - regulator-suspend-microvolt: regulator should be set to this voltage in suspend. +- ena-gpios: GPIO to use for enable control. Actual implementation depends + on regulator driver. The bindings documentation for given driver describes + which regulator actually supports it. +- ena-gpio-open-drain: GPIO is open drain type. Deprecated properties: - regulator-compatible: If a regulator chip contains multiple -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/19] arm64: exynos5433: Enable ARMv8-based Exynos5433 SoC support
On 11/27/2014 08:18 PM, Catalin Marinas wrote: > On Thu, Nov 27, 2014 at 07:35:12AM +, Chanwoo Choi wrote: >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig >> index f4536e0..8a5e8a0 100644 >> --- a/arch/arm64/Kconfig >> +++ b/arch/arm64/Kconfig >> @@ -152,6 +152,16 @@ config ARCH_EXYNOS >> help >>This enables support for Samsung Exynos SoC family >> >> +config ARCH_EXYNOS5433 >> +bool "ARMv8 based Samsung Exynos5433" >> +select ARCH_EXYNOS >> +select COMMON_CLK_SAMSUNG >> +select PINCTRL >> +select PINCTRL_EXYNOS >> + >> +help >> + This enables support for Samsung Exynos5433 SoC family > > Please update defconfig as well to include this. We aim for the > arm64 defconfig to build all the supported SoCs. > OK, I'll add it. Thanks for your review. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 7/7] ARM: dts: exynos4412-trats: Switch max77686 regulators to GPIO control
Remove fixed regulators (duplicating what max77686 provides) and
add GPIO control to max77686 regulators. Add of_compatible to
voltage-regulators node.
This gives the system full control over those regulators. Previously
the state of such regulators was a mixture of what max77686 driver set
over I2C and what regulator-fixed set through GPIO.
Removal of 'regulator-always-on' from CAM_ISP_CORE_1.2V (buck9) allows
disabling it when it is not used. Previously this regulator was always
enabled because its enable state is a OR of:
- ENB9 GPIO (turned always on by regulator-fixed),
- BUCK9EN field in BUCK9CTRL register (off by max77686 through I2C).
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-trats2.dts | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 7a68e0832cd6..4ba981eae32e 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -58,15 +58,6 @@
#address-cells = <1>;
#size-cells = <0>;
- vemmc_reg: regulator-0 {
- compatible = "regulator-fixed";
- regulator-name = "VMEM_VDD_2.8V";
- regulator-min-microvolt = <280>;
- regulator-max-microvolt = <280>;
- gpio = <&gpk0 2 0>;
- enable-active-high;
- };
-
cam_io_reg: voltage-regulator-1 {
compatible = "regulator-fixed";
regulator-name = "CAM_SENSOR_A";
@@ -94,16 +85,6 @@
enable-active-high;
};
- cam_isp_core_reg: voltage-regulator-4 {
- compatible = "regulator-fixed";
- regulator-name = "CAM_ISP_CORE_1.2V_EN";
- regulator-min-microvolt = <120>;
- regulator-max-microvolt = <120>;
- gpio = <&gpm0 3 0>;
- enable-active-high;
- regulator-always-on;
- };
-
ps_als_reg: voltage-regulator-5 {
compatible = "regulator-fixed";
regulator-name = "LED_A_3.0V";
@@ -405,6 +386,7 @@
regulator-name = "VTF_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
+ ena-gpios = <&gpy2 0 GPIO_ACTIVE_HIGH>;
};
ldo22_reg: ldo22 {
@@ -412,6 +394,7 @@
regulator-name = "VMEM_VDD_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
+ ena-gpios = <&gpk0 2 GPIO_ACTIVE_HIGH>;
};
ldo23_reg: ldo23 {
@@ -518,6 +501,7 @@
regulator-name = "VMEM_VDDF_3.0V";
regulator-min-microvolt = <285>;
regulator-max-microvolt = <285>;
+ ena-gpios = <&gpk0 2 GPIO_ACTIVE_HIGH>;
};
buck9_reg: buck9 {
@@ -525,6 +509,7 @@
regulator-name = "CAM_ISP_CORE_1.2V";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <120>;
+ ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>;
};
};
};
@@ -591,7 +576,7 @@
broken-cd;
non-removable;
card-detect-delay = <200>;
- vmmc-supply = <&vemmc_reg>;
+ vmmc-supply = <&ldo22_reg>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <0>;
samsung,dw-mshc-sdr-timing = <2 3>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
Use ena_gpio from regulator constraints (filled by parsing generic
bindings) to initialize the GPIO enable control. Support also the old
way: ena_gpio supplied in regulator_config structure.
This also adds a new set_ena_gpio() callback in regulator_ops structure
which driver may provide to actually enable the GPIO control in
hardware.
Signed-off-by: Krzysztof Kozlowski
---
drivers/regulator/core.c | 96 ++--
include/linux/regulator/driver.h | 5 +++
2 files changed, 78 insertions(+), 23 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index bbf93c9caca3..1760184cd8dc 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1044,6 +1045,14 @@ static int set_machine_constraints(struct regulator_dev
*rdev,
}
}
+ if (rdev->constraints->use_ena_gpio && ops->set_ena_gpio) {
+ ret = ops->set_ena_gpio(rdev);
+ if (ret < 0) {
+ rdev_err(rdev, "failed to set enable GPIO control\n");
+ goto out;
+ }
+ }
+
print_constraints(rdev);
return 0;
out:
@@ -1660,36 +1669,36 @@
EXPORT_SYMBOL_GPL(regulator_bulk_unregister_supply_alias);
/* Manage enable GPIO list. Same GPIO pin can be shared among regulators */
static int regulator_ena_gpio_request(struct regulator_dev *rdev,
- const struct regulator_config *config)
+ unsigned int gpio,
+ bool gpio_invert,
+ unsigned int gpio_flags)
{
struct regulator_enable_gpio *pin;
struct gpio_desc *gpiod;
int ret;
- gpiod = gpio_to_desc(config->ena_gpio);
+ gpiod = gpio_to_desc(gpio);
list_for_each_entry(pin, ®ulator_ena_gpio_list, list) {
if (pin->gpiod == gpiod) {
- rdev_dbg(rdev, "GPIO %d is already used\n",
- config->ena_gpio);
+ rdev_dbg(rdev, "GPIO %d is already used\n", gpio);
goto update_ena_gpio_to_rdev;
}
}
- ret = gpio_request_one(config->ena_gpio,
- GPIOF_DIR_OUT | config->ena_gpio_flags,
+ ret = gpio_request_one(gpio, GPIOF_DIR_OUT | gpio_flags,
rdev_get_name(rdev));
if (ret)
return ret;
pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
if (pin == NULL) {
- gpio_free(config->ena_gpio);
+ gpio_free(gpio);
return -ENOMEM;
}
pin->gpiod = gpiod;
- pin->ena_gpio_invert = config->ena_gpio_invert;
+ pin->ena_gpio_invert = gpio_invert;
list_add(&pin->list, ®ulator_ena_gpio_list);
update_ena_gpio_to_rdev:
@@ -1698,6 +1707,59 @@ update_ena_gpio_to_rdev:
return 0;
}
+/*
+ * Request GPIO for enable control from regulator_config
+ * or init_data->constraints.
+ */
+static int regulator_ena_gpio_setup(struct regulator_dev *rdev,
+ const struct regulator_config *config,
+ const struct regulator_init_data *init_data)
+{
+ unsigned int gpio_flags;
+ bool gpio_invert;
+ int gpio, ret;
+
+ if (config->ena_gpio || config->ena_gpio_initialized) {
+ gpio = config->ena_gpio;
+ gpio_invert = config->ena_gpio_invert;
+ gpio_flags = config->ena_gpio_flags;
+ } else if (init_data && init_data->constraints.use_ena_gpio) {
+ const struct regulation_constraints *c =
&init_data->constraints;
+
+ gpio = c->ena_gpio;
+ gpio_invert = false;
+ gpio_flags = GPIOF_OUT_INIT_HIGH;
+
+ if (c->ena_gpio_flags & OF_GPIO_ACTIVE_LOW) {
+ gpio_invert = true;
+ gpio_flags = GPIOF_OUT_INIT_LOW;
+ }
+
+ if (c->ena_gpio_open_drain)
+ gpio_flags |= GPIOF_OPEN_DRAIN;
+ } else {
+ return 0;
+ }
+
+ if (!gpio_is_valid(gpio))
+ return 0;
+
+ ret = regulator_ena_gpio_request(rdev, gpio, gpio_invert, gpio_flags);
+ if (ret != 0) {
+ rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
+gpio, ret);
+ return ret;
+ }
+
+ if (gpio_flags & GPIOF_OUT_INIT_HIGH)
+ rdev->ena_gpio_state = 1;
+
+ if (gpio_invert)
+ rdev->ena_gpio_state = !rdev->ena_gpio_state;
+
+ return 0;
+}
+
static void regulator_ena_gpio_free(struct regulator_dev *rdev)
{
struct regulator_enable_gpio *pin, *n;
@@ -3650,21 +3712,9 @@ re
[PATCH v4 1/7] mfd: max77686/802: Remove support for board files
The driver is used only on Exynos based boards with DTS support.
After removal of board file support from max77686 and max77802 regulator
drivers, the MFD driver can be converted to DTS-only version. This
simplifies a little the code:
1. No dead (unused) entries in platform_data structure.
2. More code removed.
3. Regulator driver does not depend on allocated memory
from MFD driver.
4. It makes also easier extending the regulator driver.
Add to the max77686 MFD driver dependency on CONFIG_OF because without
DTS the regulator drivers (max77686 and max77802) won't bind.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
Acked-by: Lee Jones
Acked-by: Javier Martinez Canillas
Tested-by: Javier Martinez Canillas
---
drivers/mfd/Kconfig | 1 +
drivers/mfd/max77686.c | 23 ---
include/linux/mfd/max77686-private.h | 1 -
include/linux/mfd/max77686.h | 28
4 files changed, 1 insertion(+), 52 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 72d38081f779..2bb0789a828b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -412,6 +412,7 @@ config MFD_MAX14577
config MFD_MAX77686
bool "Maxim Semiconductor MAX77686/802 PMIC Support"
depends on I2C=y
+ depends on OF
select MFD_CORE
select REGMAP_I2C
select REGMAP_IRQ
diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index 929795eae9fc..3da237afacde 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -205,24 +205,10 @@ static const struct of_device_id max77686_pmic_dt_match[]
= {
{ },
};
-static struct max77686_platform_data *max77686_i2c_parse_dt_pdata(struct device
- *dev)
-{
- struct max77686_platform_data *pd;
-
- pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
- if (!pd)
- return NULL;
-
- dev->platform_data = pd;
- return pd;
-}
-
static int max77686_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct max77686_dev *max77686 = NULL;
- struct max77686_platform_data *pdata = dev_get_platdata(&i2c->dev);
const struct of_device_id *match;
unsigned int data;
int ret = 0;
@@ -233,14 +219,6 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
const struct mfd_cell *cells;
int n_devs;
- if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node && !pdata)
- pdata = max77686_i2c_parse_dt_pdata(&i2c->dev);
-
- if (!pdata) {
- dev_err(&i2c->dev, "No platform data found.\n");
- return -EINVAL;
- }
-
max77686 = devm_kzalloc(&i2c->dev,
sizeof(struct max77686_dev), GFP_KERNEL);
if (!max77686)
@@ -259,7 +237,6 @@ static int max77686_i2c_probe(struct i2c_client *i2c,
max77686->dev = &i2c->dev;
max77686->i2c = i2c;
- max77686->wakeup = pdata->wakeup;
max77686->irq = i2c->irq;
if (max77686->type == TYPE_MAX77686) {
diff --git a/include/linux/mfd/max77686-private.h
b/include/linux/mfd/max77686-private.h
index 960b92ad450d..f5043490d67c 100644
--- a/include/linux/mfd/max77686-private.h
+++ b/include/linux/mfd/max77686-private.h
@@ -447,7 +447,6 @@ struct max77686_dev {
struct regmap_irq_chip_data *rtc_irq_data;
int irq;
- bool wakeup;
struct mutex irqlock;
int irq_masks_cur[MAX77686_IRQ_GROUP_NR];
int irq_masks_cache[MAX77686_IRQ_GROUP_NR];
diff --git a/include/linux/mfd/max77686.h b/include/linux/mfd/max77686.h
index 553f7d09258a..bb995ab9a575 100644
--- a/include/linux/mfd/max77686.h
+++ b/include/linux/mfd/max77686.h
@@ -119,12 +119,6 @@ enum max77802_regulators {
MAX77802_REG_MAX,
};
-struct max77686_regulator_data {
- int id;
- struct regulator_init_data *initdata;
- struct device_node *of_node;
-};
-
enum max77686_opmode {
MAX77686_OPMODE_NORMAL,
MAX77686_OPMODE_LP,
@@ -136,26 +130,4 @@ struct max77686_opmode_data {
int mode;
};
-struct max77686_platform_data {
- int ono;
- int wakeup;
-
- /* PMIC */
- struct max77686_regulator_data *regulators;
- int num_regulators;
-
- struct max77686_opmode_data *opmode_data;
-
- /*
-* GPIO-DVS feature is not enabled with the current version of
-* MAX77686 driver. Buck2/3/4_voltages[0] is used as the default
-* voltage at probe. DVS/SELB gpios are set as OUTPUT-LOW.
-*/
- int buck234_gpio_dvs[3]; /* GPIO of [0]DVS1, [1]DVS2, [2]DVS3 */
- int buck234_gpio_selb[3]; /* [0]SELB2, [1]SELB3, [2]SELB4 */
- unsigned int buck2_voltage[8]; /* buckx_voltage in uV */
- unsigned int buck3_voltage[8];
- unsigned int buck4_voltage[8];
-};
-
#endif /* _
[PATCH v4 3/7] regulator: of: Parse ena-gpios property from DTS
Drivers often add custom DTS properties for parsing the GPIO for
regulator enable control. Some of them don't have to do this in a
special custom way and would work with a generic approach (e.g. S5M8767,
S2MPS1x, MAX77686). As such drivers have to do this on their own,
multiple different bindings are added and each driver duplicates similar
code.
Add a generic binding so the regulator core will do this work for
drivers. This should offload some work from drivers and also limit
creation of new custom properties for GPIO control.
The patch only fills regulator constraints with data from DTS. Data will
be used by regulator core in consecutive patch.
Signed-off-by: Krzysztof Kozlowski
---
drivers/regulator/of_regulator.c | 11 +++
include/linux/regulator/machine.h | 13 +
2 files changed, 24 insertions(+)
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 03edb175f3ae..f64739a97296 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -31,6 +32,7 @@ static void of_get_regulation_constraints(struct device_node
*np,
struct regulation_constraints *constraints = &(*init_data)->constraints;
struct regulator_state *suspend_state;
struct device_node *suspend_np;
+ enum of_gpio_flags gpio_flags;
int ret, i;
u32 pval;
@@ -81,6 +83,15 @@ static void of_get_regulation_constraints(struct device_node
*np,
if (!ret)
constraints->enable_time = pval;
+ constraints->ena_gpio = of_get_named_gpio_flags(np, "ena-gpios", 0,
+ &gpio_flags);
+ if (gpio_is_valid(constraints->ena_gpio)) {
+ constraints->use_ena_gpio = true;
+ constraints->ena_gpio_open_drain = of_property_read_bool(np,
+
"ena-gpio-open-drain");
+ constraints->ena_gpio_flags = gpio_flags;
+ }
+
for (i = 0; i < ARRAY_SIZE(regulator_states); i++) {
switch (i) {
case PM_SUSPEND_MEM:
diff --git a/include/linux/regulator/machine.h
b/include/linux/regulator/machine.h
index 0b08d05d470b..2faf2b3b71e7 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -95,6 +95,13 @@ struct regulator_state {
* mode.
* @initial_state: Suspend state to set by default.
* @initial_mode: Mode to set at startup.
+ *
+ * @use_ena_gpio: True if ena_gpio is a valid GPIO to use for enable control.
+ *If false, all other ena_gpio* fields are ignored.
+ * @ena_gpio: GPIO to use for enable control
+ * @ena_gpio_open_drain: Is GPIO open drain
+ * @ena_gpio_flags: Flags for GPIO request, see enum of_gpio_flags
+ *
* @ramp_delay: Time to settle down after voltage change (unit: uV/us)
* @enable_time: Turn-on time of the rails (unit: microseconds)
*/
@@ -130,6 +137,12 @@ struct regulation_constraints {
/* mode to set on startup */
unsigned int initial_mode;
+ /* enable control over GPIO */
+ bool use_ena_gpio;
+ int ena_gpio;
+ bool ena_gpio_open_drain;
+ unsigned int ena_gpio_flags;
+
unsigned int ramp_delay;
unsigned int enable_time;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/7] regulator: max77686: Add GPIO control
Add enable control over GPIO for regulators supporting this: LDO20,
LDO21, LDO22, buck8 and buck9.
This is needed for proper (and full) configuration of the Maxim 77686
PMIC without creating redundant 'regulator-fixed' entries.
Signed-off-by: Krzysztof Kozlowski
---
drivers/regulator/max77686.c | 58
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index 10d206266ac2..0d6bddad0ef4 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -46,6 +47,11 @@
#define MAX77686_DVS_UVSTEP12500
/*
+ * Value for configuring buck[89] and LDO{20,21,22} as GPIO control.
+ * It is the same as 'off' for other regulators.
+ */
+#define MAX77686_GPIO_CONTROL 0x0
+/*
* Values used for configuring LDOs and bucks.
* Forcing low power mode: LDO1, 3-5, 9, 13, 17-26
*/
@@ -82,6 +88,8 @@ enum max77686_ramp_rate {
};
struct max77686_data {
+ unsigned long long gpio_enabled:MAX77686_REGULATORS;
+
/* Array indexed by regulator id */
unsigned int opmode[MAX77686_REGULATORS];
};
@@ -100,6 +108,26 @@ static unsigned int max77686_get_opmode_shift(int id)
}
}
+/*
+ * When regulator is configured for GPIO control then it
+ * replaces "normal" mode. Any change from low power mode to normal
+ * should actually change to GPIO control.
+ * Map normal mode to proper value for such regulators.
+ */
+static unsigned int max77686_map_normal_mode(struct max77686_data *max77686,
+int id)
+{
+ switch (id) {
+ case MAX77686_BUCK8:
+ case MAX77686_BUCK9:
+ case MAX77686_LDO20 ... MAX77686_LDO22:
+ if (max77686->gpio_enabled & (1 << id))
+ return MAX77686_GPIO_CONTROL;
+ }
+
+ return MAX77686_NORMAL;
+}
+
/* Some BUCKs and LDOs supports Normal[ON/OFF] mode during suspend */
static int max77686_set_suspend_disable(struct regulator_dev *rdev)
{
@@ -136,7 +164,7 @@ static int max77686_set_suspend_mode(struct regulator_dev
*rdev,
val = MAX77686_LDO_LOWPOWER_PWRREQ;
break;
case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
- val = MAX77686_NORMAL;
+ val = max77686_map_normal_mode(max77686, id);
break;
default:
pr_warn("%s: regulator_suspend_mode : 0x%x not supported\n",
@@ -160,7 +188,7 @@ static int max77686_ldo_set_suspend_mode(struct
regulator_dev *rdev,
{
unsigned int val;
struct max77686_data *max77686 = rdev_get_drvdata(rdev);
- int ret;
+ int ret, id = rdev_get_id(rdev);
switch (mode) {
case REGULATOR_MODE_STANDBY:/* switch off */
@@ -170,7 +198,7 @@ static int max77686_ldo_set_suspend_mode(struct
regulator_dev *rdev,
val = MAX77686_LDO_LOWPOWER_PWRREQ;
break;
case REGULATOR_MODE_NORMAL: /* ON in Normal Mode */
- val = MAX77686_NORMAL;
+ val = max77686_map_normal_mode(max77686, id);
break;
default:
pr_warn("%s: regulator_suspend_mode : 0x%x not supported\n",
@@ -184,7 +212,7 @@ static int max77686_ldo_set_suspend_mode(struct
regulator_dev *rdev,
if (ret)
return ret;
- max77686->opmode[rdev_get_id(rdev)] = val;
+ max77686->opmode[id] = val;
return 0;
}
@@ -197,7 +225,7 @@ static int max77686_enable(struct regulator_dev *rdev)
shift = max77686_get_opmode_shift(id);
if (max77686->opmode[id] == MAX77686_OFF_PWRREQ)
- max77686->opmode[id] = MAX77686_NORMAL;
+ max77686->opmode[id] = max77686_map_normal_mode(max77686, id);
return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
rdev->desc->enable_mask,
@@ -229,6 +257,25 @@ static int max77686_set_ramp_delay(struct regulator_dev
*rdev, int ramp_delay)
MAX77686_RAMP_RATE_MASK, ramp_value << 6);
}
+static int max77686_enable_gpio_control(struct regulator_dev *rdev)
+{
+ struct max77686_data *max77686 = rdev_get_drvdata(rdev);
+ int id = rdev_get_id(rdev);
+
+ switch (id) {
+ case MAX77686_BUCK8:
+ case MAX77686_BUCK9:
+ case MAX77686_LDO20 ... MAX77686_LDO22:
+ max77686->gpio_enabled |= (1 << id);
+
+ return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
+ rdev->desc->enable_mask,
+ MAX77686_GPIO_CONTROL);
+ }
+
+ return -EINVAL;
+}
+
static struct regulator_ops max77686_ops = {
.list_voltage = regulator_list_voltage_
Re: [PATCH 02/19] clk: samsung: Add binding documentation for Exynos5433 clock controller
Dear Mark, On 11/27/2014 08:21 PM, Mark Rutland wrote: > On Thu, Nov 27, 2014 at 07:34:59AM +, Chanwoo Choi wrote: >> This patch add binding documentation for Exynos5433 clock controller. >> Exynos5433 has various clock domains So, this documentation explains >> the detailed clock domains ans usage guide. >> >> Cc: Sylwester Nawrocki >> Cc: Tomasz Figa >> Signed-off-by: Chanwoo Choi >> Acked-by: Inki Dae >> Acked-by: Geunsik Lim >> --- >> .../devicetree/bindings/clock/exynos5433-clock.txt | 106 >> + >> 1 file changed, 106 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/clock/exynos5433-clock.txt >> >> diff --git a/Documentation/devicetree/bindings/clock/exynos5433-clock.txt >> b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt >> new file mode 100644 >> index 000..72cd0ba >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/clock/exynos5433-clock.txt >> @@ -0,0 +1,106 @@ >> +* Samsung Exynos5433 CMU (Clock Management Units) >> + >> +The Exynos5433 clock controller generates and supplies clock to various >> +controllers within the Exynos5433 SoC. >> + >> +Required Properties: >> + >> +- compatible: should be one of the following. >> + - "samsung,exynos5433-cmu-top" - clock controller compatible for CMU_TOP >> +which generates clocks for >> IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS >> +domains and bus clocks. >> + - "samsung,exynos5433-cmu-cpif" - clock controller compatible for >> CMU_CPIF >> +which generates clocks for LLI (Low Latency Interface) IP. >> + - "samsung,exynos5433-cmu-mif" - clock controller compatible for CMU_MIF >> +which generates clocks for DRAM Memory Controller domain. >> + - "samsung,exynos5433-cmu-peric" - clock controller compatible for >> CMU_PERIC >> +which generates clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS IPs. >> + - "samsung,exynos5433-cmu-peris" - clock controller compatible for >> CMU_PERIS >> +which generates clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC IPs. >> + - "samsung,exynos5433-cmu-fsys" - clock controller compatible for >> CMU_FSYS >> +which generates clocks for USB/UFS/SDMMC/TSI/PDMA IPs. >> + >> +- reg: physical base address of the controller and length of memory mapped >> + region. >> + >> +- #clock-cells: should be 1. >> + >> +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/exynos5433.h header and can be used in device >> +tree sources. > > That header should be added as part of this patch, otehrwise this is > incomplete. OK, I'll merge two patches (patch2 and patch3) by solving this issue. patch2 : [PATCH 02/19] clk: samsung: Add binding documentation for Exynos5433 clock controller patch3 : [PATCH 03/19] clk: samsung: exynos5433: Add clocks using common clock framework Thanks for your review. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote: > + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1" > +and "samsung,exynos5433-cmu-bus2" - clock controller compatible for > CMU_BUS > +which generates global data buses clock and global peripheral buses > clock. > > - reg: physical base address of the controller and length of memory mapped >region. > This looks like you are duplicating the bindings and the code, but it's really the same hardware multiple times with minor variations that you should be able to describe properly here. Why not make three nodes with the same compatible string and have them handled by the same code? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] pinctrl: exynos: Add support for Exynos5433
On Thursday 27 November 2014 16:34:58 Chanwoo Choi wrote:
> +
> +/*
> + * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
> + * four gpio/pin-mux/pinconfig controllers.
> + */
> +struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
> + {
> + /* pin-controller instance 0 data */
> + .pin_banks = exynos5433_pin_banks0,
> + .nr_banks = ARRAY_SIZE(exynos5433_pin_banks0),
> + .eint_wkup_init = exynos_eint_wkup_init,
> + .suspend= exynos_pinctrl_suspend,
> + .resume = exynos_pinctrl_resume,
> + .label = "exynos5433-gpio-ctrl0",
> + }, {
>
I'm counting nine controllers, not four ;-)
These seem to all be fairly regular, my impression is that with the
move to arm64, you should come up with a new binding that can fully
describe each controller so you don't have to add new code and bindings
for each future SoC that uses the same scheme.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [03/19] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Chanwoo, On Thursday 27 November 2014 01:05 PM, Chanwoo Choi wrote: This patch adds the support for CMU (Clock Management Units) of Exynos5433 which is 64bit SoC and has Octa-cores. This patch supports necessary clocks for kernel boot as following: - PLL/MMC/UART/MCT/I2C/SPI Cc: Sylwester Nawrocki Cc: Tomasz Figa Signed-off-by: Chanwoo Choi Acked-by: Inki Dae Acked-by: Geunsik Lim --- drivers/clk/samsung/Makefile | 1 + drivers/clk/samsung/clk-exynos5433.c | 971 + include/dt-bindings/clock/exynos5433.h | 200 +++ 3 files changed, 1172 insertions(+) create mode 100644 drivers/clk/samsung/clk-exynos5433.c create mode 100644 include/dt-bindings/clock/exynos5433.h diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile index 04acd70..9e8bd83 100644 --- a/drivers/clk/samsung/Makefile +++ b/drivers/clk/samsung/Makefile @@ -10,6 +10,7 @@ obj-$(CONFIG_SOC_EXYNOS5250) += clk-exynos5250.o obj-$(CONFIG_SOC_EXYNOS5260) += clk-exynos5260.o obj-$(CONFIG_SOC_EXYNOS5410) += clk-exynos5410.o obj-$(CONFIG_SOC_EXYNOS5420) += clk-exynos5420.o +obj-$(CONFIG_ARCH_EXYNOS5433) += clk-exynos5433.o obj-$(CONFIG_SOC_EXYNOS5440) += clk-exynos5440.o obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-audss.o obj-$(CONFIG_ARCH_EXYNOS) += clk-exynos-clkout.o diff --git a/drivers/clk/samsung/clk-exynos5433.c b/drivers/clk/samsung/clk-exynos5433.c new file mode 100644 index 000..25b447a --- /dev/null +++ b/drivers/clk/samsung/clk-exynos5433.c @@ -0,0 +1,971 @@ +/* + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * Author: Chanwoo Choi + * + * 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. + * + * Common Clock Framework support for Exynos5443 SoC. + */ + +#include +#include +#include +#include + +#include + +#include "clk.h" +#include "clk-pll.h" + +/* + * Register offset definitions for CMU_TOP + */ +#define ISP_PLL_LOCK 0x +#define AUD_PLL_LOCK 0x0004 +#define ISP_PLL_CON0 0x0100 +#define ISP_PLL_CON1 0x0104 +#define ISP_PLL_FREQ_DET 0x0108 +#define AUD_PLL_CON0 0x0110 +#define AUD_PLL_CON1 0x0114 +#define AUD_PLL_CON2 0x0118 +#define AUD_PLL_FREQ_DET 0x011c +#define MUX_SEL_TOP0 0x0200 +#define MUX_SEL_TOP1 0x0204 +#define MUX_SEL_TOP2 0x0208 +#define MUX_SEL_TOP3 0x020c +#define MUX_SEL_TOP4 0x0210 +#define MUX_SEL_TOP_MSCL 0x0220 +#define MUX_SEL_TOP_CAM1 0x0224 +#defineMUX_SEL_TOP_DISP0x0228 Looks like you inserted tab space after #define, please keep white space. +#define MUX_SEL_TOP_FSYS0 0x0230 +#define MUX_SEL_TOP_FSYS1 0x0234 +#define MUX_SEL_TOP_PERIC0 0x0238 +#define MUX_SEL_TOP_PERIC1 0x023c +#define MUX_ENABLE_TOP00x0300 +#define MUX_ENABLE_TOP10x0304 +#define MUX_ENABLE_TOP20x0308 +#define MUX_ENABLE_TOP30x030c +#define MUX_ENABLE_TOP40x0310 +#define MUX_ENABLE_TOP_MSCL0x0320 +#define MUX_ENABLE_TOP_CAM10x0324 +#define MUX_ENABLE_TOP_DISP0x0328 +#define MUX_ENABLE_TOP_FSYS0 0x0330 +#define MUX_ENABLE_TOP_FSYS1 0x0334 +#define MUX_ENABLE_TOP_PERIC0 0x0338 +#define MUX_ENABLE_TOP_PERIC1 0x033c +#define MUX_STAT_TOP0 0x0400 +#define MUX_STAT_TOP1 0x0404 +#define MUX_STAT_TOP2 0x0408 +#define MUX_STAT_TOP3 0x040c +#define MUX_STAT_TOP4 0x0410 +#define MUX_STAT_TOP_MSCL 0x0420 +#define MUX_STAT_TOP_CAM1 0x0424 +#define MUX_STAT_TOP_FSYS0 0x0430 +#define MUX_STAT_TOP_FSYS1 0x0434 +#define MUX_STAT_TOP_PERIC00x0438 +#define MUX_STAT_TOP_PERIC10x043c +#define DIV_TOP0 0x0600 +#define DIV_TOP1 0x0604 +#define DIV_TOP2 0x0608 +#define DIV_TOP3 0x060c +#define DIV_TOP4 0x0610 +#define DIV_TOP_MSCL 0x0618 +#define DIV_TOP_CAM10 0x061c +#define DIV_TOP_CAM11 0x0620 +#define DIV_TOP_FSYS0 0x062c +#define DIV_TOP_FSYS1 0x0630 +#define DIV_TOP_FSYS2 0x0634 +#define DIV_TOP_PERIC0 0x0638 +#define DIV_TOP_PERIC1 0x063c +#define DIV_TOP_PERIC2 0x0640 +#define DIV_TOP_PERIC3 0x0644 +#define DIV_TOP_PERIC4 0x
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
Dear Arnd, On 11/27/2014 08:41 PM, Arnd Bergmann wrote: > On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote: >> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1" >> +and "samsung,exynos5433-cmu-bus2" - clock controller compatible for >> CMU_BUS >> +which generates global data buses clock and global peripheral buses >> clock. >> >> - reg: physical base address of the controller and length of memory mapped >>region. >> > > This looks like you are duplicating the bindings and the code, but > it's really the same hardware multiple times with minor variations > that you should be able to describe properly here. Why not make > three nodes with the same compatible string and have them handled > by the same code? Each CMU_BUSx domain of Exynos5433 have different base address as following: - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04 - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04 - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04 So, I implement CMU_BUSx domain which has each compatible string. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
Hi,
On 27/11/14 12:56, Chanwoo Choi wrote:
> On 11/27/2014 08:41 PM, Arnd Bergmann wrote:
>> > On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote:
>>> >> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
>>> >> +and "samsung,exynos5433-cmu-bus2" - clock controller compatible for
>>> >> CMU_BUS
>>> >> +which generates global data buses clock and global peripheral buses
>>> >> clock.
>>> >>
>>> >> - reg: physical base address of the controller and length of memory
>>> >> mapped
>>> >>region.
>>> >>
>> >
>> > This looks like you are duplicating the bindings and the code, but
>> > it's really the same hardware multiple times with minor variations
>> > that you should be able to describe properly here. Why not make
>> > three nodes with the same compatible string and have them handled
>> > by the same code?
>
> Each CMU_BUSx domain of Exynos5433 have different base address as following:
> - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04
> - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04
> - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04
>
> So, I implement CMU_BUSx domain which has each compatible string.
You can always have multiple entries in the reg property. I've done
something like this for the exynos4415 CMU_ISPx units:
cmu_isp: clock-controller@1206 {
compatible = "samsung,exynos4415-cmu-isp";
reg = <0x1206 0xB10>, <0x1207 0xB10>;
#clock-cells = <1>;
assigned-clocks = <&cmu CLK_FOUT_ISP_PLL>;
assigned-clock-rates = <3>;
};
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
Hi Sylwester,
On 11/27/2014 09:12 PM, Sylwester Nawrocki wrote:
> Hi,
>
> On 27/11/14 12:56, Chanwoo Choi wrote:
>> On 11/27/2014 08:41 PM, Arnd Bergmann wrote:
On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote:
>> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
>> +and "samsung,exynos5433-cmu-bus2" - clock controller compatible for
>> CMU_BUS
>> +which generates global data buses clock and global peripheral buses
>> clock.
>>
>> - reg: physical base address of the controller and length of memory
>> mapped
>>region.
>>
This looks like you are duplicating the bindings and the code, but
it's really the same hardware multiple times with minor variations
that you should be able to describe properly here. Why not make
three nodes with the same compatible string and have them handled
by the same code?
>>
>> Each CMU_BUSx domain of Exynos5433 have different base address as following:
>> - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04
>> - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04
>> - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04
>>
>> So, I implement CMU_BUSx domain which has each compatible string.
>
> You can always have multiple entries in the reg property. I've done
> something like this for the exynos4415 CMU_ISPx units:
>
> cmu_isp: clock-controller@1206 {
> compatible = "samsung,exynos4415-cmu-isp";
> reg = <0x1206 0xB10>, <0x1207 0xB10>;
> #clock-cells = <1>;
>
> assigned-clocks = <&cmu CLK_FOUT_ISP_PLL>;
> assigned-clock-rates = <3>;
> };
Thanks for your guide.
I'll re-implment CMU_BUSx domain according to your guide.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] pinctrl: exynos: Add support for Exynos5433
2014-11-27 20:45 GMT+09:00 Arnd Bergmann :
> On Thursday 27 November 2014 16:34:58 Chanwoo Choi wrote:
>> +
>> +/*
>> + * Samsung pinctrl driver data for Exynos5433 SoC. Exynos5433 SoC includes
>> + * four gpio/pin-mux/pinconfig controllers.
>> + */
>> +struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
>> + {
>> + /* pin-controller instance 0 data */
>> + .pin_banks = exynos5433_pin_banks0,
>> + .nr_banks = ARRAY_SIZE(exynos5433_pin_banks0),
>> + .eint_wkup_init = exynos_eint_wkup_init,
>> + .suspend= exynos_pinctrl_suspend,
>> + .resume = exynos_pinctrl_resume,
>> + .label = "exynos5433-gpio-ctrl0",
>> + }, {
>>
>
> I'm counting nine controllers, not four ;-)
>
> These seem to all be fairly regular,
Yup, especially considering what Chanwoo mentioned about the great
idea someone came up with about putting EINT registers of one of the
controllers in different pin controller.
> my impression is that with the
> move to arm64, you should come up with a new binding that can fully
> describe each controller so you don't have to add new code and bindings
> for each future SoC that uses the same scheme.
Still, this is exactly the same thing I thought when initially refactoring this
driver 2 years ago and what was dismissed at that time due to people
supposedly not wanting that much data in DT. If this point of view has changed,
then I fully support your view, though.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/19] pinctrl: exynos: Add support for Exynos5433
On Thursday 27 November 2014 21:14:59 Tomasz Figa wrote: > > my impression is that with the > > move to arm64, you should come up with a new binding that can fully > > describe each controller so you don't have to add new code and bindings > > for each future SoC that uses the same scheme. > > Still, this is exactly the same thing I thought when initially refactoring > this > driver 2 years ago and what was dismissed at that time due to people > supposedly not wanting that much data in DT. If this point of view has > changed, > then I fully support your view, though. I guess people were at the time underestimating the rate at which Samsung comes out with new SoC variants that are all slightly different. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Thursday 27 November 2014 13:12:08 Sylwester Nawrocki wrote:
> On 27/11/14 12:56, Chanwoo Choi wrote:
> > On 11/27/2014 08:41 PM, Arnd Bergmann wrote:
> >> > On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote:
> >>> >> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
> >>> >> +and "samsung,exynos5433-cmu-bus2" - clock controller compatible
> >>> >> for CMU_BUS
> >>> >> +which generates global data buses clock and global peripheral
> >>> >> buses clock.
> >>> >>
> >>> >> - reg: physical base address of the controller and length of memory
> >>> >> mapped
> >>> >>region.
> >>> >>
> >> >
> >> > This looks like you are duplicating the bindings and the code, but
> >> > it's really the same hardware multiple times with minor variations
> >> > that you should be able to describe properly here. Why not make
> >> > three nodes with the same compatible string and have them handled
> >> > by the same code?
> >
> > Each CMU_BUSx domain of Exynos5433 have different base address as following:
> > - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04
> > - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04
> > - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04
> >
> > So, I implement CMU_BUSx domain which has each compatible string.
But the base address is in the reg property, not in the compatible
property. What I mean is to have multiple nodes like
clock-controller@11360 {
reg = <0 0x11360 0 0x1000>;
compatible = "samsung,exynos5433-cmu";
#clock-cells = <1>;
};
clock-controller@11480 {
reg = <0 0x11480 0 0x1000>;
compatible = "samsung,exynos5433-cmu";
#clock-cells = <1>;
};
The code will just map the local registers for each instance and then
provide the clocks of the right instance when asked for it.
> You can always have multiple entries in the reg property. I've done
> something like this for the exynos4415 CMU_ISPx units:
>
> cmu_isp: clock-controller@1206 {
> compatible = "samsung,exynos4415-cmu-isp";
> reg = <0x1206 0xB10>, <0x1207 0xB10>;
> #clock-cells = <1>;
>
> assigned-clocks = <&cmu CLK_FOUT_ISP_PLL>;
> assigned-clock-rates = <3>;
> };
This is a different problem, this is a clock controller with multiple
sets of registers that are all different. In case of the cmu, it seems
that they are all the same, you just have multiple copies at different
locations, and they are connected to different devices.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [03/19] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Pankaj, On 11/27/2014 08:48 PM, Pankaj Dubey wrote: > Hi Chanwoo, > > On Thursday 27 November 2014 01:05 PM, Chanwoo Choi wrote: >> This patch adds the support for CMU (Clock Management Units) of Exynos5433 >> which is 64bit SoC and has Octa-cores. This patch supports necessary clocks >> for kernel boot as following: >> - PLL/MMC/UART/MCT/I2C/SPI >> >> Cc: Sylwester Nawrocki >> Cc: Tomasz Figa >> Signed-off-by: Chanwoo Choi >> Acked-by: Inki Dae >> Acked-by: Geunsik Lim >> >> --- >> drivers/clk/samsung/Makefile | 1 + >> drivers/clk/samsung/clk-exynos5433.c | 971 >> + >> include/dt-bindings/clock/exynos5433.h | 200 +++ >> 3 files changed, 1172 insertions(+) >> create mode 100644 drivers/clk/samsung/clk-exynos5433.c >> create mode 100644 include/dt-bindings/clock/exynos5433.h >> >> diff --git a/drivers/clk/samsung/Makefile b/drivers/clk/samsung/Makefile >> index 04acd70..9e8bd83 100644 >> --- a/drivers/clk/samsung/Makefile >> +++ b/drivers/clk/samsung/Makefile >> @@ -10,6 +10,7 @@ obj-$(CONFIG_SOC_EXYNOS5250)+= clk-exynos5250.o >> obj-$(CONFIG_SOC_EXYNOS5260)+= clk-exynos5260.o >> obj-$(CONFIG_SOC_EXYNOS5410)+= clk-exynos5410.o >> obj-$(CONFIG_SOC_EXYNOS5420)+= clk-exynos5420.o >> +obj-$(CONFIG_ARCH_EXYNOS5433)+= clk-exynos5433.o >> obj-$(CONFIG_SOC_EXYNOS5440)+= clk-exynos5440.o >> obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-audss.o >> obj-$(CONFIG_ARCH_EXYNOS)+= clk-exynos-clkout.o >> diff --git a/drivers/clk/samsung/clk-exynos5433.c >> b/drivers/clk/samsung/clk-exynos5433.c >> new file mode 100644 >> index 000..25b447a >> --- /dev/null >> +++ b/drivers/clk/samsung/clk-exynos5433.c >> @@ -0,0 +1,971 @@ >> +/* >> + * Copyright (c) 2014 Samsung Electronics Co., Ltd. >> + * Author: Chanwoo Choi >> + * >> + * 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. >> + * >> + * Common Clock Framework support for Exynos5443 SoC. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> + >> +#include >> + >> +#include "clk.h" >> +#include "clk-pll.h" >> + >> +/* >> + * Register offset definitions for CMU_TOP >> + */ >> +#define ISP_PLL_LOCK0x >> +#define AUD_PLL_LOCK0x0004 >> +#define ISP_PLL_CON00x0100 >> +#define ISP_PLL_CON10x0104 >> +#define ISP_PLL_FREQ_DET0x0108 >> +#define AUD_PLL_CON00x0110 >> +#define AUD_PLL_CON10x0114 >> +#define AUD_PLL_CON20x0118 >> +#define AUD_PLL_FREQ_DET0x011c >> +#define MUX_SEL_TOP00x0200 >> +#define MUX_SEL_TOP10x0204 >> +#define MUX_SEL_TOP20x0208 >> +#define MUX_SEL_TOP30x020c >> +#define MUX_SEL_TOP40x0210 >> +#define MUX_SEL_TOP_MSCL0x0220 >> +#define MUX_SEL_TOP_CAM10x0224 >> +#defineMUX_SEL_TOP_DISP0x0228 > > Looks like you inserted tab space after #define, please keep white space. I'll fix it. > > >> +#define MUX_SEL_TOP_FSYS00x0230 >> +#define MUX_SEL_TOP_FSYS10x0234 >> +#define MUX_SEL_TOP_PERIC00x0238 >> +#define MUX_SEL_TOP_PERIC10x023c >> +#define MUX_ENABLE_TOP00x0300 >> +#define MUX_ENABLE_TOP10x0304 >> +#define MUX_ENABLE_TOP20x0308 >> +#define MUX_ENABLE_TOP30x030c >> +#define MUX_ENABLE_TOP40x0310 >> +#define MUX_ENABLE_TOP_MSCL0x0320 >> +#define MUX_ENABLE_TOP_CAM10x0324 >> +#define MUX_ENABLE_TOP_DISP0x0328 >> +#define MUX_ENABLE_TOP_FSYS00x0330 >> +#define MUX_ENABLE_TOP_FSYS10x0334 >> +#define MUX_ENABLE_TOP_PERIC00x0338 >> +#define MUX_ENABLE_TOP_PERIC10x033c >> +#define MUX_STAT_TOP00x0400 >> +#define MUX_STAT_TOP10x0404 >> +#define MUX_STAT_TOP20x0408 >> +#define MUX_STAT_TOP30x040c >> +#define MUX_STAT_TOP40x0410 >> +#define MUX_STAT_TOP_MSCL0x0420 >> +#define MUX_STAT_TOP_CAM10x0424 >> +#define MUX_STAT_TOP_FSYS00x0430 >> +#define MUX_STAT_TOP_FSYS10x0434 >> +#define MUX_STAT_TOP_PERIC00x0438 >> +#define MUX_STAT_TOP_PERIC10x043c >> +#define DIV_TOP00x0600 >> +#define DIV_TOP10x0604 >> +#define DIV_TOP20x0608 >> +#define DIV_TOP30x060c >> +#define DIV_TOP40x0610 >> +#define DIV_TOP_MSCL0x0618 >> +#define DIV_TOP_CAM100x061c >> +#define DIV_TOP_CAM110x0620 >> +#define DIV_TOP_FSYS00x062c >> +#define DIV_TOP_FSYS10x0630 >> +#define DIV_TOP_FSYS20x0634 >> +#define DIV_TOP_PERIC00x0638 >> +#define DIV_TOP_PERIC10x063c >> +#define DIV_TOP_PERIC20x0640 >> +#define DIV_TOP_PERIC3
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
Dear Arnd,
On 11/27/2014 09:35 PM, Arnd Bergmann wrote:
> On Thursday 27 November 2014 13:12:08 Sylwester Nawrocki wrote:
>> On 27/11/14 12:56, Chanwoo Choi wrote:
>>> On 11/27/2014 08:41 PM, Arnd Bergmann wrote:
> On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote:
>>> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
>>> +and "samsung,exynos5433-cmu-bus2" - clock controller compatible
>>> for CMU_BUS
>>> +which generates global data buses clock and global peripheral
>>> buses clock.
>>>
>>> - reg: physical base address of the controller and length of memory
>>> mapped
>>>region.
>>>
>
> This looks like you are duplicating the bindings and the code, but
> it's really the same hardware multiple times with minor variations
> that you should be able to describe properly here. Why not make
> three nodes with the same compatible string and have them handled
> by the same code?
>>>
>>> Each CMU_BUSx domain of Exynos5433 have different base address as following:
>>> - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04
>>> - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04
>>> - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04
>>>
>>> So, I implement CMU_BUSx domain which has each compatible string.
>
> But the base address is in the reg property, not in the compatible
> property. What I mean is to have multiple nodes like
The merged clock driver in mainline have different compatible string
if base addresss of clock domain is different. So, I implemented each CMU_BUSx
domain
with different compatible string.
>
> clock-controller@11360 {
> reg = <0 0x11360 0 0x1000>;
> compatible = "samsung,exynos5433-cmu";
> #clock-cells = <1>;
> };
>
> clock-controller@11480 {
> reg = <0 0x11480 0 0x1000>;
> compatible = "samsung,exynos5433-cmu";
> #clock-cells = <1>;
> };
>
> The code will just map the local registers for each instance and then
> provide the clocks of the right instance when asked for it.
Each clock domain has not the same mux/divider/clock. So, just one compatible
string could not support all of clock domains.
Best Regards,
Chanwoo Choi
>
>> You can always have multiple entries in the reg property. I've done
>> something like this for the exynos4415 CMU_ISPx units:
>>
>> cmu_isp: clock-controller@1206 {
>> compatible = "samsung,exynos4415-cmu-isp";
>> reg = <0x1206 0xB10>, <0x1207 0xB10>;
>> #clock-cells = <1>;
>>
>> assigned-clocks = <&cmu CLK_FOUT_ISP_PLL>;
>> assigned-clock-rates = <3>;
>> };
>
> This is a different problem, this is a clock controller with multiple
> sets of registers that are all different. In case of the cmu, it seems
> that they are all the same, you just have multiple copies at different
> locations, and they are connected to different devices.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/7] mfd: max77686/802: Remove support for board files
On Thu, Nov 27, 2014 at 12:20:47PM +0100, Krzysztof Kozlowski wrote: > The driver is used only on Exynos based boards with DTS support. > After removal of board file support from max77686 and max77802 regulator > drivers, the MFD driver can be converted to DTS-only version. This > simplifies a little the code: Why is this a dependency for new features in the regulator core? signature.asc Description: Digital signature
Re: [PATCH v4 1/7] mfd: max77686/802: Remove support for board files
On czw, 2014-11-27 at 13:03 +, Mark Brown wrote: > On Thu, Nov 27, 2014 at 12:20:47PM +0100, Krzysztof Kozlowski wrote: > > The driver is used only on Exynos based boards with DTS support. > > After removal of board file support from max77686 and max77802 regulator > > drivers, the MFD driver can be converted to DTS-only version. This > > simplifies a little the code: > > Why is this a dependency for new features in the regulator core? My mistake, I based this patchset on regulator cleanup but this MFD change is not needed for it. It can be skipped here. Sorry for the noise. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Thursday 27 November 2014 21:58:53 Chanwoo Choi wrote:
> Dear Arnd,
>
> On 11/27/2014 09:35 PM, Arnd Bergmann wrote:
> > On Thursday 27 November 2014 13:12:08 Sylwester Nawrocki wrote:
> >> On 27/11/14 12:56, Chanwoo Choi wrote:
> >>> On 11/27/2014 08:41 PM, Arnd Bergmann wrote:
> > On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote:
> >>> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
> >>> +and "samsung,exynos5433-cmu-bus2" - clock controller compatible
> >>> for CMU_BUS
> >>> +which generates global data buses clock and global peripheral
> >>> buses clock.
> >>>
> >>> - reg: physical base address of the controller and length of memory
> >>> mapped
> >>>region.
> >>>
> >
> > This looks like you are duplicating the bindings and the code, but
> > it's really the same hardware multiple times with minor variations
> > that you should be able to describe properly here. Why not make
> > three nodes with the same compatible string and have them handled
> > by the same code?
> >>>
> >>> Each CMU_BUSx domain of Exynos5433 have different base address as
> >>> following:
> >>> - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04
> >>> - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04
> >>> - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04
> >>>
> >>> So, I implement CMU_BUSx domain which has each compatible string.
> >
> > But the base address is in the reg property, not in the compatible
> > property. What I mean is to have multiple nodes like
>
> The merged clock driver in mainline have different compatible string
> if base addresss of clock domain is different. So, I implemented each
> CMU_BUSx domain
> with different compatible string.
Why?
> > clock-controller@11360 {
> > reg = <0 0x11360 0 0x1000>;
> > compatible = "samsung,exynos5433-cmu";
> > #clock-cells = <1>;
> > };
> >
> > clock-controller@11480 {
> > reg = <0 0x11480 0 0x1000>;
> > compatible = "samsung,exynos5433-cmu";
> > #clock-cells = <1>;
> > };
> >
> > The code will just map the local registers for each instance and then
> > provide the clocks of the right instance when asked for it.
>
> Each clock domain has not the same mux/divider/clock. So, just one compatible
> string could not support all of clock domains.
What are the specific differences? I saw that one of them has more
outputs than the others but it seemed like a superset, so you just
wouldn't be allowed to access the non-connected outputs.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/2] Samsung fixes for v3.18
On Friday 21 November 2014, Kukjin Kim wrote: > The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9: > > Linux 3.18-rc5 (2014-11-16 16:36:20 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tags/samsung-fixes-v3.18 > > for you to fetch changes up to 0526f276f94758245ac5886604fe8c805c1b6d2c: > > ARM: dts: Explicitly set dr_mode on exynos5250-snow (2014-11-19 > 16:52:15 +0900) > > > Samsung fixes for v3.18 > > - explicitly set dr_mode on exynos5250-snow > this is required when kernel is built with USB gadget support. > Pulled into fixes, thanks! The patch looks like it should be backported to stable kernels but doesn't have the cc header, are you going to send it to sta...@vger.kernel.org once it hits mainline? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] Samsung defconfig update for v3.18
On Friday 21 November 2014, Kukjin Kim wrote: > The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4: > > Linux 3.18-rc3 (2014-11-02 15:01:51 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > tags/samsung-defconfig-v3.18 > > for you to fetch changes up to 0788148935c3a0fae3cca6af72943b9628bf8a54: > > ARM: exynos_defconfig: Enable max77802 rtc and clock drivers > (2014-11-21 21:46:21 +0900) > > > Samsung defconfig update for v3.18 > > - enable max77802 rtc and clock drivers for exynos_defconfig > : enable the kernel config options to have the drivers for > max77802 including rtc and 2-ch 32kHz clock outputs Pulled into next/fixes, thanks! Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] Samsung defconfig update for v3.18
On Thursday 27 November 2014, Arnd Bergmann wrote: > On Friday 21 November 2014, Kukjin Kim wrote: > > The following changes since commit 0df1f2487d2f0d04703f142813d53615d62a1da4: > > > > Linux 3.18-rc3 (2014-11-02 15:01:51 -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > > tags/samsung-defconfig-v3.18 > > > > for you to fetch changes up to 0788148935c3a0fae3cca6af72943b9628bf8a54: > > > > ARM: exynos_defconfig: Enable max77802 rtc and clock drivers > > (2014-11-21 21:46:21 +0900) > > > > > > Samsung defconfig update for v3.18 > > > > - enable max77802 rtc and clock drivers for exynos_defconfig > > : enable the kernel config options to have the drivers for > > max77802 including rtc and 2-ch 32kHz clock outputs > > Pulled into next/fixes, thanks! Sorry, I meant fixes, not next/fixes. It's queued for 3.18. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Thursday 27 November 2014 22:41:49 Chanwoo Choi wrote:
> 2014년 11월 27일 목요일, Arnd Bergmann님이 작성한 메시지:
>
> > On Thursday 27 November 2014 21:58:53 Chanwoo Choi wrote:
> > > Dear Arnd,
> > >
> > > On 11/27/2014 09:35 PM, Arnd Bergmann wrote:
> > > > On Thursday 27 November 2014 13:12:08 Sylwester Nawrocki wrote:
> > > >> On 27/11/14 12:56, Chanwoo Choi wrote:
> > > >>> On 11/27/2014 08:41 PM, Arnd Bergmann wrote:
> > > > On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote:
> > > >>> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
> > > >>> +and "samsung,exynos5433-cmu-bus2" - clock controller
> > compatible for CMU_BUS
> > > >>> +which generates global data buses clock and global
> > peripheral buses clock.
> > > >>>
> > > >>> - reg: physical base address of the controller and length of
> > memory mapped
> > > >>>region.
> > > >>>
> > > >
> > > > This looks like you are duplicating the bindings and the code, but
> > > > it's really the same hardware multiple times with minor variations
> > > > that you should be able to describe properly here. Why not make
> > > > three nodes with the same compatible string and have them handled
> > > > by the same code?
> > > >>>
> > > >>> Each CMU_BUSx domain of Exynos5433 have different base address as
> > following:
> > > >>> - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04
> > > >>> - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04
> > > >>> - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04
> > > >>>
> > > >>> So, I implement CMU_BUSx domain which has each compatible string.
> > > >
> > > > But the base address is in the reg property, not in the compatible
> > > > property. What I mean is to have multiple nodes like
> > >
> > > The merged clock driver in mainline have different compatible string
> > > if base addresss of clock domain is different. So, I implemented each
> > CMU_BUSx domain
> > > with different compatible string.
> >
> > Why?
>
>
> As I explained on below, each clock domain have different clocks.
> So, clocks have unique clock name.
>
> If clock driver use only one compatible for various clock domain, clock
> driver have to know the base address of each domain for distinction of
> clock domain. I think It is stong dependency between device and driver.
No, not at all. You can have lots of clock controllers with the same
compatible string defining different instances of the same IP block,
e.g. for compatible="fixed-clock".
> >
> > > > clock-controller@11360 {
> > > > reg = <0 0x11360 0 0x1000>;
> > > > compatible = "samsung,exynos5433-cmu";
> > > > #clock-cells = <1>;
> > > > };
> > > >
> > > > clock-controller@11480 {
> > > > reg = <0 0x11480 0 0x1000>;
> > > > compatible = "samsung,exynos5433-cmu";
> > > > #clock-cells = <1>;
> > > > };
> > > >
> > > > The code will just map the local registers for each instance and then
> > > > provide the clocks of the right instance when asked for it.
> > >
> > > Each clock domain has not the same mux/divider/clock. So, just one
> > compatible
> > > string could not support all of clock domains.
> >
> > What are the specific differences?
>
>
>
> > I'm not sure that difference among clock domains because I think it is
> dependent on the opinion of architect of SoC.
>
> cmu_bus0/1/2 are much similar. Just cmu_bus2 has one more mux/gate clock
> than cmu_bus0/1.
Yes, that's what I mean. You can simply model that extra mux/gate
in the driver, as long as nothing ever tries to access the clock.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
Hello Viresh,
On Thu, Nov 27, 2014 at 09:38:39AM +0530, Viresh Kumar wrote:
> Few nits..
>
> On 26 November 2014 at 23:20, Eduardo Valentin wrote:
>
> > Signed-off-by: Eduardo Valentin
> > ---
>
> The normal practice is to write the non-commitable part here ...
>
err... normal practice by whom? hehe...
My "normal" practice is to allow people to read the diff stat before my
extra comments :-)
> > drivers/thermal/cpu_cooling.c | 5 +
> > drivers/thermal/db8500_cpufreq_cooling.c | 5 -
> > drivers/thermal/imx_thermal.c | 5 -
> > drivers/thermal/samsung/exynos_thermal_common.c| 2 +-
> > drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
> > 5 files changed, 6 insertions(+), 17 deletions(-)
> > ---
>
> But this works as well :)
>
hehe ok.
> > This is attempt to organize the cpu cooling vs. cpufreq boot sequencing.
> > The main change in this patch, as in the commit log, is to have the check
> > for the cpufreq layer in the cpu cooling device registration, instead of
> > in thermal drivers. This way, drivers don't need to bother about it, they
> > just need to propagate the error value.
> >
> > This change was tested on top of:
> > (0) - Viresh's change in cpufreq layer and cpufreq-dt (up to patch 4):
> > https://patchwork.kernel.org/patch/5384141/
> > https://patchwork.kernel.org/patch/5384151/
> > https://patchwork.kernel.org/patch/5384161/
> > https://patchwork.kernel.org/patch/5384171/
> > (1) - fix of thermal core:
> > https://patchwork.kernel.org/patch/5326991/
> >
> > After Viresh's changes, cpufreq-dt is properly sequenced with cpu cooling
> > registration. Non-of based drivers also should take advantage if these
> > changes, as now they do not need to check for cpufreq layer. The check is
> > where it belongs, in cpu cooling device registration.
> >
> > BR, Eduardo Valentin
> >
> >
> > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> > index 1ab0018..9e6945b 100644
> > --- a/drivers/thermal/cpu_cooling.c
> > +++ b/drivers/thermal/cpu_cooling.c
> > @@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node *np,
> > int ret = 0, i;
> > struct cpufreq_policy policy;
> >
> > + if (!cpufreq_get_current_driver() ||
> > !cpufreq_frequency_get_table(0)) {
>
> Only !cpufreq_frequency_get_table(0) is enough here.
>
Yeah, I thought of it too. Just combined what people had in their
drivers here. But I agree that latter is enough.
> For rest:
>
> Acked-by: Viresh Kumar
Ok.
though.. "normal practice" says ack's are oftern used by the maintainer
of the affected code (quoting Documentation/SubmittingPatches) :-)
BR, Eduardo Valenti
signature.asc
Description: Digital signature
[PATCHv2 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
In this patch, the cpu_cooling code checks for the usability of cpufreq
layer before proceeding with the CPU cooling device registration. The
main reason is: CPU cooling device is not usable if cpufreq cannot
switch frequencies.
Similar checks are spread in thermal drivers. Thus, the advantage now
is to have the check in a single place: cpu cooling device registration.
For this reason, this patch also updates the existing drivers that
depend on CPU cooling to simply propagate the error code of the cpu
cooling registration call. Therefore, in case cpufreq is not ready, the
thermal drivers will still return -EPROBE_DEFER, in an attempt to try
again when cpufreq layer gets ready.
Cc: devicet...@vger.kernel.org
Cc: Grant Likely
Cc: Kukjin Kim
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Naveen Krishna Chatradhi
Cc: Rob Herring
Cc: Zhang Rui
Acked-by: Viresh Kumar
Signed-off-by: Eduardo Valentin
---
drivers/thermal/cpu_cooling.c | 5 +
drivers/thermal/db8500_cpufreq_cooling.c | 5 -
drivers/thermal/imx_thermal.c | 5 -
drivers/thermal/samsung/exynos_thermal_common.c| 2 +-
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 6 --
5 files changed, 6 insertions(+), 17 deletions(-)
---
(I'm sorry VireshK, I am still using my normal practice) :-)
Changes from V1:
- As per Viresh K. suggestion's, the check for cpufreq layer readiness is now
only a simple fetch for cpufreq table.
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 1ab0018..bed3fa2 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -440,6 +440,11 @@ __cpufreq_cooling_register(struct device_node *np,
int ret = 0, i;
struct cpufreq_policy policy;
+ if (!cpufreq_frequency_get_table(0)) {
+ pr_err("cpu_cooling: cpufreq layer not ready! Deferring.\n");
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
/* Verify that all the clip cpus have same freq_min, freq_max limit */
for_each_cpu(i, clip_cpus) {
/* continue if cpufreq policy not found and not return error */
diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
b/drivers/thermal/db8500_cpufreq_cooling.c
index 786d192..1ac7ec6 100644
--- a/drivers/thermal/db8500_cpufreq_cooling.c
+++ b/drivers/thermal/db8500_cpufreq_cooling.c
@@ -18,7 +18,6 @@
*/
#include
-#include
#include
#include
#include
@@ -30,10 +29,6 @@ static int db8500_cpufreq_cooling_probe(struct
platform_device *pdev)
struct thermal_cooling_device *cdev;
struct cpumask mask_val;
- /* make sure cpufreq driver has been initialized */
- if (!cpufreq_frequency_get_table(0))
- return -EPROBE_DEFER;
-
cpumask_set_cpu(0, &mask_val);
cdev = cpufreq_cooling_register(&mask_val);
diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
index 5a1f107..16405b4 100644
--- a/drivers/thermal/imx_thermal.c
+++ b/drivers/thermal/imx_thermal.c
@@ -9,7 +9,6 @@
#include
#include
-#include
#include
#include
#include
@@ -459,10 +458,6 @@ static int imx_thermal_probe(struct platform_device *pdev)
int measure_freq;
int ret;
- if (!cpufreq_get_current_driver()) {
- dev_dbg(&pdev->dev, "no cpufreq driver!");
- return -EPROBE_DEFER;
- }
data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
if (!data)
return -ENOMEM;
diff --git a/drivers/thermal/samsung/exynos_thermal_common.c
b/drivers/thermal/samsung/exynos_thermal_common.c
index 3f5ad25..f84975e 100644
--- a/drivers/thermal/samsung/exynos_thermal_common.c
+++ b/drivers/thermal/samsung/exynos_thermal_common.c
@@ -373,7 +373,7 @@ int exynos_register_thermal(struct thermal_sensor_conf
*sensor_conf)
if (IS_ERR(th_zone->cool_dev[th_zone->cool_dev_size])) {
dev_err(sensor_conf->dev,
"Failed to register cpufreq cooling device\n");
- ret = -EINVAL;
+ ret =
PTR_ERR(th_zone->cool_dev[th_zone->cool_dev_size]);
goto err_unregister;
}
th_zone->cool_dev_size++;
diff --git a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
index 5fd0386..cf88585 100644
--- a/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
+++ b/drivers/thermal/ti-soc-thermal/ti-thermal-common.c
@@ -28,7 +28,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -407,11 +406,6 @@ int ti_thermal_register_cpu_cooling(struct ti_bandgap
*bgp, int id)
if (!data)
return -EINVAL;
- if (!cpufreq_get_current_driver()) {
- dev_dbg(bgp->dev, "no cpufr
[PATCH] PM / Domains: Add pm_genpd_lookup() API to lookup domain by device node
In a step to move away from using genpd's name based APIs, such as the
pm_genpd_add_subdomain_names(), provide an API to lookup an already
initialized generic PM domain by its device node.
This API would typically be a called from SOC specific code, to fetch a
handle to the domain. Especially convenient to configure subdomains and
when the hierarchy of the domains are described in DT.
Do note, before pm_genpd_init() is invoked to initialize a generic PM
domain, it's the callers responsibility to assign the new ->dev_node
pointer in the struct generic_pm_domain, to enable pm_genpd_lookup() to
find the domain.
Signed-off-by: Ulf Hansson
---
The background to why I propose this patch comes from a discussion around the
below patchset:
https://lkml.org/lkml/2014/11/24/290
---
drivers/base/power/domain.c | 26 ++
include/linux/pm_domain.h | 2 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 735c473..34555eb 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -75,6 +75,32 @@ struct generic_pm_domain *dev_to_genpd(struct device *dev)
return pd_to_genpd(dev->pm_domain);
}
+/**
+ * pm_genpd_lookup - Fetch a generic PM domain object by device node
+ * @node: Device node to a corresponding genpd.
+ *
+ * Returns a valid pointer to struct generic_pm_domain on success or ERR_PTR()
+ * on failure.
+ */
+struct generic_pm_domain *pm_genpd_lookup(struct device_node *node)
+{
+ struct generic_pm_domain *genpd = ERR_PTR(-ENOENT), *gpd;
+
+ if (IS_ERR_OR_NULL(node))
+ return ERR_PTR(-EINVAL);
+
+ mutex_lock(&gpd_list_lock);
+ list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
+ if (gpd->dev_node == node) {
+ genpd = gpd;
+ break;
+ }
+ }
+ mutex_unlock(&gpd_list_lock);
+ return genpd;
+}
+EXPORT_SYMBOL_GPL(pm_genpd_lookup);
+
static int genpd_stop_dev(struct generic_pm_domain *genpd, struct device *dev)
{
return GENPD_DEV_TIMED_CALLBACK(genpd, int, stop, dev,
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 8cbd32e..322cb7c 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -53,6 +53,7 @@ struct generic_pm_domain {
struct dev_power_governor *gov;
struct work_struct power_off_work;
const char *name;
+ struct device_node *dev_node; /* Device node for the PM domain */
unsigned int in_progress; /* Number of devices being suspended
now */
atomic_t sd_count; /* Number of subdomains with power "on" */
enum gpd_status status; /* Current state of the domain */
@@ -126,6 +127,7 @@ static inline struct generic_pm_domain_data
*dev_gpd_data(struct device *dev)
}
extern struct generic_pm_domain *dev_to_genpd(struct device *dev);
+extern struct generic_pm_domain *pm_genpd_lookup(struct device_node *node);
extern int __pm_genpd_add_device(struct generic_pm_domain *genpd,
struct device *dev,
struct gpd_timing_data *td);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: Add DECON driver
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
DECON(Display and Enhancement Controller) is the new IP
in exynos7 SOC for generating video signals using pixel data.
DECON driver can be used to drive 2 different interfaces on Exynos7:
DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
The existing FIMD driver code was used as a template to create
DECON driver. Only DECON-INT is supported as of now, and
DECON-EXT support will be added later.
Signed-off-by: Akshu Agrawal
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/video/exynos7-decon.txt| 67 ++
drivers/gpu/drm/exynos/Kconfig | 13 +-
drivers/gpu/drm/exynos/Makefile|1 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1029
drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
include/video/exynos7_decon.h | 346 +++
7 files changed, 1458 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
create mode 100644 include/video/exynos7_decon.h
diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
b/Documentation/devicetree/bindings/video/exynos7-decon.txt
new file mode 100644
index 000..14db519
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
@@ -0,0 +1,67 @@
+Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
+
+DECON (Display and Enhancement Controller) is the Display Controller for the
+Exynos7 series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be "samsung,exynos7-decon";
+
+- reg: physical base address and length of the DECON registers set.
+
+- interrupt-parent: should be the phandle of the decon controller's
+ parent interrupt controller.
+
+- interrupts: should contain a list of all DECON IP block interrupts in the
+order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- interrupt-names: should contain the interrupt names: "fifo", "vsync",
+ "lcd_sys", in the same order as they were listed in the interrupts
+property.
+
+- pinctrl-0: pin control group to be used for this controller.
+
+- pinctrl-names: must contain a "default" entry.
+
+- clocks: must include clock specifiers corresponding to entries in the
+ clock-names property.
+
+- clock-names: list of clock names sorted in the same order as the clocks
+ property. Must contain "pclk_decon0", "aclk_decon0",
+ "decon0_eclk", "decon0_vclk".
+
+Optional Properties:
+- samsung,power-domain: a phandle to DECON power domain node.
+- display-timings: timing settings for FIMD, as described in document [1].
+ Can be used in case timings cannot be provided otherwise
+ or to override timings provided by the panel.
+
+[1]: Documentation/devicetree/bindings/video/display-timing.txt
+
+Example:
+
+SoC specific DT entry:
+
+ decon@1393 {
+ compatible = "samsung,exynos7-decon";
+ interrupt-parent = <&combiner>;
+ reg = <0x1393 0x1000>;
+ interrupt-names = "lcd_sys", "vsync", "fifo";
+ interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
+ clocks = <&clock_disp PCLK_DECON_INT>,
+<&clock_disp ACLK_DECON_INT>,
+<&clock_disp SCLK_DECON_INT_ECLK>,
+<&clock_disp SCLK_DECON_INT_EXTCLKPLL>;
+ clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
+ "decon0_vclk";
+ status = "disabled";
+ };
+
+Board specific DT entry:
+
+ decon@1393 {
+ pinctrl-0 = <&lcd_clk &pwm1_out>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 7f9f6f9..d3434cb 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
help
Choose this option if you want to use Exynos FIMD for DRM.
+config DRM_EXYNOS_DECON
+ bool "Exynos DRM DECON"
+ depends on DRM_EXYNOS
+ select FB_MODE_HELPERS
+ help
+ Choose this option if you want to use Exynos DECON for DRM.
+
config DRM_EXYNOS_DPI
bool "EXYNOS DRM parallel output support"
- depends on DRM_EXYNOS_FIMD
+ depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS_DECON)
select DRM_PANEL
default n
help
@@ -42,7 +49,7 @@ config DRM_EXYNOS_DPI
config DR
Re: [PATCH RFC v2 07/12] PM / Domains: export pm_genpd_lookup_name
On 25 November 2014 at 09:48, amit daniel kachhap wrote: > On Tue, Nov 25, 2014 at 1:05 PM, Ulf Hansson wrote: >> On 24 November 2014 at 14:04, Amit Daniel Kachhap >> wrote: >>> This API may be needed to set the power domain parent/child relationship >>> in the power domain platform driver. The parent relationship is >>> generally set after the child power domain is registered with the power >>> domain subsystem. In this case, pm_genpd_lookup_name API might be >>> useful. >> >> I think this is a step in the wrong direction. Instead we should be >> working on removing the "name" based APIs from genpd. >> >> The proper way should be to pass the PM domain as a parameter to the >> APIs instead. > Yes i understand but i had a special requirement for using this API > during pd probe. > I cannot use hierarchy to represent parent/child pd nodes as it will > break the existing SoC's. In my case all the PD nodes are linear. The > parent/child relationship are established in the second pass after all > the PD entries are registered with the help of this API. > Although there a way that i can always keep parent PD's before the > child PD's in DT in linear order. Will check this approach. I had some thinking around this, could the below approach work? I just posted a patch[1] adding a new pm_genpd_lookup() API, which is using a "DT device node" to fetch the genpd. The idea is to use that API to get the genpd handle which is needed to configure a subdomain through pm_genpd_add_subdomain() API. In principle you will have to walk through the DT a couple of times, initialize those domains (and subdomains) which either don't have a parent domain or which parent domain already has been initialized. I guess you need a somewhat clever loop to do that, but I think it's doable. Obviously we also need to have a generic binding for a "parent domain". I like Geert's proposal from the other patch, which means using "power-domains = <&pd_xyz>". Kind regards Uffe [1] http://marc.info/?l=linux-pm&m=141709766008458&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 2/3] ARM: shmobile: Convert to genpd flags for PM clocks for r8a7779
Instead of using the dev_ops ->stop|start() callbacks for genpd, let's
convert to use genpd's flag field and set it to PM_DOMAIN_PM_CLK.
Signed-off-by: Ulf Hansson
---
Changes in v2:
None.
---
arch/arm/mach-shmobile/pm-r8a7779.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/pm-r8a7779.c
b/arch/arm/mach-shmobile/pm-r8a7779.c
index 82fe3d7..6d1c011 100644
--- a/arch/arm/mach-shmobile/pm-r8a7779.c
+++ b/arch/arm/mach-shmobile/pm-r8a7779.c
@@ -83,9 +83,8 @@ static void r8a7779_init_pm_domain(struct r8a7779_pm_domain
*r8a7779_pd)
{
struct generic_pm_domain *genpd = &r8a7779_pd->genpd;
+ genpd->flags = PM_DOMAIN_PM_CLK;
pm_genpd_init(genpd, NULL, false);
- genpd->dev_ops.stop = pm_clk_suspend;
- genpd->dev_ops.start = pm_clk_resume;
genpd->dev_ops.active_wakeup = pd_active_wakeup;
genpd->power_off = pd_power_down;
genpd->power_on = pd_power_up;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 0/3] PM / Domains: Add initial PM clock support to genpd
Changes in v2: -Small fixes in patch 1. It's quite common for PM domains to use PM clocks. Typically from SOC specific code, the per device PM clock list is created and pm_clk_suspend|resume() are invoked to handle clock gating/ungating. A step towards consolidation is to integrate PM clock support into genpd, which is what this patchset does. In this initial step, the calls to the pm_clk_suspend|resume() are handled within genpd, but the per device PM clock list still needs to be created from SOC specific code. It seems reasonable to have gendp to handle that as well, but that left to future patchsets to address. It's not every users of genpd that are keen on using PM clocks thus we need to provide this a configuration option for genpd. In patch 2 and patch 3, we convert some of the SH-MOBILE SOCs to start using the new PM clock support in genpd. Ulf Hansson (3): PM / Domains: Initial PM clock support for genpd ARM: shmobile: Convert to genpd flags for PM clocks for r8a7779 ARM: shmobile: Convert to genpd flags for PM clocks for R-mobile arch/arm/mach-shmobile/pm-r8a7779.c | 3 +-- arch/arm/mach-shmobile/pm-rmobile.c | 3 +-- drivers/base/power/domain.c | 7 +++ include/linux/pm_domain.h | 3 +++ 4 files changed, 12 insertions(+), 4 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 3/3] ARM: shmobile: Convert to genpd flags for PM clocks for R-mobile
Instead of using the dev_ops ->stop|start() callbacks for genpd, let's convert to use genpd's flag field and set it to PM_DOMAIN_PM_CLK. Signed-off-by: Ulf Hansson --- Changes in v2: None. --- arch/arm/mach-shmobile/pm-rmobile.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm/mach-shmobile/pm-rmobile.c b/arch/arm/mach-shmobile/pm-rmobile.c index 717e641..42af9bd 100644 --- a/arch/arm/mach-shmobile/pm-rmobile.c +++ b/arch/arm/mach-shmobile/pm-rmobile.c @@ -106,9 +106,8 @@ static void rmobile_init_pm_domain(struct rmobile_pm_domain *rmobile_pd) struct generic_pm_domain *genpd = &rmobile_pd->genpd; struct dev_power_governor *gov = rmobile_pd->gov; + genpd->flags = PM_DOMAIN_PM_CLK; pm_genpd_init(genpd, gov ? : &simple_qos_governor, false); - genpd->dev_ops.stop = pm_clk_suspend; - genpd->dev_ops.start= pm_clk_resume; genpd->dev_ops.active_wakeup= rmobile_pd_active_wakeup; genpd->power_off= rmobile_pd_power_down; genpd->power_on = rmobile_pd_power_up; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/3] PM / Domains: Initial PM clock support for genpd
It's quite common for PM domains to use PM clocks. Typically from SOC
specific code, the per device PM clock list is created and
pm_clk_suspend|resume() are invoked to handle clock gating/ungating.
A step towards consolidation is to integrate PM clock support into
genpd, which is what this patch does.
In this initial step, the calls to the pm_clk_suspend|resume() are
handled within genpd, but the per device PM clock list still needs to
be created from SOC specific code. It seems reasonable to have gendp to
handle that as well, but that left to future patches to address.
It's not every users of genpd that are keen on using PM clocks thus we
need to provide this a configuration option for genpd. Therefore let's
add flag field in the genpd struct to keep this information and define
a new PM_DOMAIN_PM_CLK bit can then be set at initialization.
Signed-off-by: Ulf Hansson
---
Changes in v2:
Set ->start() callback to pm_clk_resume() and fixed comment.
---
drivers/base/power/domain.c | 7 +++
include/linux/pm_domain.h | 3 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 735c473..42ba5a0 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1928,6 +1929,12 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
genpd->domain.ops.complete = pm_genpd_complete;
genpd->dev_ops.save_state = pm_genpd_default_save_state;
genpd->dev_ops.restore_state = pm_genpd_default_restore_state;
+
+ if (genpd->flags & PM_DOMAIN_PM_CLK) {
+ genpd->dev_ops.stop = pm_clk_suspend;
+ genpd->dev_ops.start = pm_clk_resume;
+ }
+
mutex_lock(&gpd_list_lock);
list_add(&genpd->gpd_list_node, &gpd_list);
mutex_unlock(&gpd_list_lock);
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 8cbd32e..4ba06a4f 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -76,6 +77,8 @@ struct generic_pm_domain {
struct device *dev);
void (*detach_dev)(struct generic_pm_domain *domain,
struct device *dev);
+ unsigned int flags; /* Bit field of configs for genpd */
+#define PM_DOMAIN_PM_CLK BIT(0) /* PM domain uses PM clk */
};
static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain *pd)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Thu, Nov 27, 2014 at 11:02 PM, Arnd Bergmann wrote:
> On Thursday 27 November 2014 22:41:49 Chanwoo Choi wrote:
>> 2014년 11월 27일 목요일, Arnd Bergmann님이 작성한 메시지:
>>
>> > On Thursday 27 November 2014 21:58:53 Chanwoo Choi wrote:
>> > > Dear Arnd,
>> > >
>> > > On 11/27/2014 09:35 PM, Arnd Bergmann wrote:
>> > > > On Thursday 27 November 2014 13:12:08 Sylwester Nawrocki wrote:
>> > > >> On 27/11/14 12:56, Chanwoo Choi wrote:
>> > > >>> On 11/27/2014 08:41 PM, Arnd Bergmann wrote:
>> > > > On Thursday 27 November 2014 16:35:08 Chanwoo Choi wrote:
>> > > >>> + - "samsung,exynos5433-cmu-bus0", "samsung,exynos5433-cmu-bus1"
>> > > >>> +and "samsung,exynos5433-cmu-bus2" - clock controller
>> > compatible for CMU_BUS
>> > > >>> +which generates global data buses clock and global
>> > peripheral buses clock.
>> > > >>>
>> > > >>> - reg: physical base address of the controller and length of
>> > memory mapped
>> > > >>>region.
>> > > >>>
>> > > >
>> > > > This looks like you are duplicating the bindings and the code, but
>> > > > it's really the same hardware multiple times with minor variations
>> > > > that you should be able to describe properly here. Why not make
>> > > > three nodes with the same compatible string and have them handled
>> > > > by the same code?
>> > > >>>
>> > > >>> Each CMU_BUSx domain of Exynos5433 have different base address as
>> > following:
>> > > >>> - CMU_BUS0's base address and range : 0x1360_ ~ 0x1360_0b04
>> > > >>> - CMU_BUS1's base address and range : 0x1480_ ~ 0x1480_0b04
>> > > >>> - CMU_BUS2's base address and range : 0x1340_ ~ 0x1340_0b04
>> > > >>>
>> > > >>> So, I implement CMU_BUSx domain which has each compatible string.
>> > > >
>> > > > But the base address is in the reg property, not in the compatible
>> > > > property. What I mean is to have multiple nodes like
>> > >
>> > > The merged clock driver in mainline have different compatible string
>> > > if base addresss of clock domain is different. So, I implemented each
>> > CMU_BUSx domain
>> > > with different compatible string.
>> >
>> > Why?
>>
>>
>> As I explained on below, each clock domain have different clocks.
>> So, clocks have unique clock name.
>>
>> If clock driver use only one compatible for various clock domain, clock
>> driver have to know the base address of each domain for distinction of
>> clock domain. I think It is stong dependency between device and driver.
>
> No, not at all. You can have lots of clock controllers with the same
> compatible string defining different instances of the same IP block,
> e.g. for compatible="fixed-clock".
But, "fixed-clock" pass all properties from dt file to
driver/clk/clk-fixed-rate.c.
and "fixed-clock" driver has not the data dependent on h/w. e.g.,
clock offset, parent clock.
>
>> >
>> > > > clock-controller@11360 {
>> > > > reg = <0 0x11360 0 0x1000>;
>> > > > compatible = "samsung,exynos5433-cmu";
>> > > > #clock-cells = <1>;
>> > > > };
>> > > >
>> > > > clock-controller@11480 {
>> > > > reg = <0 0x11480 0 0x1000>;
>> > > > compatible = "samsung,exynos5433-cmu";
>> > > > #clock-cells = <1>;
>> > > > };
>> > > >
>> > > > The code will just map the local registers for each instance and then
>> > > > provide the clocks of the right instance when asked for it.
>> > >
>> > > Each clock domain has not the same mux/divider/clock. So, just one
>> > compatible
>> > > string could not support all of clock domains.
>> >
>> > What are the specific differences?
>>
>>
>>
>> > I'm not sure that difference among clock domains because I think it is
>> dependent on the opinion of architect of SoC.
>>
>> cmu_bus0/1/2 are much similar. Just cmu_bus2 has one more mux/gate clock
>> than cmu_bus0/1.
>
> Yes, that's what I mean. You can simply model that extra mux/gate
> in the driver, as long as nothing ever tries to access the clock.
If only use one compatible to support CMU_BUSx domains,
I would implement it as following with Sylwester's guide.
To Sylwester, Tomaz,
Are you agree following method to support CMU_BUSx domains
by using one compatible string?
+/*
+ * Register offset definitions for CMU_BUS{0|1}
+ */
+#define DIV_BUS0x0600
+#define DIV_STAT_BUS0x0700
+#define ENABLE_ACLK_BUS0x0800
+#define ENABLE_PCLK_BUS0x0900
+#define ENABLE_IP_BUS00x0b00
+#define ENABLE_IP_BUS10x0b04
+
+#define bus_clk_regs(num)\
+static unsigned long bus##num_clk_regs[] __initdata = {\
+DIV_BUS,\
+DIV_STAT_BUS,\
+ENABLE_ACLK_BUS,\
+ENABLE_PCLK_BUS,\
+ENABLE_IP_BUS0,\
+ENABLE_IP_BUS1,\
+};\
+
+#define bus_div_clks(num)\
+static struct
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Friday 28 November 2014 00:17:40 Chanwoo Choi wrote:
>
> But, "fixed-clock" pass all properties from dt file to
> driver/clk/clk-fixed-rate.c.
> and "fixed-clock" driver has not the data dependent on h/w. e.g.,
> clock offset, parent clock.
The parent clocks would obviously have to be provided in DT if you
do this. I'm not sure what you mean with clock offsets. What would
it take to describe that?
> >> >
> >> > > > clock-controller@11360 {
> >> > > > reg = <0 0x11360 0 0x1000>;
> >> > > > compatible = "samsung,exynos5433-cmu";
> >> > > > #clock-cells = <1>;
> >> > > > };
> >> > > >
> >> > > > clock-controller@11480 {
> >> > > > reg = <0 0x11480 0 0x1000>;
> >> > > > compatible = "samsung,exynos5433-cmu";
> >> > > > #clock-cells = <1>;
> >> > > > };
> >> > > >
> >> > > > The code will just map the local registers for each instance and then
> >> > > > provide the clocks of the right instance when asked for it.
> >> > >
> >> > > Each clock domain has not the same mux/divider/clock. So, just one
> >> > compatible
> >> > > string could not support all of clock domains.
> >> >
> >> > What are the specific differences?
> >>
> >>
> >>
> >> > I'm not sure that difference among clock domains because I think it is
> >> dependent on the opinion of architect of SoC.
> >>
> >> cmu_bus0/1/2 are much similar. Just cmu_bus2 has one more mux/gate clock
> >> than cmu_bus0/1.
> >
> > Yes, that's what I mean. You can simply model that extra mux/gate
> > in the driver, as long as nothing ever tries to access the clock.
>
> If only use one compatible to support CMU_BUSx domains,
> I would implement it as following with Sylwester's guide.
>
> To Sylwester, Tomaz,
> Are you agree following method to support CMU_BUSx domains
> by using one compatible string?
> +#define bus_clk_regs(num)\
> +static unsigned long bus##num_clk_regs[] __initdata = {\
> +DIV_BUS,\
> +DIV_STAT_BUS,\
> +ENABLE_ACLK_BUS,\
> +ENABLE_PCLK_BUS,\
> +ENABLE_IP_BUS0,\
> +ENABLE_IP_BUS1,\
> +};\
I don't understand why you would need a macro here. Isn't this constant
data that you can pass into multiple devices? The use of macros
definitely makes it worse than the original patch.
> +#define bus_div_clks(num)\
> +static struct samsung_div_clock bus##num_div_clks[] __initdata = {\
> +/* DIV_BUS */\
> +DIV(CLK_DIV_PCLK_BUS##num_133, "div_pclk_bus"#num"_133",\
> +"aclk_bus"#num"_400", DIV_BUS##num, 0, 3),\
> +};\
To illustrate my point further: CLK_DIV_PCLK_BUS0/1/2 are all the
same, and so are DIV_BUS0/1/2, so you should not need to duplicate
the definitions at all but just call them 'CLK_DIV_PCLK_BUS'
and 'DIV_BUS'.
For the "aclk_bus"#num"_400" and "div_pclk_bus"#num"_133" strings,
I don't know what they refer to. Are you sure they have to be unique?
> +
> +#define bus_clk_regs(0)
> +#define bus_div_clks(0)
> +#define bus_gate_clks(0)
> +
> +#define bus_clk_regs(1)
> +#define bus_div_clks(1)
> +#define bus_gate_clks(1)
> +
> +static void __init exynos5433_cmu_bus_init(struct device_node *np)
> +{
> +void __iomem *reg_base_bus0, *reg_base_bus1;
> +
> +reg_base_bus0 = of_iomap(np, 0);
> +reg_base_bus1 = of_iomap(np, 1);
> +
> +bus0_ctx = samsung_clk_init(np, reg_base_bus0, BUS0_NR_CLKS);
> +bus1_ctx = samsung_clk_init(np, reg_base_bus0, BUS0_NR_CLKS);
> +
> +samsung_clk_register_div(bus0_ctx, bus0_div_clks,
> +ARRAY_SIZE(bus0_div_clks));
> +samsung_clk_register_gate(bus0_ctx, bus0_gate_clks,
> +ARRAY_SIZE(bus0_gate_clks));
> +samsung_clk_register_div(bus1_ctx, bus1_div_clks,
> +ARRAY_SIZE(bus1_div_clks));
> +samsung_clk_register_gate(bus1_ctx, bus1_gate_clks,
> +ARRAY_SIZE(bus1_gate_clks));
> +
> +samsung_clk_of_provider(np, bus0_ctx);
> +samsung_clk_of_provider(np, bus1_ctx);
> +
> +}
> +CLK_OF_DECLARE(exynos5433_cmu_bus, "samsung,exynos5433-cmu-bus",
> +exynos5433_cmu_bus_init);
This isn't helpful either: you really have two instances and should
not merge them together into one device node. This should look like
static void __init exynos5433_cmu_bus_init(struct device_node *np)
{
void __iomem *reg_base_bus;
reg_base_bus = of_iomap(np, 0);
bus_ctx = samsung_clk_init(np, reg_base_bus, BUS_NR_CLKS);
samsung_clk_register_div(bus_ctx, bus_div_clks,
ARRAY_SIZE(bus_div_clks));
samsung_clk_register_gate(bus_ctx, bus_gate_clks,
ARRAY_SIZE(bus_gate_clks));
samsung_clk_of_provider(np, bus0_ctx);
}
and get called three times.
Arnd
--
To unsubscribe from t
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Fri, Nov 28, 2014 at 12:33 AM, Arnd Bergmann wrote:
> On Friday 28 November 2014 00:17:40 Chanwoo Choi wrote:
>>
>> But, "fixed-clock" pass all properties from dt file to
>> driver/clk/clk-fixed-rate.c.
>> and "fixed-clock" driver has not the data dependent on h/w. e.g.,
>> clock offset, parent clock.
>
> The parent clocks would obviously have to be provided in DT if you
> do this. I'm not sure what you mean with clock offsets. What would
> it take to describe that?
>
>> >> >
>> >> > > > clock-controller@11360 {
>> >> > > > reg = <0 0x11360 0 0x1000>;
>> >> > > > compatible = "samsung,exynos5433-cmu";
>> >> > > > #clock-cells = <1>;
>> >> > > > };
>> >> > > >
>> >> > > > clock-controller@11480 {
>> >> > > > reg = <0 0x11480 0 0x1000>;
>> >> > > > compatible = "samsung,exynos5433-cmu";
>> >> > > > #clock-cells = <1>;
>> >> > > > };
>> >> > > >
>> >> > > > The code will just map the local registers for each instance and
>> >> > > > then
>> >> > > > provide the clocks of the right instance when asked for it.
>> >> > >
>> >> > > Each clock domain has not the same mux/divider/clock. So, just one
>> >> > compatible
>> >> > > string could not support all of clock domains.
>> >> >
>> >> > What are the specific differences?
>> >>
>> >>
>> >>
>> >> > I'm not sure that difference among clock domains because I think it is
>> >> dependent on the opinion of architect of SoC.
>> >>
>> >> cmu_bus0/1/2 are much similar. Just cmu_bus2 has one more mux/gate clock
>> >> than cmu_bus0/1.
>> >
>> > Yes, that's what I mean. You can simply model that extra mux/gate
>> > in the driver, as long as nothing ever tries to access the clock.
>>
>> If only use one compatible to support CMU_BUSx domains,
>> I would implement it as following with Sylwester's guide.
>>
>> To Sylwester, Tomaz,
>> Are you agree following method to support CMU_BUSx domains
>> by using one compatible string?
>
>
>> +#define bus_clk_regs(num)\
>> +static unsigned long bus##num_clk_regs[] __initdata = {\
>> +DIV_BUS,\
>> +DIV_STAT_BUS,\
>> +ENABLE_ACLK_BUS,\
>> +ENABLE_PCLK_BUS,\
>> +ENABLE_IP_BUS0,\
>> +ENABLE_IP_BUS1,\
>> +};\
>
> I don't understand why you would need a macro here. Isn't this constant
> data that you can pass into multiple devices? The use of macros
> definitely makes it worse than the original patch.
>
>> +#define bus_div_clks(num)\
>> +static struct samsung_div_clock bus##num_div_clks[] __initdata = {\
>> +/* DIV_BUS */\
>> +DIV(CLK_DIV_PCLK_BUS##num_133, "div_pclk_bus"#num"_133",\
>> +"aclk_bus"#num"_400", DIV_BUS##num, 0, 3),\
>> +};\
>
> To illustrate my point further: CLK_DIV_PCLK_BUS0/1/2 are all the
> same, and so are DIV_BUS0/1/2, so you should not need to duplicate
> the definitions at all but just call them 'CLK_DIV_PCLK_BUS'
> and 'DIV_BUS'.
CLK_DIV_PCLK_BUS0/1/2 is not all the same.
Each CLK_DIV_PCLK_BUS0/1/2 must need the unique clock number.
Because some device may need some clocks by using unique clock number.
>
> For the "aclk_bus"#num"_400" and "div_pclk_bus"#num"_133" strings,
> I don't know what they refer to. Are you sure they have to be unique?
Sure.
All clocks(mux/divider/gate) must need the unique clock number.
Best Regards,
Chanwoo Choi
>
>> +
>> +#define bus_clk_regs(0)
>> +#define bus_div_clks(0)
>> +#define bus_gate_clks(0)
>> +
>> +#define bus_clk_regs(1)
>> +#define bus_div_clks(1)
>> +#define bus_gate_clks(1)
>> +
>> +static void __init exynos5433_cmu_bus_init(struct device_node *np)
>> +{
>> +void __iomem *reg_base_bus0, *reg_base_bus1;
>> +
>> +reg_base_bus0 = of_iomap(np, 0);
>> +reg_base_bus1 = of_iomap(np, 1);
>> +
>> +bus0_ctx = samsung_clk_init(np, reg_base_bus0, BUS0_NR_CLKS);
>> +bus1_ctx = samsung_clk_init(np, reg_base_bus0, BUS0_NR_CLKS);
>> +
>> +samsung_clk_register_div(bus0_ctx, bus0_div_clks,
>> +ARRAY_SIZE(bus0_div_clks));
>> +samsung_clk_register_gate(bus0_ctx, bus0_gate_clks,
>> +ARRAY_SIZE(bus0_gate_clks));
>> +samsung_clk_register_div(bus1_ctx, bus1_div_clks,
>> +ARRAY_SIZE(bus1_div_clks));
>> +samsung_clk_register_gate(bus1_ctx, bus1_gate_clks,
>> +ARRAY_SIZE(bus1_gate_clks));
>> +
>> +samsung_clk_of_provider(np, bus0_ctx);
>> +samsung_clk_of_provider(np, bus1_ctx);
>> +
>> +}
>> +CLK_OF_DECLARE(exynos5433_cmu_bus, "samsung,exynos5433-cmu-bus",
>> +exynos5433_cmu_bus_init);
>
> This isn't helpful either: you really have two instances and should
> not merge them together into one device node. This should look like
>
> static void __init exynos5433_cmu_bus
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Friday 28 November 2014 00:44:07 Chanwoo Choi wrote:
> >
> >> +#define bus_div_clks(num)\
> >> +static struct samsung_div_clock bus##num_div_clks[] __initdata = {\
> >> +/* DIV_BUS */\
> >> +DIV(CLK_DIV_PCLK_BUS##num_133, "div_pclk_bus"#num"_133",\
> >> +"aclk_bus"#num"_400", DIV_BUS##num, 0, 3),\
> >> +};\
> >
> > To illustrate my point further: CLK_DIV_PCLK_BUS0/1/2 are all the
> > same, and so are DIV_BUS0/1/2, so you should not need to duplicate
> > the definitions at all but just call them 'CLK_DIV_PCLK_BUS'
> > and 'DIV_BUS'.
>
> CLK_DIV_PCLK_BUS0/1/2 is not all the same.
> Each CLK_DIV_PCLK_BUS0/1/2 must need the unique clock number.
> Because some device may need some clocks by using unique clock number.
This is from your original patch:
+/* CMU_BUS0 */
+#define CLK_DIV_PCLK_BUS0_133 1
+
+#define CLK_ACLK_AHB2APB_BUS0P 2
+#define CLK_ACLK_BUS0NP_1333
+#define CLK_ACLK_BUS0ND_4004
+#define CLK_PCLK_BUS0SRVND_133 5
+#define CLK_PCLK_PMU_BUS0 6
+#define CLK_PCLK_SYSREG_BUS0 7
+
+#define BUS0_NR_CLK8
+
+/* CMU_BUS1 */
+#define CLK_DIV_PCLK_BUS1_133 1
+
+#define CLK_ACLK_AHB2APB_BUS1P 2
+#define CLK_ACLK_BUS1NP_1333
+#define CLK_ACLK_BUS1ND_4004
+#define CLK_PCLK_BUS1SRVND_133 5
+#define CLK_PCLK_PMU_BUS1 6
+#define CLK_PCLK_SYSREG_BUS1 7
+
+#define BUS1_NR_CLK8
+
+/* CMU_BUS2 */
+#define CLK_MOUT_ACLK_BUS2_400_USER1
+
+#define CLK_DIV_PCLK_BUS2_133 2
+
+#define CLK_ACLK_AHB2APB_BUS2P 3
+#define CLK_ACLK_BUS2NP_1334
+#define CLK_ACLK_BUS2BEND_400 5
+#define CLK_ACLK_BUS2RTND_400 6
+#define CLK_PCLK_BUS2SRVND_133 7
+#define CLK_PCLK_PMU_BUS2 8
+#define CLK_PCLK_SYSREG_BUS2 9
+
+#define BUS2_NR_CLK10
The numbers are arbitrarily assigned, but for bus0 and bus1,
they are all identical, while bus2 uses a lightly different
numbering, which you could easily change, e.g. by using the
numbers you have for bus2 on bus0 and bus1 as well.
+ * Register offset definitions for CMU_BUS0
+ */
+#define DIV_BUS0 0x0600
+#define DIV_STAT_BUS0 0x0700
+#define ENABLE_ACLK_BUS0 0x0800
+#define ENABLE_PCLK_BUS0 0x0900
+#define ENABLE_IP_BUS0 0x0b00
+#define ENABLE_IP_BUS1 0x0b04
+
+/*
+ * Register offset definitions for CMU_BUS1
+ */
+#define DIV_BUS1 0x0600
+#define DIV_STAT_BUS1 0x0700
+#define ENABLE_ACLK_BUS1 0x0800
+#define ENABLE_PCLK_BUS1 0x0900
+#define ENABLE_IP_BUS100x0b00
+#define ENABLE_IP_BUS110x0b04
+/*
+ * Register offset definitions for CMU_BUS2
+ */
+#define MUX_SEL_BUS2 0x0200
+#define MUX_ENABLE_BUS20x0300
+#define MUX_STAT_BUS2 0x0400
+#define DIV_BUS2 0x0600
+#define DIV_STAT_BUS2 0x0700
+#define ENABLE_ACLK_BUS2 0x0800
+#define ENABLE_PCLK_BUS2 0x0900
+#define ENABLE_IP_BUS200x0b00
+#define ENABLE_IP_BUS210x0b04
More importantly, the register offsets are all identical, except that
bus2 has the additional MUX_SEL and MUX_ENABLE definitions. It's very
obvious that this is the same hardware block in multiple instances.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2} domains
On Fri, Nov 28, 2014 at 12:51 AM, Arnd Bergmann wrote:
> On Friday 28 November 2014 00:44:07 Chanwoo Choi wrote:
>> >
>> >> +#define bus_div_clks(num)\
>> >> +static struct samsung_div_clock bus##num_div_clks[] __initdata = {\
>> >> +/* DIV_BUS */\
>> >> +DIV(CLK_DIV_PCLK_BUS##num_133, "div_pclk_bus"#num"_133",\
>> >> +"aclk_bus"#num"_400", DIV_BUS##num, 0, 3),\
>> >> +};\
>> >
>> > To illustrate my point further: CLK_DIV_PCLK_BUS0/1/2 are all the
>> > same, and so are DIV_BUS0/1/2, so you should not need to duplicate
>> > the definitions at all but just call them 'CLK_DIV_PCLK_BUS'
>> > and 'DIV_BUS'.
>>
>> CLK_DIV_PCLK_BUS0/1/2 is not all the same.
>> Each CLK_DIV_PCLK_BUS0/1/2 must need the unique clock number.
>> Because some device may need some clocks by using unique clock number.
>
> This is from your original patch:
>
> +/* CMU_BUS0 */
> +#define CLK_DIV_PCLK_BUS0_133 1
> +
> +#define CLK_ACLK_AHB2APB_BUS0P 2
> +#define CLK_ACLK_BUS0NP_1333
> +#define CLK_ACLK_BUS0ND_4004
> +#define CLK_PCLK_BUS0SRVND_133 5
> +#define CLK_PCLK_PMU_BUS0 6
> +#define CLK_PCLK_SYSREG_BUS0 7
> +
> +#define BUS0_NR_CLK8
> +
> +/* CMU_BUS1 */
> +#define CLK_DIV_PCLK_BUS1_133 1
> +
> +#define CLK_ACLK_AHB2APB_BUS1P 2
> +#define CLK_ACLK_BUS1NP_1333
> +#define CLK_ACLK_BUS1ND_4004
> +#define CLK_PCLK_BUS1SRVND_133 5
> +#define CLK_PCLK_PMU_BUS1 6
> +#define CLK_PCLK_SYSREG_BUS1 7
> +
> +#define BUS1_NR_CLK8
> +
> +/* CMU_BUS2 */
> +#define CLK_MOUT_ACLK_BUS2_400_USER1
> +
> +#define CLK_DIV_PCLK_BUS2_133 2
> +
> +#define CLK_ACLK_AHB2APB_BUS2P 3
> +#define CLK_ACLK_BUS2NP_1334
> +#define CLK_ACLK_BUS2BEND_400 5
> +#define CLK_ACLK_BUS2RTND_400 6
> +#define CLK_PCLK_BUS2SRVND_133 7
> +#define CLK_PCLK_PMU_BUS2 8
> +#define CLK_PCLK_SYSREG_BUS2 9
> +
> +#define BUS2_NR_CLK10
>
>
> The numbers are arbitrarily assigned, but for bus0 and bus1,
> they are all identical, while bus2 uses a lightly different
> numbering, which you could easily change, e.g. by using the
> numbers you have for bus2 on bus0 and bus1 as well.
OK, I'll remove duplicate clock number due to the same on other clock domain.
If use only CLK_DIV_PCLK_BUS instead of CLK_DIV_PCLK_BUS0/1/2,
I think I have to use three compatible string for each CMU_BUSx domain
as following:.
clocks = <&cmu_bus0 CLK_DIV_PCLK_BUS>;
clocks = <&cmu_bus1 CLK_DIV_PCLK_BUS>;
clocks = <&cmu_bus2 CLK_DIV_PCLK_BUS>;
>
> + * Register offset definitions for CMU_BUS0
> + */
> +#define DIV_BUS0 0x0600
> +#define DIV_STAT_BUS0 0x0700
> +#define ENABLE_ACLK_BUS0 0x0800
> +#define ENABLE_PCLK_BUS0 0x0900
> +#define ENABLE_IP_BUS0 0x0b00
> +#define ENABLE_IP_BUS1 0x0b04
> +
>
> +/*
> + * Register offset definitions for CMU_BUS1
> + */
> +#define DIV_BUS1 0x0600
> +#define DIV_STAT_BUS1 0x0700
> +#define ENABLE_ACLK_BUS1 0x0800
> +#define ENABLE_PCLK_BUS1 0x0900
> +#define ENABLE_IP_BUS100x0b00
> +#define ENABLE_IP_BUS110x0b04
>
> +/*
> + * Register offset definitions for CMU_BUS2
> + */
> +#define MUX_SEL_BUS2 0x0200
> +#define MUX_ENABLE_BUS20x0300
> +#define MUX_STAT_BUS2 0x0400
> +#define DIV_BUS2 0x0600
> +#define DIV_STAT_BUS2 0x0700
> +#define ENABLE_ACLK_BUS2 0x0800
> +#define ENABLE_PCLK_BUS2 0x0900
> +#define ENABLE_IP_BUS200x0b00
> +#define ENABLE_IP_BUS210x0b04
>
> More importantly, the register offsets are all identical, except that
> bus2 has the additional MUX_SEL and MUX_ENABLE definitions. It's very
> obvious that this is the same hardware block in multiple instances.
You're right. I'll remove duplicate offset definition.
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PM / Domains: Add pm_genpd_lookup() API to lookup domain by device node
On Thursday, November 27, 2014 03:14:13 PM Ulf Hansson wrote:
> In a step to move away from using genpd's name based APIs, such as the
> pm_genpd_add_subdomain_names(), provide an API to lookup an already
> initialized generic PM domain by its device node.
>
> This API would typically be a called from SOC specific code, to fetch a
> handle to the domain. Especially convenient to configure subdomains and
> when the hierarchy of the domains are described in DT.
>
> Do note, before pm_genpd_init() is invoked to initialize a generic PM
> domain, it's the callers responsibility to assign the new ->dev_node
> pointer in the struct generic_pm_domain, to enable pm_genpd_lookup() to
> find the domain.
>
> Signed-off-by: Ulf Hansson
> ---
>
> The background to why I propose this patch comes from a discussion around the
> below patchset:
> https://lkml.org/lkml/2014/11/24/290
>
>
> ---
> drivers/base/power/domain.c | 26 ++
> include/linux/pm_domain.h | 2 ++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 735c473..34555eb 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -75,6 +75,32 @@ struct generic_pm_domain *dev_to_genpd(struct device *dev)
> return pd_to_genpd(dev->pm_domain);
> }
>
> +/**
> + * pm_genpd_lookup - Fetch a generic PM domain object by device node
> + * @node: Device node to a corresponding genpd.
> + *
> + * Returns a valid pointer to struct generic_pm_domain on success or
> ERR_PTR()
> + * on failure.
> + */
> +struct generic_pm_domain *pm_genpd_lookup(struct device_node *node)
> +{
> + struct generic_pm_domain *genpd = ERR_PTR(-ENOENT), *gpd;
> +
> + if (IS_ERR_OR_NULL(node))
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(&gpd_list_lock);
> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
> + if (gpd->dev_node == node) {
> + genpd = gpd;
> + break;
> + }
> + }
> + mutex_unlock(&gpd_list_lock);
> + return genpd;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_lookup);
> +
> static int genpd_stop_dev(struct generic_pm_domain *genpd, struct device
> *dev)
> {
> return GENPD_DEV_TIMED_CALLBACK(genpd, int, stop, dev,
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 8cbd32e..322cb7c 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -53,6 +53,7 @@ struct generic_pm_domain {
> struct dev_power_governor *gov;
> struct work_struct power_off_work;
> const char *name;
> + struct device_node *dev_node; /* Device node for the PM domain */
Please don't add DT-specific members to generic data structures.
You can use struct fwnode_handle (currently in linux-next) instead.
> unsigned int in_progress; /* Number of devices being suspended
> now */
> atomic_t sd_count; /* Number of subdomains with power "on" */
> enum gpd_status status; /* Current state of the domain */
> @@ -126,6 +127,7 @@ static inline struct generic_pm_domain_data
> *dev_gpd_data(struct device *dev)
> }
>
> extern struct generic_pm_domain *dev_to_genpd(struct device *dev);
> +extern struct generic_pm_domain *pm_genpd_lookup(struct device_node *node);
> extern int __pm_genpd_add_device(struct generic_pm_domain *genpd,
>struct device *dev,
>struct gpd_timing_data *td);
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drm/exynos: Add DECON driver
Hi Ajay,
On 27 November 2014 at 19:41, Ajay Kumar wrote:
> This series is based on exynos-drm-next branch of Inki Dae's tree at:
> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>
> DECON(Display and Enhancement Controller) is the new IP
> in exynos7 SOC for generating video signals using pixel data.
>
> DECON driver can be used to drive 2 different interfaces on Exynos7:
> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>
> The existing FIMD driver code was used as a template to create
> DECON driver. Only DECON-INT is supported as of now, and
> DECON-EXT support will be added later.
>
> Signed-off-by: Akshu Agrawal
> Signed-off-by: Ajay Kumar
> ---
> .../devicetree/bindings/video/exynos7-decon.txt| 67 ++
> drivers/gpu/drm/exynos/Kconfig | 13 +-
> drivers/gpu/drm/exynos/Makefile|1 +
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1029
>
> drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
> drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
> include/video/exynos7_decon.h | 346 +++
> 7 files changed, 1458 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
> create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
> create mode 100644 include/video/exynos7_decon.h
>
> diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
> b/Documentation/devicetree/bindings/video/exynos7-decon.txt
> new file mode 100644
> index 000..14db519
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
> @@ -0,0 +1,67 @@
> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
> +
> +DECON (Display and Enhancement Controller) is the Display Controller for the
> +Exynos7 series of SoCs which transfers the image data from a video memory
> +buffer to an external LCD interface.
> +
> +Required properties:
> +- compatible: value should be "samsung,exynos7-decon";
> +
> +- reg: physical base address and length of the DECON registers set.
> +
> +- interrupt-parent: should be the phandle of the decon controller's
> + parent interrupt controller.
> +
> +- interrupts: should contain a list of all DECON IP block interrupts in the
> +order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier
> +format depends on the interrupt controller used.
> +
> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
> + "lcd_sys", in the same order as they were listed in the interrupts
> +property.
> +
> +- pinctrl-0: pin control group to be used for this controller.
> +
> +- pinctrl-names: must contain a "default" entry.
> +
> +- clocks: must include clock specifiers corresponding to entries in the
> + clock-names property.
> +
> +- clock-names: list of clock names sorted in the same order as the clocks
> + property. Must contain "pclk_decon0", "aclk_decon0",
> + "decon0_eclk", "decon0_vclk".
> +
> +Optional Properties:
> +- samsung,power-domain: a phandle to DECON power domain node.
> +- display-timings: timing settings for FIMD, as described in document [1].
> + Can be used in case timings cannot be provided otherwise
> + or to override timings provided by the panel.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +
> +Example:
> +
> +SoC specific DT entry:
> +
> + decon@1393 {
> + compatible = "samsung,exynos7-decon";
> + interrupt-parent = <&combiner>;
> + reg = <0x1393 0x1000>;
> + interrupt-names = "lcd_sys", "vsync", "fifo";
> + interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
> + clocks = <&clock_disp PCLK_DECON_INT>,
> +<&clock_disp ACLK_DECON_INT>,
> +<&clock_disp SCLK_DECON_INT_ECLK>,
> +<&clock_disp SCLK_DECON_INT_EXTCLKPLL>;
> + clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
> + "decon0_vclk";
> + status = "disabled";
> + };
> +
> +Board specific DT entry:
> +
> + decon@1393 {
> + pinctrl-0 = <&lcd_clk &pwm1_out>;
> + pinctrl-names = "default";
> + status = "okay";
> + };
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> index 7f9f6f9..d3434cb 100644
> --- a/drivers/gpu/drm/exynos/Kconfig
> +++ b/drivers/gpu/drm/exynos/Kconfig
> @@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
> help
> Choose this option if you want to use Exynos FIMD for DRM.
>
> +config DRM_EXYNOS_DECON
> + bool "Exynos DRM DECON"
> + depends on DRM_EXYNOS
> + select FB_MODE_HELPERS
> + help
> + Choose this option if you want to use Exynos DEC
[PATCH v2 2/2] cpuidle: exynos: add coupled cpuidle support for Exynos4210
The following patch adds coupled cpuidle support for Exynos4210 to
an existing cpuidle-exynos driver. As a result it enables AFTR mode
to be used by default on Exynos4210 without the need to hot unplug
CPU1 first.
The patch is heavily based on earlier cpuidle-exynos4210 driver from
Daniel Lezcano:
http://www.spinics.net/lists/linux-samsung-soc/msg28134.html
Changes from Daniel's code include:
- porting code to current kernels
- fixing it to work on my setup (by using S5P_INFORM register
instead of S5P_VA_SYSRAM one on Revison 1.1 and retrying poking
CPU1 out of the BOOT ROM if necessary)
- fixing rare lockup caused by waiting for CPU1 to get stuck in
the BOOT ROM (CPU hotplug code in arch/arm/mach-exynos/platsmp.c
doesn't require this and works fine)
- moving Exynos specific code to arch/arm/mach-exynos/pm.c
- using cpu_boot_reg_base() helper instead of BOOT_VECTOR macro
- using exynos_cpu_*() helpers instead of accessing registers
directly
- using arch_send_wakeup_ipi_mask() instead of dsb_sev()
(this matches CPU hotplug code in arch/arm/mach-exynos/platsmp.c)
- integrating separate exynos4210-cpuidle driver into existing
exynos-cpuidle one
Cc: Colin Cross
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Daniel Lezcano
Acked-by: Kyungmin Park
---
v2:
- added Signed-off-by from Daniel Lezcano
- added separate struct cpuidle_driver exynos_coupled_idle_driver
arch/arm/mach-exynos/common.h| 4 +
arch/arm/mach-exynos/exynos.c| 4 +
arch/arm/mach-exynos/platsmp.c | 2 +-
arch/arm/mach-exynos/pm.c| 122 +++
drivers/cpuidle/Kconfig.arm | 1 +
drivers/cpuidle/cpuidle-exynos.c | 77 +++--
include/linux/platform_data/cpuidle-exynos.h | 20 +
7 files changed, 224 insertions(+), 6 deletions(-)
create mode 100644 include/linux/platform_data/cpuidle-exynos.h
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index 865f878..f70eca7 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -13,6 +13,7 @@
#define __ARCH_ARM_MACH_EXYNOS_COMMON_H
#include
+#include
#define EXYNOS3250_SOC_ID 0xE3472000
#define EXYNOS3_SOC_MASK 0xF000
@@ -150,8 +151,11 @@ extern void exynos_pm_central_suspend(void);
extern int exynos_pm_central_resume(void);
extern void exynos_enter_aftr(void);
+extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
+
extern void s5p_init_cpu(void __iomem *cpuid_addr);
extern unsigned int samsung_rev(void);
+extern void __iomem *cpu_boot_reg_base(void);
static inline void pmu_raw_writel(u32 val, u32 offset)
{
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index c13d083..509f2e5 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -246,6 +246,10 @@ static void __init exynos_dt_machine_init(void)
if (!IS_ENABLED(CONFIG_SMP))
exynos_sysram_init();
+#ifdef CONFIG_ARM_EXYNOS_CPUIDLE
+ if (of_machine_is_compatible("samsung,exynos4210"))
+ exynos_cpuidle.dev.platform_data = &cpuidle_coupled_exynos_data;
+#endif
if (of_machine_is_compatible("samsung,exynos4210") ||
of_machine_is_compatible("samsung,exynos4212") ||
(of_machine_is_compatible("samsung,exynos4412") &&
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index 7a1ebfe..3f32c47 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -194,7 +194,7 @@ int exynos_cluster_power_state(int cluster)
S5P_CORE_LOCAL_PWR_EN);
}
-static inline void __iomem *cpu_boot_reg_base(void)
+void __iomem *cpu_boot_reg_base(void)
{
if (soc_is_exynos4210() && samsung_rev() == EXYNOS4210_REV_1_1)
return pmu_base_addr + S5P_INFORM5;
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 159eb4c..1f9cbd4 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -179,3 +179,125 @@ void exynos_enter_aftr(void)
cpu_pm_exit();
}
+
+static atomic_t cpu1_wakeup = ATOMIC_INIT(0);
+
+static int exynos_cpu0_enter_aftr(void)
+{
+ int ret = -1;
+
+ /*
+* If the other cpu is powered on, we have to power it off, because
+* the AFTR state won't work otherwise
+*/
+ if (cpu_online(1)) {
+ /*
+* We reach a sync point with the coupled idle state, we know
+* the other cpu will power down itself or will abort the
+* sequence, let's wait for one of these to happen
+*/
+ while (exynos_cpu_power_state(1)) {
+ /*
+* The other cpu may skip idle and boot back
+* up again
+*/
+
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
Hi Kevin,
On Thu, Nov 27, 2014 at 12:11 AM, Nicolas Pitre
wrote:
> On Wed, 26 Nov 2014, Kevin Hilman wrote:
>
>> Abhilash Kesavan writes:
>>
>> > Hi Kevin,
>> >
>> > On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman wrote:
>> >> [...]
>> >>
>> >> More specifically, with only the loopback call to turn off CCI commented
>> >> out, the imprecise aborts go away.
>> >
>> > I can't see how enabling snoops for the boot cluster is causing these
>> > aborts. Perhaps as Krzysztof commented it has something to do with the
>> > secure firmware/tz software on these boards ? Other than there does
>> > not appear to be any difference between the working/non-working
>> > setups.
>>
>> Perhaps the secure firmware is preventing the CCI to be enabled by the
>> kernel, and that is causing the imprecise abort?
>
> That is well possible.
>
> Now.. if the bootloader/firmware does not let Linux deal with both
> the CCI and caches then MCPM simply has no more purpose for this board.
> The whole point of MCPM is actually to handle the CCI properly and the
> most efficient way despite all the possible races and opportunities for
> memory corruptions. And yes, this is a complex task.
>
> So there is actually two choices: the firmware let Linux take care of it
> via the MCPM layer (easy), or the firmware has to implement it all
> _properly_ (hard) behind an interface such as PSCI, at which point MCPM
> should be configured out.
>
> If the firmware does not let Linux interact with the CCI _and_ does not
> implement full MCPM-like services then the platform is broken and only a
> firmware upgrade could fix that. It might still be possible to boot all
> CPUs through other means, but power management would then be severely
> limited.
How about restricting the mcpm initialization to only known working
boards like chromebooks and smdk. This would be better than disabling
the config altogether from exynos_defconfig. The non-working boards
would then default to platsmp. Assuming that the firmware handles all
CCI/cache activities then platsmp may work for secondary core boot-up
?
Can you please apply the below diff and test the non-working boards
with CONFIG_EXYNOS5420_MCPM enabled.
diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
b/arch/arm/mach-exynos/mcpm-exynos.c
index b0d3c2e..34d77bb 100644
--- a/arch/arm/mach-exynos/mcpm-exynos.c
+++ b/arch/arm/mach-exynos/mcpm-exynos.c
@@ -316,8 +316,9 @@ static void __init exynos_cache_off(void)
}
static const struct of_device_id exynos_dt_mcpm_match[] = {
- { .compatible = "samsung,exynos5420" },
- { .compatible = "samsung,exynos5800" },
+ { .compatible = "samsung,smdk5420" },
+ { .compatible = "google,pi" },
+ { .compatible = "google,pit" },
{},
};
On a different note, I did not see any mainline support for Odroid
Xu3, are you testing this board with a non-mainline kernel ?
Regards,
Abhilash
>
>
>
> Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] cpuidle: exynos: add coupled cpuidle support for Exynos4210
Hi, The following patchset adds coupled cpuidle support for Exynos4210 to an existing cpuidle-exynos driver. As a result it enables AFTR mode to be used by default on Exynos4210 without the need to hot unplug CPU1 first. This work is heavily based on earlier cpuidle-exynos4210 driver from Daniel Lezcano: http://www.spinics.net/lists/linux-samsung-soc/msg28134.html Changes from Daniel's code include: - porting code to current kernels - fixing it to work on my setup (by using S5P_INFORM register instead of S5P_VA_SYSRAM one on Revison 1.1 and retrying poking CPU1 out of the BOOT ROM if necessary) - fixing rare lockup caused by waiting for CPU1 to get stuck in the BOOT ROM (CPU hotplug code in arch/arm/mach-exynos/platsmp.c doesn't require this and works fine) - moving Exynos specific code to arch/arm/mach-exynos/pm.c - using cpu_boot_reg_base() helper instead of BOOT_VECTOR macro - using exynos_cpu_*() helpers instead of accessing registers directly - using arch_send_wakeup_ipi_mask() instead of dsb_sev() (this matches CPU hotplug code in arch/arm/mach-exynos/platsmp.c) - integrating separate exynos4210-cpuidle driver into existing exynos-cpuidle one patch #1 is a fix for Exynos platform PM code preparing it for coupled cpuidle support patch #2 adds coupled cpuidle AFTR mode for Exynos4210 The patchset depends on: - for-next branch (760a7d4763c8) of linux-samsung.git kernel tree v2: - rebased on top of for-next branch (commit: 760a7d4763c8) of linux-samsung.git kernel tree (the patchset also applies fine to next-20141126 branch of linux-next kernel tree but needs CPUIDLE_FLAG_TIME_VALID flag usage removed to fix build) - added Signed-off-by from Daniel Lezcano to patch #2 - added separate struct cpuidle_driver exynos_coupled_idle_driver Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (2): ARM: EXYNOS: apply S5P_CENTRAL_SEQ_OPTION fix only when necessary cpuidle: exynos: add coupled cpuidle support for Exynos4210 arch/arm/mach-exynos/common.h| 4 + arch/arm/mach-exynos/exynos.c| 4 + arch/arm/mach-exynos/platsmp.c | 2 +- arch/arm/mach-exynos/pm.c| 133 ++- arch/arm/mach-exynos/suspend.c | 4 + drivers/cpuidle/Kconfig.arm | 1 + drivers/cpuidle/cpuidle-exynos.c | 77 +++- include/linux/platform_data/cpuidle-exynos.h | 20 8 files changed, 235 insertions(+), 10 deletions(-) create mode 100644 include/linux/platform_data/cpuidle-exynos.h -- 1.8.2.3 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: EXYNOS: apply S5P_CENTRAL_SEQ_OPTION fix only when necessary
Commit c2dd114d2486 ("ARM: EXYNOS: fix register setup for AFTR mode
code") added S5P_CENTRAL_SEQ_OPTION register setup fix for all
Exynos SoCs to AFTR mode code-path. It turned out that for coupled
cpuidle AFTR mode on Exynos4210 (added by the next patch) applying
this fix causes lockup so enable it in the AFTR mode code-path only
on SoCs that require it (in the suspend code-path it can be always
applied like it was before commit c2dd114d2486).
Cc: Daniel Lezcano
Cc: Colin Cross
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Tomasz Figa
Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Kyungmin Park
---
v2:
- no changes
arch/arm/mach-exynos/pm.c | 11 +++
arch/arm/mach-exynos/suspend.c | 4
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c
index 86f3ecd8..159eb4c 100644
--- a/arch/arm/mach-exynos/pm.c
+++ b/arch/arm/mach-exynos/pm.c
@@ -97,10 +97,6 @@ void exynos_pm_central_suspend(void)
tmp = pmu_raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
tmp &= ~S5P_CENTRAL_LOWPWR_CFG;
pmu_raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
-
- /* Setting SEQ_OPTION register */
- pmu_raw_writel(S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0,
- S5P_CENTRAL_SEQ_OPTION);
}
int exynos_pm_central_resume(void)
@@ -164,6 +160,13 @@ void exynos_enter_aftr(void)
exynos_pm_central_suspend();
+ if (of_machine_is_compatible("samsung,exynos4212") ||
+ of_machine_is_compatible("samsung,exynos4412")) {
+ /* Setting SEQ_OPTION register */
+ pmu_raw_writel(S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0,
+ S5P_CENTRAL_SEQ_OPTION);
+ }
+
cpu_suspend(0, exynos_aftr_finisher);
if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index f8e7dcd..9c67a15 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -282,6 +282,10 @@ static int exynos_pm_suspend(void)
{
exynos_pm_central_suspend();
+ /* Setting SEQ_OPTION register */
+ pmu_raw_writel(S5P_USE_STANDBY_WFI0 | S5P_USE_STANDBY_WFE0,
+ S5P_CENTRAL_SEQ_OPTION);
+
if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9)
exynos_cpu_save_register();
--
1.8.2.3
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On Thu, 27 Nov 2014, Abhilash Kesavan wrote:
> Hi Kevin,
>
> On Thu, Nov 27, 2014 at 12:11 AM, Nicolas Pitre
> wrote:
> > On Wed, 26 Nov 2014, Kevin Hilman wrote:
> >
> >> Abhilash Kesavan writes:
> >>
> >> > Hi Kevin,
> >> >
> >> > On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman wrote:
> >> >> [...]
> >> >>
> >> >> More specifically, with only the loopback call to turn off CCI commented
> >> >> out, the imprecise aborts go away.
> >> >
> >> > I can't see how enabling snoops for the boot cluster is causing these
> >> > aborts. Perhaps as Krzysztof commented it has something to do with the
> >> > secure firmware/tz software on these boards ? Other than there does
> >> > not appear to be any difference between the working/non-working
> >> > setups.
> >>
> >> Perhaps the secure firmware is preventing the CCI to be enabled by the
> >> kernel, and that is causing the imprecise abort?
> >
> > That is well possible.
> >
> > Now.. if the bootloader/firmware does not let Linux deal with both
> > the CCI and caches then MCPM simply has no more purpose for this board.
> > The whole point of MCPM is actually to handle the CCI properly and the
> > most efficient way despite all the possible races and opportunities for
> > memory corruptions. And yes, this is a complex task.
> >
> > So there is actually two choices: the firmware let Linux take care of it
> > via the MCPM layer (easy), or the firmware has to implement it all
> > _properly_ (hard) behind an interface such as PSCI, at which point MCPM
> > should be configured out.
> >
> > If the firmware does not let Linux interact with the CCI _and_ does not
> > implement full MCPM-like services then the platform is broken and only a
> > firmware upgrade could fix that. It might still be possible to boot all
> > CPUs through other means, but power management would then be severely
> > limited.
>
> How about restricting the mcpm initialization to only known working
> boards like chromebooks and smdk. This would be better than disabling
> the config altogether from exynos_defconfig. The non-working boards
> would then default to platsmp. Assuming that the firmware handles all
> CCI/cache activities then platsmp may work for secondary core boot-up
> ?
>
> Can you please apply the below diff and test the non-working boards
> with CONFIG_EXYNOS5420_MCPM enabled.
I'd much prefer if the CCI is non accessible on some board that the
device tree file for that board be modified instead by marking the CCI
as unavailable.
>
> diff --git a/arch/arm/mach-exynos/mcpm-exynos.c
> b/arch/arm/mach-exynos/mcpm-exynos.c
> index b0d3c2e..34d77bb 100644
> --- a/arch/arm/mach-exynos/mcpm-exynos.c
> +++ b/arch/arm/mach-exynos/mcpm-exynos.c
> @@ -316,8 +316,9 @@ static void __init exynos_cache_off(void)
> }
>
> static const struct of_device_id exynos_dt_mcpm_match[] = {
> - { .compatible = "samsung,exynos5420" },
> - { .compatible = "samsung,exynos5800" },
> + { .compatible = "samsung,smdk5420" },
> + { .compatible = "google,pi" },
> + { .compatible = "google,pit" },
> {},
> };
>
> On a different note, I did not see any mainline support for Odroid
> Xu3, are you testing this board with a non-mainline kernel ?
>
> Regards,
> Abhilash
> >
> >
> >
> > Nicolas
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/7] regulator: dt-bindings: Document the ena-gpios property
On Thu, Nov 27, 2014 at 12:20:48PM +0100, Krzysztof Kozlowski wrote: > +- ena-gpios: GPIO to use for enable control. Actual implementation depends > + on regulator driver. The bindings documentation for given driver describes > + which regulator actually supports it. > +- ena-gpio-open-drain: GPIO is open drain type. I'm relly not a big fan of adding a fixed name property here with no override capability, it means that the naming won't reflect the specific regulator design so closely and in practice for many of the PMICs the GPIO control can do rather more than just control enables and supports reprogramming. The latter case where we've got a signal which can sometimes be simply and enable but sometimes more makes it especially worrying to have the property always be there, it's something that might work in some configurations but could easily be broken if we try to exploit more advanced functionality (things also triggering other configuration changes at the same time). Factoring out the code is good but it seems better to have it be something which drivers can control, for example by having them explicitly specify a property name to use or perhaps a flag to enable the default name. We also need an invert option. signature.asc Description: Digital signature
Re: [PATCH v4 4/7] regulator: Use ena_gpio supplied with generic regulator bindings
On Thu, Nov 27, 2014 at 12:20:50PM +0100, Krzysztof Kozlowski wrote:
> Use ena_gpio from regulator constraints (filled by parsing generic
> bindings) to initialize the GPIO enable control. Support also the old
> way: ena_gpio supplied in regulator_config structure.
>
> This also adds a new set_ena_gpio() callback in regulator_ops structure
> which driver may provide to actually enable the GPIO control in
> hardware.
This seems really confused like it's trying to work around some other
problem - this all feels like it's at the wrong abstraction level. As
far as I can tell this is trying to fix bugs in the previous patch and
do some other refactorings (the "also add this other random op" bit
especially) but I'm really not clear what the goal is.
Please try to think if the code you're writing makes sense at the big
picture level rather than just band aiding specific problems you see.
It's also a good idea to keep random code motion separate from
functional changes since it makes it much easier to follow what each is
supposed to do.
> @@ -1044,6 +1045,14 @@ static int set_machine_constraints(struct
> regulator_dev *rdev,
> }
> }
>
> + if (rdev->constraints->use_ena_gpio && ops->set_ena_gpio) {
> + ret = ops->set_ena_gpio(rdev);
> + if (ret < 0) {
> + rdev_err(rdev, "failed to set enable GPIO control\n");
> + goto out;
> + }
> + }
Why do we need some special magic operation for GPIO based enables
that's separate to any other enable operation? This seems really
confusing, if the constraint setting doesn't work somehow for GPIO based
enables we should fix that. Though since this operation takes no
parameters it's hard to see how it's supposed to apply constraints
unless it reparses them which doesn't seem like a good idea...
> static int regulator_ena_gpio_request(struct regulator_dev *rdev,
> - const struct regulator_config *config)
> - ret = gpio_request_one(config->ena_gpio,
> - GPIOF_DIR_OUT | config->ena_gpio_flags,
> + ret = gpio_request_one(gpio, GPIOF_DIR_OUT | gpio_flags,
> rdev_get_name(rdev));
> +/*
> + * Request GPIO for enable control from regulator_config
> + * or init_data->constraints.
> + */
> +static int regulator_ena_gpio_setup(struct regulator_dev *rdev,
> + const struct regulator_config *config,
> + const struct regulator_init_data *init_data)
Why is setting up the GPIO different to requesting it, especially given
that we have an existing function called _request() which still exists?
signature.asc
Description: Digital signature
Re: [PATCH v4 3/7] regulator: of: Parse ena-gpios property from DTS
On Thu, Nov 27, 2014 at 12:20:49PM +0100, Krzysztof Kozlowski wrote:
> + constraints->ena_gpio = of_get_named_gpio_flags(np, "ena-gpios", 0,
> + &gpio_flags);
> + if (gpio_is_valid(constraints->ena_gpio)) {
No, this isn't sensible - in what way would an enable control GPIO be a
constraint? The whole reason we have separate constraint and config
structures is that these are different things. Keep the GPIO setup in
the configuration.
signature.asc
Description: Digital signature
Re: [PATCH] ARM: exynos_defconfig: disable CONFIG_EXYNOS5420_MCPM; not stable
On 26/11/14 18:41, Nicolas Pitre wrote: On Wed, 26 Nov 2014, Kevin Hilman wrote: Abhilash Kesavan writes: Hi Kevin, On Wed, Nov 26, 2014 at 6:30 AM, Kevin Hilman wrote: [...] More specifically, with only the loopback call to turn off CCI commented out, the imprecise aborts go away. I can't see how enabling snoops for the boot cluster is causing these aborts. Perhaps as Krzysztof commented it has something to do with the secure firmware/tz software on these boards ? Other than there does not appear to be any difference between the working/non-working setups. Perhaps the secure firmware is preventing the CCI to be enabled by the kernel, and that is causing the imprecise abort? That is well possible. Now.. if the bootloader/firmware does not let Linux deal with both the CCI and caches then MCPM simply has no more purpose for this board. The whole point of MCPM is actually to handle the CCI properly and the most efficient way despite all the possible races and opportunities for memory corruptions. And yes, this is a complex task. So there is actually two choices: the firmware let Linux take care of it via the MCPM layer (easy), or the firmware has to implement it all _properly_ (hard) behind an interface such as PSCI, at which point MCPM should be configured out. If the firmware does not let Linux interact with the CCI _and_ does not implement full MCPM-like services then the platform is broken and only a firmware upgrade could fix that. It might still be possible to boot all CPUs through other means, but power management would then be severely limited. Thanks Nico for the detailed description on the requirements for using MCPM. This is the kind of issue I was worried in the other thread on Fijitsu platform. That's the reason I was asking the information about their secure firmware and what exactly it configures so that we won't end up with similar situation on there too and definitely not to push PSCI. I completely agree with you that making a some change in firmware to give control of CCI to kernel is easy. Probably if the vendors disagree to apply this small fix to the firmware we should provide them with *only choice* of PSCI implementation which is quite complex and easy to get it wrong. That might trigger them to provide a small fix to use MCPM. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
On Mon, Nov 17, 2014 at 12:48:22PM +0100, Marek Szyprowski wrote:
> This is an updated patchset, which intends to add support for L2 cache
> on Exynos4 SoCs on boards running under secure firmware, which requires
> certain initialization steps to be done with help of firmware, as
> selected registers are writable only from secure mode.
>
> First four patches extend existing support for secure write in L2C driver
> to account for design of secure firmware running on Exynos. Namely:
> 1) direct read access to certain registers is needed on Exynos, because
> secure firmware calls set several registers at once,
> 2) not all boards are running secure firmware, so .write_sec callback
> needs to be installed in Exynos firmware ops initialization code,
> 3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
> is not allowed and so must use l2c_write_sec as well,
> 4) on certain boards, default value of prefetch register is incorrect
> and must be overridden at L2C initialization.
> For boards running with firmware that provides access to individual
> L2C registers this series should introduce no functional changes. However
> since the driver is widely used on other platforms I'd like to kindly ask
> any interested people for testing.
>
> Further three patches add implementation of .write_sec and .configure
> callbacks for Exynos secure firmware and necessary DT nodes to enable
> L2 cache.
>
> Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
> boards (both with secure firmware). There should be no functional change
> for Exynos boards running without secure firmware. I do not have access
> to affected non-Exynos boards, so I could not test on them.
So, I applied this series, and now I get a conflicts between my tree and
arm-soc for:
arch/arm/mach-exynos/firmware.c
arch/arm/mach-exynos/sleep.S
So, I'm going to un-stage the exynos bits, and we'll have to work out
some way to handle those.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] PM / Domains: Initial PM clock support for genpd
On Thursday, November 27, 2014 03:51:49 PM Ulf Hansson wrote:
> It's quite common for PM domains to use PM clocks. Typically from SOC
> specific code, the per device PM clock list is created and
> pm_clk_suspend|resume() are invoked to handle clock gating/ungating.
>
> A step towards consolidation is to integrate PM clock support into
> genpd, which is what this patch does.
>
> In this initial step, the calls to the pm_clk_suspend|resume() are
> handled within genpd, but the per device PM clock list still needs to
> be created from SOC specific code. It seems reasonable to have gendp to
> handle that as well, but that left to future patches to address.
>
> It's not every users of genpd that are keen on using PM clocks thus we
> need to provide this a configuration option for genpd. Therefore let's
> add flag field in the genpd struct to keep this information and define
> a new PM_DOMAIN_PM_CLK bit can then be set at initialization.
>
> Signed-off-by: Ulf Hansson
> ---
>
> Changes in v2:
> Set ->start() callback to pm_clk_resume() and fixed comment.
>
> ---
> drivers/base/power/domain.c | 7 +++
> include/linux/pm_domain.h | 3 +++
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 735c473..42ba5a0 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1928,6 +1929,12 @@ void pm_genpd_init(struct generic_pm_domain *genpd,
> genpd->domain.ops.complete = pm_genpd_complete;
> genpd->dev_ops.save_state = pm_genpd_default_save_state;
> genpd->dev_ops.restore_state = pm_genpd_default_restore_state;
> +
> + if (genpd->flags & PM_DOMAIN_PM_CLK) {
> + genpd->dev_ops.stop = pm_clk_suspend;
> + genpd->dev_ops.start = pm_clk_resume;
> + }
> +
> mutex_lock(&gpd_list_lock);
> list_add(&genpd->gpd_list_node, &gpd_list);
> mutex_unlock(&gpd_list_lock);
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 8cbd32e..4ba06a4f 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -14,6 +14,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
If you defined the flag as
#define PM_DOMAIN_FLAGS_PM_CLK (1U << 0)
(which is a kind of usual way to do that), you wouldn't need the
bitops.h above.
Moreover, I personally don't like #defines in struct definitions.
>
> @@ -76,6 +77,8 @@ struct generic_pm_domain {
> struct device *dev);
> void (*detach_dev)(struct generic_pm_domain *domain,
> struct device *dev);
> + unsigned int flags; /* Bit field of configs for genpd */
> +#define PM_DOMAIN_PM_CLK BIT(0) /* PM domain uses PM clk */
> };
>
> static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain *pd)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [03/19] clk: samsung: exynos5433: Add clocks using common clock framework
Hi Pankaj,
On 11/27/2014 08:48 PM, Pankaj Dubey wrote:
> Hi Chanwoo,
>
> On Thursday 27 November 2014 01:05 PM, Chanwoo Choi wrote:
>> This patch adds the support for CMU (Clock Management Units) of Exynos5433
>> which is 64bit SoC and has Octa-cores. This patch supports necessary clocks
>> for kernel boot as following:
>> - PLL/MMC/UART/MCT/I2C/SPI
>>
>> Cc: Sylwester Nawrocki
>> Cc: Tomasz Figa
>> Signed-off-by: Chanwoo Choi
>> Acked-by: Inki Dae
>> Acked-by: Geunsik Lim
>>
>> ---
>> drivers/clk/samsung/Makefile | 1 +
>> drivers/clk/samsung/clk-exynos5433.c | 971
>> +
>> include/dt-bindings/clock/exynos5433.h | 200 +++
>> 3 files changed, 1172 insertions(+)
>> create mode 100644 drivers/clk/samsung/clk-exynos5433.c
>> create mode 100644 include/dt-bindings/clock/exynos5433.h
>>
(snip)
>> +
>> +static struct samsung_div_clock top_div_clks[] __initdata = {
>> +/* DIV_TOP2 */
>> +DIV(CLK_DIV_ACLK_FSYS_200, "div_aclk_fsys_200", "mout_bus_pll_user",
>> +DIV_TOP2, 0, 3),
>> +
>> +/* DIV_TOP3 */
>> +DIV(CLK_DIV_ACLK_IMEM_SSSX, "div_aclk_imem_sssx",
>> +"mout_bus_pll_user", DIV_TOP3, 24, 3),
>
> Isn't this clock name should be div_aclk_imem_sssx_266 as per UM?
You're right. So, I fxied clock name on patch11[1] for CMU_BUSx domains.
- [1] [PATCH 11/19] clk: samsung: exynos5433: Add clocks for CMU_BUS{0|1|2}
domains
/* DIV_TOP3 */
- DIV(CLK_DIV_ACLK_IMEM_SSSX, "div_aclk_imem_sssx",
+ DIV(CLK_DIV_ACLK_IMEM_SSSX_266, "div_aclk_imem_sssx_266",
"mout_bus_pll_user", DIV_TOP3, 24, 3),
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] thermal: cpu_cooling: check for the readiness of cpufreq layer
On 27 November 2014 at 19:38, Eduardo Valentin wrote: >> Acked-by: Viresh Kumar > > Ok. > > though.. "normal practice" says ack's are oftern used by the maintainer > of the affected code (quoting Documentation/SubmittingPatches) :-) Hehe :) Another paragraph from the same file: Acked-by: does not necessarily indicate acknowledgement of the entire patch. For example, if a patch affects multiple subsystems and has an Acked-by: from one subsystem maintainer then this usually indicates acknowledgement of just the part which affects that maintainer's code. Judgement should be used here. When in doubt people should refer to the original discussion in the mailing list archives. So my Acked-by was as cpufreq subsystem Maintainer :) -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
Hi Alim,
On Wed, Nov 26, 2014 at 7:03 PM, Alim Akhtar wrote:
> Hi Vivek,
>
> On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam
> wrote:
>> USB and Power regulator on Exynos7 require gpios available
>> in BUS1 pin controller block.
>> So adding the BUS1 pinctrl support.
>>
>> Signed-off-by: Naveen Krishna Ch
>> Signed-off-by: Vivek Gautam
>> Cc: Linus Walleij
>> ---
> Looks good to me.
> Thanks!
>
> Reviewed-by: Alim Akhtar
Thanks for the review.
>
>>
>> This patch was part of series:
>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>> https://lkml.org/lkml/2014/11/21/247
>>
>> Changes since V1:
>> - Added support for all pin banks which are part of BUS1 pin controller.
>>
>> drivers/pinctrl/samsung/pinctrl-exynos.c | 19 +++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> index d5d4cfc..44e60dc 100644
>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>> @@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data
>> exynos7_pin_banks7[] __initconst = {
>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>> };
>>
>> +/* pin banks of exynos7 pin-controller - BUS1 */
>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst
>> = {
>> + EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>> + EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
>> + EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
>> + EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
>> + EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>> + EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
>> + EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
>> + EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
>> + EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>> + EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
>> +};
>> +
>> const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
>> {
>> /* pin-controller instance 0 Alive data */
>> @@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[]
>> __initconst = {
>> .pin_banks = exynos7_pin_banks7,
>> .nr_banks = ARRAY_SIZE(exynos7_pin_banks7),
>> .eint_gpio_init = exynos_eint_gpio_init,
>> + }, {
>> + /* pin-controller instance 8 BUS1 data */
>> + .pin_banks = exynos7_pin_banks8,
>> + .nr_banks = ARRAY_SIZE(exynos7_pin_banks8),
>> + .eint_gpio_init = exynos_eint_gpio_init,
>> },
>> };
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Regards,
> Alim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
Hi Linus,
On Fri, Nov 28, 2014 at 9:05 AM, Vivek Gautam wrote:
> Hi Alim,
>
>
> On Wed, Nov 26, 2014 at 7:03 PM, Alim Akhtar wrote:
>> Hi Vivek,
>>
>> On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam
>> wrote:
>>> USB and Power regulator on Exynos7 require gpios available
>>> in BUS1 pin controller block.
>>> So adding the BUS1 pinctrl support.
>>>
>>> Signed-off-by: Naveen Krishna Ch
>>> Signed-off-by: Vivek Gautam
>>> Cc: Linus Walleij
If the change looks good, will it be possible to pick it fo 3.19-rc1 ?
That will really help enabling USB IP on exynos7.
>>> ---
>> Looks good to me.
>> Thanks!
>>
>> Reviewed-by: Alim Akhtar
>
> Thanks for the review.
>
>>
>>>
>>> This patch was part of series:
>>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>>> https://lkml.org/lkml/2014/11/21/247
>>>
>>> Changes since V1:
>>> - Added support for all pin banks which are part of BUS1 pin controller.
>>>
>>> drivers/pinctrl/samsung/pinctrl-exynos.c | 19 +++
>>> 1 file changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> index d5d4cfc..44e60dc 100644
>>> --- a/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> +++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
>>> @@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data
>>> exynos7_pin_banks7[] __initconst = {
>>> EXYNOS_PIN_BANK_EINTG(8, 0x060, "gpr3", 0x0c),
>>> };
>>>
>>> +/* pin banks of exynos7 pin-controller - BUS1 */
>>> +static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst
>>> = {
>>> + EXYNOS_PIN_BANK_EINTG(8, 0x020, "gpf0", 0x00),
>>> + EXYNOS_PIN_BANK_EINTG(8, 0x040, "gpf1", 0x04),
>>> + EXYNOS_PIN_BANK_EINTG(4, 0x060, "gpf2", 0x08),
>>> + EXYNOS_PIN_BANK_EINTG(5, 0x080, "gpf3", 0x0c),
>>> + EXYNOS_PIN_BANK_EINTG(8, 0x0a0, "gpf4", 0x10),
>>> + EXYNOS_PIN_BANK_EINTG(8, 0x0c0, "gpf5", 0x14),
>>> + EXYNOS_PIN_BANK_EINTG(5, 0x0e0, "gpg1", 0x18),
>>> + EXYNOS_PIN_BANK_EINTG(5, 0x100, "gpg2", 0x1c),
>>> + EXYNOS_PIN_BANK_EINTG(6, 0x120, "gph1", 0x20),
>>> + EXYNOS_PIN_BANK_EINTG(3, 0x140, "gpv6", 0x24),
>>> +};
>>> +
>>> const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
>>> {
>>> /* pin-controller instance 0 Alive data */
>>> @@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[]
>>> __initconst = {
>>> .pin_banks = exynos7_pin_banks7,
>>> .nr_banks = ARRAY_SIZE(exynos7_pin_banks7),
>>> .eint_gpio_init = exynos_eint_gpio_init,
>>> + }, {
>>> + /* pin-controller instance 8 BUS1 data */
>>> + .pin_banks = exynos7_pin_banks8,
>>> + .nr_banks = ARRAY_SIZE(exynos7_pin_banks8),
>>> + .eint_gpio_init = exynos_eint_gpio_init,
>>> },
>>> };
>>> --
>>> 1.7.10.4
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-samsung-soc" in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Regards,
>> Alim
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R&D Institute, Bangalore
> India
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] arm64: exynos: Add bus1 pinctrl node on exynos7
Hi Kukjin,
On Wed, Nov 26, 2014 at 6:59 PM, Alim Akhtar wrote:
> Hi Vivek,
>
> On Mon, Nov 24, 2014 at 6:36 PM, Vivek Gautam
> wrote:
>> BUS1 pinctrl provides gpios for usb and power regulator
>> available on exynos7-espresso board. So add relevant device
>> node for pinctrl-bus1.
>>
>> Signed-off-by: Naveen Krishna Ch
>> Signed-off-by: Vivek Gautam
>> ---
We can pick this up for 3.19 rc1 ?
>>
> Looks good to me.
> Reviewed-by: Alim Akhtar
>
>> This patch was part of series:
>> "[PATCH 00/11] Exynos7: Adding USB 3.0 support"
>> https://lkml.org/lkml/2014/11/21/247
>>
>> Changes since V1:
>> - Added support for all pin banks which are part of BUS1 pin controller.
>>
>> arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 82
>> +++
>> arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
>> 2 files changed, 89 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> index 2eef4a2..c367f0a 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
>> @@ -335,6 +335,88 @@
>> };
>> };
>>
>> +&pinctrl_bus1 {
>> + gpf0: gpf0 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpf1: gpf1 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpf2: gpf2 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpf3: gpf3 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpf4: gpf4 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpf5: gpf5 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpg1: gpg1 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpg2: gpg2 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gph1: gph1 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +
>> + gpv6: gpv6 {
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> +};
>> +
>> &pinctrl_nfc {
>> gpj0: gpj0 {
>> gpio-controller;
>> diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> index 1d9e4c9..e633b02 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> +++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
>> @@ -26,6 +26,7 @@
>> pinctrl5 = &pinctrl_ese;
>> pinctrl6 = &pinctrl_fsys0;
>> pinctrl7 = &pinctrl_fsys1;
>> + pinctrl8 = &pinctrl_bus1;
>> };
>>
>> cpus {
>> @@ -242,6 +243,12 @@
>> interrupts = <0 383 0>;
>> };
>>
>> + pinctrl_bus1: pinctrl@1487 {
>> + compatible = "samsung,exynos7-pinctrl";
>> + reg = <0x1487 0x1000>;
>> + interrupts = <0 384 0>;
>> + };
>> +
>> pinctrl_nfc: pinctrl@14cd {
>> compatible = "samsung,exynos7-pinctrl";
>> reg = <0x14cd 0x1000>;
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Regards,
> Alim
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to maj
Re: [PATCH] drm/exynos: Add DECON driver
Hi Pankaj,
Thanks a lot for reviewing the patch. Find my comments below.
On Thu, Nov 27, 2014 at 9:55 PM, Pankaj Dubey wrote:
> Hi Ajay,
>
> On 27 November 2014 at 19:41, Ajay Kumar wrote:
>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> DECON(Display and Enhancement Controller) is the new IP
>> in exynos7 SOC for generating video signals using pixel data.
>>
>> DECON driver can be used to drive 2 different interfaces on Exynos7:
>> DECON-INT(video controller) and DECON-EXT(Mixer for HDMI)
>>
>> The existing FIMD driver code was used as a template to create
>> DECON driver. Only DECON-INT is supported as of now, and
>> DECON-EXT support will be added later.
>>
>> Signed-off-by: Akshu Agrawal
>> Signed-off-by: Ajay Kumar
>> ---
>> .../devicetree/bindings/video/exynos7-decon.txt| 67 ++
>> drivers/gpu/drm/exynos/Kconfig | 13 +-
>> drivers/gpu/drm/exynos/Makefile|1 +
>> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1029
>>
>> drivers/gpu/drm/exynos/exynos_drm_drv.c|4 +
>> drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
>> include/video/exynos7_decon.h | 346 +++
>> 7 files changed, 1458 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt
>> create mode 100644 drivers/gpu/drm/exynos/exynos7_drm_decon.c
>> create mode 100644 include/video/exynos7_decon.h
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> new file mode 100644
>> index 000..14db519
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/video/exynos7-decon.txt
>> @@ -0,0 +1,67 @@
>> +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON)
>> +
>> +DECON (Display and Enhancement Controller) is the Display Controller for the
>> +Exynos7 series of SoCs which transfers the image data from a video memory
>> +buffer to an external LCD interface.
>> +
>> +Required properties:
>> +- compatible: value should be "samsung,exynos7-decon";
>> +
>> +- reg: physical base address and length of the DECON registers set.
>> +
>> +- interrupt-parent: should be the phandle of the decon controller's
>> + parent interrupt controller.
>> +
>> +- interrupts: should contain a list of all DECON IP block interrupts in the
>> +order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt
>> specifier
>> +format depends on the interrupt controller used.
>> +
>> +- interrupt-names: should contain the interrupt names: "fifo", "vsync",
>> + "lcd_sys", in the same order as they were listed in the interrupts
>> +property.
>> +
>> +- pinctrl-0: pin control group to be used for this controller.
>> +
>> +- pinctrl-names: must contain a "default" entry.
>> +
>> +- clocks: must include clock specifiers corresponding to entries in the
>> + clock-names property.
>> +
>> +- clock-names: list of clock names sorted in the same order as the clocks
>> + property. Must contain "pclk_decon0", "aclk_decon0",
>> + "decon0_eclk", "decon0_vclk".
>> +
>> +Optional Properties:
>> +- samsung,power-domain: a phandle to DECON power domain node.
>> +- display-timings: timing settings for FIMD, as described in document [1].
>> + Can be used in case timings cannot be provided otherwise
>> + or to override timings provided by the panel.
>> +
>> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
>> +
>> +Example:
>> +
>> +SoC specific DT entry:
>> +
>> + decon@1393 {
>> + compatible = "samsung,exynos7-decon";
>> + interrupt-parent = <&combiner>;
>> + reg = <0x1393 0x1000>;
>> + interrupt-names = "lcd_sys", "vsync", "fifo";
>> + interrupts = <0 188 0>, <0 189 0>, <0 190 0>;
>> + clocks = <&clock_disp PCLK_DECON_INT>,
>> +<&clock_disp ACLK_DECON_INT>,
>> +<&clock_disp SCLK_DECON_INT_ECLK>,
>> +<&clock_disp SCLK_DECON_INT_EXTCLKPLL>;
>> + clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk",
>> + "decon0_vclk";
>> + status = "disabled";
>> + };
>> +
>> +Board specific DT entry:
>> +
>> + decon@1393 {
>> + pinctrl-0 = <&lcd_clk &pwm1_out>;
>> + pinctrl-names = "default";
>> + status = "okay";
>> + };
>> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
>> index 7f9f6f9..d3434cb 100644
>> --- a/drivers/gpu/drm/exynos/Kconfig
>> +++ b/drivers/gpu/drm/exynos/Kconfig
>> @@ -32,9 +32,16 @@ config DRM_EXYNOS_FIMD
>> help
>> Choose this op
Re: [PATCH V2 1/3] PM / Domains: Initial PM clock support for genpd
>
> If you defined the flag as
>
> #define PM_DOMAIN_FLAGS_PM_CLK (1U << 0)
>
> (which is a kind of usual way to do that), you wouldn't need the
> bitops.h above.
>
> Moreover, I personally don't like #defines in struct definitions.
>
>>
>> @@ -76,6 +77,8 @@ struct generic_pm_domain {
>> struct device *dev);
>> void (*detach_dev)(struct generic_pm_domain *domain,
>> struct device *dev);
>> + unsigned int flags; /* Bit field of configs for genpd */
>> +#define PM_DOMAIN_PM_CLK BIT(0) /* PM domain uses PM clk */
While I fix your above comments, I wonder whether I actually also
should change the prefix of the define as well.
>From "PM_DOMAIN" to "GENPD". Cause I think it's a genpd specific
define and not a "PM domain" define. Please tell me if you have any
objections to that.
>> };
>>
>> static inline struct generic_pm_domain *pd_to_genpd(struct dev_pm_domain
>> *pd)
>>
>
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
Thanks for review!
Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
