Re: [PATCH v3 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver
Dear MyungJoo,
Almost device tree patches in this series are reviewed by Exynos maintainer.
Could you please review this series?
Best Regards,
Chanwoo Choi
On 2015년 12월 11일 14:07, Chanwoo Choi wrote:
> This patch adds the generic exynos bus frequency driver for AMBA AXI bus
> of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
> have the common architecture for bus between DRAM and sub-blocks in SoC.
> This driver can support the generic bus frequency driver for Exynos SoCs.
>
> In devicetree, Each bus block has a bus clock, regulator, operation-point
> and devfreq-event devices which measure the utilization of each bus block.
>
> Signed-off-by: Chanwoo Choi
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon
> ---
> drivers/devfreq/Kconfig | 15 ++
> drivers/devfreq/Makefile| 1 +
> drivers/devfreq/exynos/Makefile | 1 +
> drivers/devfreq/exynos/exynos-bus.c | 449
>
> 4 files changed, 466 insertions(+)
> create mode 100644 drivers/devfreq/exynos/exynos-bus.c
>
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 64281bb2f650..55ec774f794c 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
>
> comment "DEVFREQ Drivers"
>
> +config ARM_EXYNOS_BUS_DEVFREQ
> + bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
> + depends on ARCH_EXYNOS
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND
> + select DEVFREQ_EVENT_EXYNOS_PPMU
> + select PM_DEVFREQ_EVENT
> + select PM_OPP
> + help
> + This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
> + Memory bus has one more group of memory bus (e.g, MIF and INT block).
> + Each memory bus group could contain many memoby bus block. It reads
> + PPMU counters of memory controllers by using DEVFREQ-event device
> + and adjusts the operating frequencies and voltages with OPP support.
> + This does not yet operate with optimal voltages.
> +
> config ARM_EXYNOS4_BUS_DEVFREQ
> bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
> depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
> !ARCH_MULTIPLATFORM
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 5134f9ee983d..375ebbb4fcfb 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
> obj-$(CONFIG_DEVFREQ_GOV_USERSPACE) += governor_userspace.o
>
> # DEVFREQ Drivers
> +obj-$(CONFIG_ARCH_EXYNOS)+= exynos/
> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos/
> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos/
> obj-$(CONFIG_ARM_TEGRA_DEVFREQ) += tegra-devfreq.o
> diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
> index 49bc9175f923..4ec06d322996 100644
> --- a/drivers/devfreq/exynos/Makefile
> +++ b/drivers/devfreq/exynos/Makefile
> @@ -1,3 +1,4 @@
> # Exynos DEVFREQ Drivers
> +obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
> obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ)+= exynos_ppmu.o exynos4_bus.o
> obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ)+= exynos_ppmu.o exynos5_bus.o
> diff --git a/drivers/devfreq/exynos/exynos-bus.c
> b/drivers/devfreq/exynos/exynos-bus.c
> new file mode 100644
> index ..f1bc20839650
> --- /dev/null
> +++ b/drivers/devfreq/exynos/exynos-bus.c
> @@ -0,0 +1,449 @@
> +/*
> + * Generic Exynos Bus frequency driver with DEVFREQ Framework
> + *
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
> + * Author : Chanwoo Choi
> + *
> + * This driver support Exynos Bus frequency feature by using
> + * DEVFREQ framework and is based on drivers/devfreq/exynos/exynos4_bus.c.
> + *
> + * 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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DEFAULT_SATURATION_RATIO 40
> +
> +struct exynos_bus {
> + struct device *dev;
> +
> + struct devfreq *devfreq;
> + struct devfreq_event_dev **edev;
> + unsigned int edev_count;
> + struct mutex lock;
> +
> + struct dev_pm_opp *curr_opp;
> +
> + struct regulator *regulator;
> + struct clk *clk;
> + int ratio;
> +};
> +
> +/*
> + * Control the devfreq-event device to get the current state of bus
> + */
> +#define exynos_bus_ops_edev(ops) \
> +static int exynos_bus_##ops(struct exynos_bus *bus) \
> +{\
> + int i, ret; \
> +
Re: [PATCH v3 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 2015년 12월 11일 16:18, Krzysztof Kozlowski wrote: > On 11.12.2015 14:07, Chanwoo Choi wrote: >> This patch adds the bus device-tree node of INT (internal) block >> to enable the bus frequency scaling. The following sub-blocks share >> the VDD_INT power source: >> - LEFTBUS (parent device) >> - RIGHTBUS >> - PERIL >> - LCD0 >> - FSYS >> - MCUISP / ISP >> - MFC >> >> The LEFTBUS is parent device with devfreq ondemand governor >> and the rest devices has the dependency on LEFTBUS bus. > > I pointed this previously. If you wish to leave the sentence in such > form then "rest of" and "have" not "has". It is my mistake. I'll modify it as following your comment: - "and the rest of devices depend on the LEFTBUS device." 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 v3 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU node
On 2015년 12월 11일 16:15, Krzysztof Kozlowski wrote: > On 11.12.2015 14:07, Chanwoo Choi wrote: >> This patch adds the exynos4412-ppmu-common.dtsi to duplicate PPMU node > > I think the goal of the patch was to remove duplication of nodes, not to > duplicate them. :) OK. I'll modify both subject and description of this patch. > > Except of that patch is okay: > > Reviewed-by: Krzysztof Kozlowski [snip] 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 v3 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
On 11.12.2015 14:07, Chanwoo Choi wrote:
> THis patch adds the bus device tree nodes for both MIF (Memory) and INT
> (Internal) block to enable the bus frequency.
>
> The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
> bus is parent device in INT block using VDD_INT.
>
> Signed-off-by: Chanwoo Choi
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
> arch/arm/boot/dts/exynos4412-trats2.dts | 48
> +
> 2 files changed, 95 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 7bd65026761e..b6818aec7cf9 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -501,3 +501,50 @@
> &watchdog {
> status = "okay";
> };
> +
> +&bus_acp {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
I meant put them in proper place, respecting alphabetical order. The 'b'
comes before 'w'.
As for the new nodes (bus_XXX) your previous sorting (first parent, then
passive) was also okay - it had sense. This is up to you. Just put
everything not at the end of file.
Best regards,
Krzysztof
> +
> +&bus_c2c {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
> +
> +&bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>;
> + status = "okay";
> +};
> +
> +&bus_display {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_fsys {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_leftbus {
> + devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
> + vdd-supply = <&buck3_reg>;
> + status = "okay";
> +};
> +
> +&bus_mfc {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_peri {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_rightbus {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
> b/arch/arm/boot/dts/exynos4412-trats2.dts
> index 92438eb6eec6..0b8aff3b8cb7 100644
> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
> @@ -1251,3 +1251,51 @@
> vtmu-supply = <&ldo10_reg>;
> status = "okay";
> };
> +
> +&bus_acp {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
> +
> +&bus_c2c {
> + devfreq = <&bus_dmc>;
> + status = "okay";
> +};
> +
> +&bus_dmc {
> + devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
> + vdd-supply = <&buck1_reg>;
> + status = "okay";
> +};
> +
> +&bus_display {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +
> +&bus_fsys {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_leftbus {
> + devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
> + vdd-supply = <&buck3_reg>;
> + status = "okay";
> +};
> +
> +&bus_mfc {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_peri {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
> +
> +&bus_rightbus {
> + devfreq = <&bus_leftbus>;
> + status = "okay";
> +};
>
--
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 v3 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus device-tree node of INT (internal) block > to enable the bus frequency scaling. The following sub-blocks share > the VDD_INT power source: > - LEFTBUS (parent device) > - RIGHTBUS > - PERIL > - LCD0 > - FSYS > - MCUISP / ISP > - MFC > > The LEFTBUS is parent device with devfreq ondemand governor > and the rest devices has the dependency on LEFTBUS bus. I pointed this previously. If you wish to leave the sentence in such form then "rest of" and "have" not "has". Best regards, Krzysztof > > Signed-off-by: Chanwoo Choi > Reviewed-by: Krzysztof Kozlowski > --- > arch/arm/boot/dts/exynos3250-rinato.dts | 41 > + > 1 file changed, 41 insertions(+) > -- 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 v3 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU node
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the exynos4412-ppmu-common.dtsi to duplicate PPMU node I think the goal of the patch was to remove duplication of nodes, not to duplicate them. :) Except of that patch is okay: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof > because exynos3250-rinato/monk, exynos4412-trats2/odroidu3 has the same > PPMU device tree node. > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250-monk.dts | 41 + > arch/arm/boot/dts/exynos3250-rinato.dts | 41 + > arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 + > arch/arm/boot/dts/exynos4412-ppmu-common.dtsi | 49 > + > arch/arm/boot/dts/exynos4412-trats2.dts | 41 + > 5 files changed, 53 insertions(+), 120 deletions(-) > create mode 100644 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi -- 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 v3 16/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has > one power line for all buses to translate data between DRAM and sub-blocks. > > Following list specifies the detailed relation between DRAM and sub-blocks: > - DMC/ACP clock for DMC (Dynamic Memory Controller) > - ACLK200 clock for LCD0 > - ACLK100 clock for PERIL/PERIR/MFC(PCLK) > - ACLK160 clock for CAM/TV/LCD0/LCD1 > - ACLK133 clock for FSYS/GPS > - GDL/GDR clock for LEFTBUS/RIGHTBUS > - SCLK_MFC clock for MFC > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos4210.dtsi | 159 > ++ > 1 file changed, 159 insertions(+) > Reviewed-by: Krzysztof Kozlowski 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 v3 15/20] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus noes using VDD_INT for Exynos4x12 SoC. > Exynos4x12 has the following AXI buses to translate data between > DRAM and sub-blocks. > > Following list specifies the detailed relation between DRAM and sub-blocks: > - ACLK100 clock for PERIL/PERIR/MFC(PCLK) > - ACLK160 clock for CAM/TV/LCD > : The minimum clock of ACLK160 should be over 160MHz. > When drop the clock under 160MHz, show the broken image. > - ACLK133 clock for FSYS > - GDL clock for LEFTBUS > - GDR clock for RIGHTBUS > - SCLK_MFC clock for MFC > > Signed-off-by: Chanwoo Choi > [linux.amoon: Tested on Odroid U3] > Tested-by: Anand Moon > --- > arch/arm/boot/dts/exynos4x12.dtsi | 106 > ++ > 1 file changed, 106 insertions(+) > Reviewed-by: Krzysztof Kozlowski 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 v3 14/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12
On 11.12.2015 14:07, Chanwoo Choi wrote:
> This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
"noes", pointed at v2.
> Exynos4x12 has the following AXI buses to translate data
> between DRAM and DMC/ACP/C2C.
>
> Signed-off-by: Chanwoo Choi
> [linux.amoon: Tested on Odroid U3]
> Tested-by: Anand Moon
> ---
> arch/arm/boot/dts/exynos4x12.dtsi | 68
> +++
> 1 file changed, 68 insertions(+)
The code itself:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
> b/arch/arm/boot/dts/exynos4x12.dtsi
> index 84a23f962946..99a0f4ca3d47 100644
> --- a/arch/arm/boot/dts/exynos4x12.dtsi
> +++ b/arch/arm/boot/dts/exynos4x12.dtsi
> @@ -281,6 +281,74 @@
> clocks = <&clock CLK_SMMU_LITE1>, <&clock CLK_FIMC_LITE1>;
> #iommu-cells = <0>;
> };
> +
> + bus_dmc: bus_dmc {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_DMC>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_acp: bus_acp {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_ACP>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_acp_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_c2c: bus_c2c {
> + compatible = "samsung,exynos-bus";
> + clocks = <&clock CLK_DIV_C2C>;
> + clock-names = "bus";
> + operating-points-v2 = <&bus_dmc_opp_table>;
> + status = "disabled";
> + };
> +
> + bus_dmc_opp_table: opp_table1 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@1 {
> + opp-hz = /bits/ 64 <1>;
> + opp-microvolt = <90>;
> + };
> + opp@13400 {
> + opp-hz = /bits/ 64 <13400>;
> + opp-microvolt = <90>;
> + };
> + opp@16000 {
> + opp-hz = /bits/ 64 <16000>;
> + opp-microvolt = <90>;
> + };
> + opp@26700 {
> + opp-hz = /bits/ 64 <26700>;
> + opp-microvolt = <95>;
> + };
> + opp@4 {
> + opp-hz = /bits/ 64 <4>;
> + opp-microvolt = <105>;
> + };
> + };
> +
> + bus_acp_opp_table: opp_table2 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp@1 {
> + opp-hz = /bits/ 64 <1>;
> + };
> + opp@13400 {
> + opp-hz = /bits/ 64 <13400>;
> + };
> + opp@16000 {
> + opp-hz = /bits/ 64 <16000>;
> + };
> + opp@26700 {
> + opp-hz = /bits/ 64 <26700>;
> + };
> + };
> };
>
> &combiner {
>
--
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 v3 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the bus nodes using VDD_INT for Exynos3250 SoC. > Exynos3250 has following AXI buses to translate data between > DRAM and sub-blocks. > > Following list specifies the detailed relation between DRAM and sub-blocks: > - ACLK400 clock for MCUISP > - ACLK266 clock for ISP > - ACLK200 clock for FSYS > - ACLK160 clock for LCD0 > - ACLK100 clock for PERIL > - GDL clock for LEFTBUS > - GDR clock for RIGHTBUS > - SCLK_MFC clock for MFC > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250.dtsi | 147 > ++ > 1 file changed, 147 insertions(+) > Reviewed-by: Krzysztof Kozlowski 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 v3 03/20] ARM: dts: Add DMC bus node for Exynos3250
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 > SoC. > The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard > SDRAM devices. The bus includes the OPP tables and the source clock for DMC > block. > > Following list specifies the detailed relation between the clock and DMC > block: > - The source clock of DMC block : div_dmc > > Signed-off-by: Chanwoo Choi > --- > arch/arm/boot/dts/exynos3250.dtsi | 34 ++ > 1 file changed, 34 insertions(+) > Reviewed-by: Krzysztof Kozlowski 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 v3 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
On 11.12.2015 14:07, Chanwoo Choi wrote: > This patch adds the documentation for generic exynos bus frequency > driver. > > Signed-off-by: Chanwoo Choi > --- > .../devicetree/bindings/devfreq/exynos-bus.txt | 93 > ++ > 1 file changed, 93 insertions(+) > create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt > Thanks, now it looks good to me. Reviewed-by: Krzysztof Kozlowski 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] ARM: dts: Make CPU configuration more readable for exynos542x/5800
On 11.12.2015 15:21, Viresh Kumar wrote: > On 11-12-15, 15:17, Krzysztof Kozlowski wrote: >> Exynos5420 and Exynos5800 boards boot from big core (A15) but >> Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this > > s/Exynos5420/Exynos5422 Damn, one can get confused. Thanks for review! Krzysztof > and then you can add > > Reviewed-by: Viresh Kumar > -- 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: dts: Make CPU configuration more readable for exynos542x/5800
On 11-12-15, 15:17, Krzysztof Kozlowski wrote: > Exynos5420 and Exynos5800 boards boot from big core (A15) but > Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this s/Exynos5420/Exynos5422 and then you can add Reviewed-by: Viresh Kumar -- viresh -- 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] ARM: dts: Make CPU configuration more readable for exynos542x/5800
Exynos5420 and Exynos5800 boards boot from big core (A15) but
Exynos5420 boards choose otherwise: LITTLE core (A7) (on Exynos5422 this
is property of the board - configurable by pulling up/down gpg2-1).
To make user-visible CPU ordering more consistent the 'cpus' node was
overridden by exynos5422-cpus.dtsi.
However this is a little bit ugly and error-prone. Overriding the CPU
child nodes requires to basically reverse what was done initially in
exynos5420.dtsi.
Instead, split CPU configuration entirely to separate files which should
be included by board DTS.
Suggested-by: Viresh Kumar
Signed-off-by: Krzysztof Kozlowski
---
Tested on Exynos5422 based Odroid XU4. Please kindly test on Exynos5420
or Exynos5800 boards.
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 1 +
arch/arm/boot/dts/exynos5420-cpus.dtsi| 92 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts| 1 +
arch/arm/boot/dts/exynos5420-smdk5420.dts | 1 +
arch/arm/boot/dts/exynos5420.dtsi | 72 +-
arch/arm/boot/dts/exynos5422-cpus.dtsi| 130 ++
arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 +
7 files changed, 170 insertions(+), 128 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos5420-cpus.dtsi
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 4ecef6981d5c..365eec6f6687 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -11,6 +11,7 @@
/dts-v1/;
#include "exynos5420.dtsi"
+#include "exynos5420-cpus.dtsi"
#include
#include
#include
diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi
b/arch/arm/boot/dts/exynos5420-cpus.dtsi
new file mode 100644
index ..7aaf0313274f
--- /dev/null
+++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
@@ -0,0 +1,92 @@
+/*
+ * SAMSUNG EXYNOS5420 SoC cpu device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This file provides desired ordering for Exynos5420 and Exynos5800
+ * boards: CPU[0123] being the A15.
+ *
+ * The Exynos5420, 5422 and 5800 actually share the same CPU configuration
+ * but particular boards choose different booting order.
+ *
+ * Exynos5420 and Exynos5800 always boot from Cortex-A15. On Exynos5422
+ * booting cluster (big or LITTLE) is chosen by IROM code by reading
+ * the gpg2-1 GPIO. By default all Exynos5422 based boards choose booting
+ * from the LITTLE: Cortex-A7.
+ *
+ * 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.
+ */
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x0>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x1>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x2>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0x3>;
+ clock-frequency = <18>;
+ cci-control-port = <&cci_control1>;
+ };
+
+ cpu4: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x100>;
+ clock-frequency = <10>;
+ cci-control-port = <&cci_control0>;
+ };
+
+ cpu5: cpu@101 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x101>;
+ clock-frequency = <10>;
+ cci-control-port = <&cci_control0>;
+ };
+
+ cpu6: cpu@102 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x102>;
+ clock-frequency = <10>;
+ cci-control-port = <&cci_control0>;
+ };
+
+ cpu7: c
Re: [PATCH] clk: samsung: exynos542x: fix MFC clock hierarchy parent
Hi, 2015-12-08 22:29 GMT+09:00 Marek Szyprowski : > Proper source for MFC block is mout_user_aclk333 (in datasheet named > USER_MUX_ACLK_333), not the output of CLKDIV_ACLK_333 MUX. > > Signed-off-by: Marek Szyprowski > --- > drivers/clk/samsung/clk-exynos5420.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Acked-by: Tomasz Figa 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] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof
On 11 December 2015 at 09:53, Krzysztof Kozlowski
wrote:
> On 11.12.2015 13:07, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 22 November 2015 at 05:43, Krzysztof Kozlowski
>> wrote:
>>> 2015-11-22 3:14 GMT+09:00 Anand Moon :
Hi Krzysztof,
>
> [...]
>
>>> Yes, now you pasted the same warning I did...
>>>
>>> This is still the same issue. I already wrote it:
1. BUG: sleeping function called from invalid context
2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> We can repeat it many times but that won't change anything...
>>>
>>> Best regards,
>>> Krzysztof
>>
>> Would you consider below changes to fix the above issue.
>> I have tested this change by enabling CONFIG_DEBUG_ATOMIC_SLEEP
>> And I don't observed issue.
>>
>> 1. BUG: sleeping function called from invalid context
>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>
>> Please share your thought on this changes.
>>
>> root@odroidxu4:/usr/src/odroidxu3-4.y-devel# git diff drivers/pwm/core.c
>> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
>> index d24ca5f..f3f6cf9 100644
>> --- a/drivers/pwm/core.c
>> +++ b/drivers/pwm/core.c
>> @@ -506,6 +506,9 @@ int pwm_enable(struct pwm_device *pwm)
>> if (!pwm)
>> return -EINVAL;
>>
>> + if (!mutex_is_locked(&pwm->lock))
>> + return -EINVAL;
>> +
>> mutex_lock(&pwm->lock);
>>
>> if (!test_and_set_bit(PWMF_ENABLED, &pwm->flags)) {
>
> First of all, Thierry suggested way of fixing this:
> "Any objections to simply removing it and make all users use a workqueue
> or some such if they need to control a PWM as a result of an interrupt
> trigger?"
You are correct, current design need to be changes.
> what is wrong with his approach?
>
pwm->lock is locked but it never get unlocked, although the code looks correct.
> Second, you are writing something that looks like mutex-try-lock...
> which will fail the pwm_enable(). IMHO this *hides* the real issue and
> does not solve anything (except hiding also the warning).
Thanks for the inputs. I have realized my mistake.
>
> Best regards,
> Krzysztof
-Anand Moon
--
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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 14:28, Krzysztof Kozlowski wrote: > Actually I think there is no nice way of making this as separate paths. > As Javier's mentioned, there aren't many differences. Currently the CPU > ordering is the only difference in DT. > > Making it as separate path would create hierarchy like: > - exynos5420-based-board.dts >\- include: exynos5420.dtsi > \- include: exynos5.dtsi >\- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi) > > - exynos5422-based-board.dts >\- include: exynos5420.dtsi > \- include: exynos5.dtsi >\- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi) > > which of course is okay... except we keep the definition of CPUs > completely outside of main Exynos5420 DTSI. Then we have to include both > DTSI for each new DTS. So what? There isn't anything wrong in this case and is just the right thing to do, IMHO. We have just kept the CPU devices separately, simple. -- viresh -- 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 v3 00/20] PM / devferq: Add generic exynos bus frequency driver and new passive governor
This patch-set includes the two features as following. The generic exynos bus
frequency driver is able to support almost Exynos SoCs for bus frequency
scaling. And the new passive governor is able to make the dependency on
between devices for frequency/voltage scaling. I had posted the patch-set[2]
with the similiar concept. This is is revised version for exynos bus frequency.
- Generic exynos bus frequency driver
- New passive governor of DEVFREQ framework
Depend on:
- next-20151210 tag of linux-next (master branch).
- Merge the latest devfreq patches on devfreq.git[2] (for-rafael branch).
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch:
for-rafael)
[2] https://lkml.org/lkml/2015/1/7/872
: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
Changes from v2:
(https://lkml.org/lkml/2015/12/8/869)
- Fix typo on documentation
- Modify the more appropriate sentence on patch description
- Add the detailed description about both parent and passive bus device
- Modify the DMC frequency for Exynos4x12 DMC bus (200MHz -> 267MHz)
- Modify the voltage of 200MHz was included in Exynos3250 DMC bus (800mV ->
825mV)
- Rename OPP nodes as 'opp@'
- Delete the duplicate 'opp-microvolt' property of passive devfreq device
- Reorder the 'bus_xxx' device tree node alphabetically in
exynos3250-rinato/monk.dts
- Reorder the 'bus_xxx' device tree node alphabetically in
exynos4412-trats/odroidu3
- Add new exynos4412-ppmu-common.dtsi to remove the duplicate PPMU dt node
on rinato/monk/trats2/odroid-u3 board
- Add the log message if bus device is registered to devfreq framework
successfully
- Add the reviewed-by tag from Krzysztof Kozlowski
- Add the tested-by tag from Anand Moon on Odroid U3
- Add 'SAMSUNG BUS FREQUENCY DRIVER' entry to MAINTAINERS
Changes from v1:
(https://lkml.org/lkml/2015/11/26/260)
- Check whether the instance of regulator is NULL or not
when executing regulator_disable() because of only parent
devfreq device has the regulator instance. After fixing it,
the wake-up from suspend state is well working. (patch1)
- Fix bug which checks 'bus-clk' instead of 'bus->regulator'
after calling devm_clk_get() (on patch1)
- Update the documentation to remove the description about
DEVFREQ-EVENT subsystem (on patch2)
- Add the full name of DMC (Dynamic Memory Controller) (on patch2)
- Modify the detailed correlation of buses for Exynos3250
on documentation (patch2)
- Add the MFC bus node for Exynos3250 (on patch11, patch12)
- Fix the duplicate frequency of bus_display on Exynos4x12.dtsi
- Add the PPMU node for exynos4412-odroidu3
- Add the support of bus frequency for exynos4412-odroidu3
Detailed descirption for patch-set:
1. Add generic exynos bus frequency driver
: This patch-set adds the generic exynos bus frequency driver for AXI bus
of sub-blocks in exynos SoC. The Samsung Exynos SoC have the common
architecture for bus between DRAM and sub-blocks in SoC.
There are the different buses according to Exynos SoC because Exynos SoC
has the differnt sub-blocks and bus speed. In spite of this difference
among Exynos SoCs, this driver is able to support almost Exynos SoC by adding
unique data of each bus in the devicetree file.
In devicetree, each bus node has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
For example,
- The bus of DMC block in exynos3250.dtsi are listed below:
bus_dmc: bus_dmc {
compatible = "samsung,exynos-bus";
clocks = <&cmu_dmc CLK_DIV_DMC>;
clock-names = "bus";
operating-points-v2 = <&bus_dmc_opp_table>;
status = "disabled";
};
bus_dmc_opp_table: opp_table1 {
compatible = "operating-points-v2";
opp-shared;
opp@5000 {
opp-hz = /bits/ 64 <5000>;
opp-microvolt = <80>;
};
opp@1 {
opp-hz = /bits/ 64 <1>;
opp-microvolt = <80>;
};
opp@13400 {
opp-hz = /bits/ 64 <13400>;
opp-microvolt = <80>;
};
opp@2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <825000>;
};
opp@4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <875000>;
};
};
- Usage case to handle the frequency and voltage of bus on runtime
in exynos3250-rinato.dts are listed below:
&bus_dmc {
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11.12.2015 13:53, Javier Martinez Canillas wrote:
> Hello Viresh,
>
> On 12/11/2015 01:38 AM, Viresh Kumar wrote:
>> On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
>>> We had such configuration before (before df09df6f9ac3). I don't see any
>>> benefit in what you described. Where is the "thing" to be fixed? It is
>>> mixed up. The contiguous ordering is easier to read and more natural.
>>
>> This is what you are doing today (keeping on one CPU per cluster to
>> simplify it):
>>
>> cpu0: cpu@0 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> reg = <0x0>;
>> clock-frequency = <18>;
>> cci-control-port = <&cci_control1>;
>> };
>>
>> cpu4: cpu@100 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a7";
>> reg = <0x100>;
>> clock-frequency = <10>;
>> cci-control-port = <&cci_control0>;
>> };
>>
>>
>> Then you overwrite it with:
>>
>> &cpu0 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a7";
>> reg = <0x100>;
>> clock-frequency = <10>;
>> cci-control-port = <&cci_control0>;
>> };
>>
>> &cpu4 {
>> device_type = "cpu";
>> compatible = "arm,cortex-a15";
>> reg = <0x0>;
>> clock-frequency = <18>;
>> cci-control-port = <&cci_control1>;
>> };
>>
>>
>> Don't you think this isn't the right way of solving problems?
>>
>> The DT overwrite feature isn't there to do such kind of stuff, though
>> it doesn't stop you from doing that.
>>
>
> I still fail to understand why the override is not a good way to solve
> the issue.
>
>> Either you should keep separate paths for both the SoCs, or can solve
>
> There's no point IMHO to duplicate the HW description since is the only
> difference between the Exynos5422 and Exynos5800 SoCs AFAIK.
Actually I think there is no nice way of making this as separate paths.
As Javier's mentioned, there aren't many differences. Currently the CPU
ordering is the only difference in DT.
Making it as separate path would create hierarchy like:
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi (the cpus are not in exynos5420.dtsi)
- exynos5422-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi (the cpus are not in exynos5420.dtsi)
which of course is okay... except we keep the definition of CPUs
completely outside of main Exynos5420 DTSI. Then we have to include both
DTSI for each new DTS.
Other idea is to create artificial "exynos5420-common":
- exynos5420-based-board.dts
\- include: exynos5420.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5420-cpu.dtsi
- exynos5422-based-board.dts
\- include: exynos5422.dtsi
\- include: exynos5420-common.dtsi
\- include: exynos5.dtsi
\- include: exynos5422-cpu.dtsi
This is also confusing...
Any third idea?
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
[PATCH v3 04/20] ARM: dts: Add DMC bus frequency for exynos3250-rinato/monk
This patch adds the DMC (Dynamic Memory Controller) bus frequency node
which includes the devfreq-events and regulator properties. The bus
frequency support the DVFS (Dynamic Voltage Frequency Scaling) feature
with ondemand governor.
The devfreq-events (ppmu_dmc0*) can monitor the utilization of DMC bus
on runtime and the buck1_reg (VDD_MIF power line) supplies the power to
the DMC block.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250-monk.dts | 6 ++
arch/arm/boot/dts/exynos3250-rinato.dts | 6 ++
2 files changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 443a35085846..456844a81189 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -156,6 +156,12 @@
};
};
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
&cpu0 {
cpu0-supply = <&buck2_reg>;
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 3e64d5dcdd60..d6bb990ce931 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -147,6 +147,12 @@
};
};
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
&cpu0 {
cpu0-supply = <&buck2_reg>;
};
--
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 v3 01/20] PM / devfreq: exynos: Add generic exynos bus frequency driver
This patch adds the generic exynos bus frequency driver for AMBA AXI bus
of sub-blocks in exynos SoC with DEVFREQ framework. The Samsung Exynos SoC
have the common architecture for bus between DRAM and sub-blocks in SoC.
This driver can support the generic bus frequency driver for Exynos SoCs.
In devicetree, Each bus block has a bus clock, regulator, operation-point
and devfreq-event devices which measure the utilization of each bus block.
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/Kconfig | 15 ++
drivers/devfreq/Makefile| 1 +
drivers/devfreq/exynos/Makefile | 1 +
drivers/devfreq/exynos/exynos-bus.c | 449
4 files changed, 466 insertions(+)
create mode 100644 drivers/devfreq/exynos/exynos-bus.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 64281bb2f650..55ec774f794c 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -66,6 +66,21 @@ config DEVFREQ_GOV_USERSPACE
comment "DEVFREQ Drivers"
+config ARM_EXYNOS_BUS_DEVFREQ
+ bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
+ depends on ARCH_EXYNOS
+ select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DEVFREQ_EVENT_EXYNOS_PPMU
+ select PM_DEVFREQ_EVENT
+ select PM_OPP
+ help
+ This adds the common DEVFREQ driver for Exynos Memory bus. Exynos
+ Memory bus has one more group of memory bus (e.g, MIF and INT block).
+ Each memory bus group could contain many memoby bus block. It reads
+ PPMU counters of memory controllers by using DEVFREQ-event device
+ and adjusts the operating frequencies and voltages with OPP support.
+ This does not yet operate with optimal voltages.
+
config ARM_EXYNOS4_BUS_DEVFREQ
bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 5134f9ee983d..375ebbb4fcfb 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE) += governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
# DEVFREQ Drivers
+obj-$(CONFIG_ARCH_EXYNOS) += exynos/
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos/
obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 49bc9175f923..4ec06d322996 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,3 +1,4 @@
# Exynos DEVFREQ Drivers
+obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o
obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos-bus.c
b/drivers/devfreq/exynos/exynos-bus.c
new file mode 100644
index ..f1bc20839650
--- /dev/null
+++ b/drivers/devfreq/exynos/exynos-bus.c
@@ -0,0 +1,449 @@
+/*
+ * Generic Exynos Bus frequency driver with DEVFREQ Framework
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * Author : Chanwoo Choi
+ *
+ * This driver support Exynos Bus frequency feature by using
+ * DEVFREQ framework and is based on drivers/devfreq/exynos/exynos4_bus.c.
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DEFAULT_SATURATION_RATIO 40
+
+struct exynos_bus {
+ struct device *dev;
+
+ struct devfreq *devfreq;
+ struct devfreq_event_dev **edev;
+ unsigned int edev_count;
+ struct mutex lock;
+
+ struct dev_pm_opp *curr_opp;
+
+ struct regulator *regulator;
+ struct clk *clk;
+ int ratio;
+};
+
+/*
+ * Control the devfreq-event device to get the current state of bus
+ */
+#define exynos_bus_ops_edev(ops) \
+static int exynos_bus_##ops(struct exynos_bus *bus)\
+{ \
+ int i, ret; \
+ \
+ for (i = 0; i < bus->edev_count; i++) { \
+ if (!bus->edev[i]) \
+ continue; \
+ ret = devfreq_event_##ops(bus->edev[i]);\
+ if (ret < 0)\
+ return ret; \
+ }
[PATCH v3 03/20] ARM: dts: Add DMC bus node for Exynos3250
This patch adds the DMC (Dynamic Memory Controller) bus node for Exynos3250 SoC.
The DMC is an AMBA AXI-compliant slave to interface external JEDEC standard
SDRAM devices. The bus includes the OPP tables and the source clock for DMC
block.
Following list specifies the detailed relation between the clock and DMC block:
- The source clock of DMC block : div_dmc
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 18e3deffbf48..262b3b1995fd 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -701,6 +701,40 @@
clock-names = "ppmu";
status = "disabled";
};
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_dmc CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <80>;
+ };
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <80>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <80>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <825000>;
+ };
+ opp@4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <875000>;
+ };
+ };
};
};
--
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 v3 05/20] PM / devfreq: Add new passive governor
This patch adds the new passive governor for DEVFREQ framework. The following
governors are already present and used for DVFS (Dynamic Voltage and Frequency
Scaling) drivers. The following governors are independently used for one device
driver which don't give the influence to other device drviers and also don't
receive the effect from other device drivers.
- ondemand / performance / powersave / userspace
The passive governor depends on operation of parent driver with specific
governos extremely and is not able to decide the new frequency by oneself.
According to the decided new frequency of parent driver with governor,
the passive governor uses it to decide the appropriate frequency for own
device driver. The passive governor must need the following information
from device tree:
- the source clock and OPP tables
- the instance of parent device
For exameple,
there are one more devfreq device drivers which need to change their source
clock according to their utilization on runtime. But, they share the same
power line (e.g., regulator). So, specific device driver is operated as parent
with ondemand governor and then the rest device driver with passive governor
is influenced by parent device.
Suggested-by: Myungjoo Ham
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/Kconfig| 9
drivers/devfreq/Makefile | 1 +
drivers/devfreq/devfreq.c | 47
drivers/devfreq/governor_passive.c | 108 +
include/linux/devfreq.h| 15 ++
5 files changed, 180 insertions(+)
create mode 100644 drivers/devfreq/governor_passive.c
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 55ec774f794c..d03f635a93e1 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -64,6 +64,15 @@ config DEVFREQ_GOV_USERSPACE
Otherwise, the governor does not change the frequnecy
given at the initialization.
+config DEVFREQ_GOV_PASSIVE
+ tristate "Passive"
+ help
+ Sets the frequency by other governors (simple_ondemand, performance,
+ powersave, usersapce) of a parent devfreq device. This governor
+ always has the dependency on the chosen frequency from paired
+ governor. This governor does not change the frequency by oneself
+ through sysfs entry.
+
comment "DEVFREQ Drivers"
config ARM_EXYNOS_BUS_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 375ebbb4fcfb..f81c313b4b79 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND) +=
governor_simpleondemand.o
obj-$(CONFIG_DEVFREQ_GOV_PERFORMANCE) += governor_performance.o
obj-$(CONFIG_DEVFREQ_GOV_POWERSAVE)+= governor_powersave.o
obj-$(CONFIG_DEVFREQ_GOV_USERSPACE)+= governor_userspace.o
+obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
# DEVFREQ Drivers
obj-$(CONFIG_ARCH_EXYNOS) += exynos/
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 984c5e9e7bdd..15e58779e4c0 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -190,6 +190,31 @@ static struct devfreq_governor
*find_devfreq_governor(const char *name)
/* Load monitoring helper functions for governors use */
+static int update_devfreq_passive(struct devfreq *devfreq, unsigned long freq)
+{
+ struct devfreq *passive;
+ unsigned long rate;
+ int ret;
+
+ list_for_each_entry(passive, &devfreq->passive_dev_list, passive_node) {
+ if (!passive->governor)
+ continue;
+ rate = freq;
+
+ ret = passive->governor->get_target_freq(passive, &rate);
+ if (ret)
+ return ret;
+
+ ret = passive->profile->target(passive->dev.parent, &rate, 0);
+ if (ret)
+ return ret;
+
+ passive->previous_freq = rate;
+ }
+
+ return 0;
+}
+
/**
* update_devfreq() - Reevaluate the device and configure frequency.
* @devfreq: the devfreq instance.
@@ -233,10 +258,18 @@ int update_devfreq(struct devfreq *devfreq)
flags |= DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use LUB */
}
+ if (!list_empty(&devfreq->passive_dev_list)
+ && devfreq->previous_freq > freq)
+ update_devfreq_passive(devfreq, freq);
+
err = devfreq->profile->target(devfreq->dev.parent, &freq, flags);
if (err)
return err;
+ if (!list_empty(&devfreq->passive_dev_list)
+ && devfreq->previous_freq < freq)
+ update_devfreq_passive(devfreq, freq);
+
if (devfreq->profile->freq_table)
if (devfreq_update_status(devfreq, freq))
dev_err(&devfreq->dev,
@@ -442,6 +475,10 @@ static void _remove_devf
[PATCH v3 06/20] PM / devfreq: Add devfreq_get_devfreq_by_phandle()
This patch adds the new devfreq_get_devfreq_by_phandle() OF helper function
which can find the instance of devfreq device by using phandle ("devfreq").
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/devfreq.c | 44
include/linux/devfreq.h | 9 +
2 files changed, 53 insertions(+)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 15e58779e4c0..78ea4cdaa82c 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "governor.h"
static struct class *devfreq_class;
@@ -686,6 +687,49 @@ struct devfreq *devm_devfreq_add_device(struct device *dev,
}
EXPORT_SYMBOL(devm_devfreq_add_device);
+#ifdef CONFIG_OF
+/*
+ * devfreq_get_devfreq_by_phandle - Get the devfreq device from devicetree
+ * @dev - instance to the given device
+ * @index - index into list of devfreq
+ *
+ * return the instance of devfreq device
+ */
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+ struct device_node *node;
+ struct devfreq *devfreq;
+
+ if (!dev)
+ return ERR_PTR(-EINVAL);
+
+ if (!dev->of_node)
+ return ERR_PTR(-EINVAL);
+
+ node = of_parse_phandle(dev->of_node, "devfreq", index);
+ if (!node)
+ return ERR_PTR(-ENODEV);
+
+ mutex_lock(&devfreq_list_lock);
+ list_for_each_entry(devfreq, &devfreq_list, node) {
+ if (devfreq->dev.parent
+ && devfreq->dev.parent->of_node == node) {
+ mutex_unlock(&devfreq_list_lock);
+ return devfreq;
+ }
+ }
+ mutex_unlock(&devfreq_list_lock);
+
+ return ERR_PTR(-EPROBE_DEFER);
+}
+#else
+struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev, int index)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif /* CONFIG_OF */
+EXPORT_SYMBOL_GPL(devfreq_get_devfreq_by_phandle);
+
/**
* devm_devfreq_remove_device() - Resource-managed devfreq_remove_device()
* @dev: the device to add devfreq feature.
diff --git a/include/linux/devfreq.h b/include/linux/devfreq.h
index 95c54578a1b4..cf972befca2b 100644
--- a/include/linux/devfreq.h
+++ b/include/linux/devfreq.h
@@ -211,6 +211,9 @@ extern int devm_devfreq_register_opp_notifier(struct device
*dev,
extern void devm_devfreq_unregister_opp_notifier(struct device *dev,
struct devfreq *devfreq);
+extern struct devfreq *devfreq_get_devfreq_by_phandle(struct device *dev,
+ int index);
+
/**
* devfreq_update_stats() - update the last_status pointer in struct devfreq
* @df:the devfreq instance whose status needs updating
@@ -322,6 +325,12 @@ static inline void
devm_devfreq_unregister_opp_notifier(struct device *dev,
{
}
+static inline struct devfreq *devfreq_get_devfreq_by_phandle(struct device
*dev,
+ int index)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline int devfreq_update_stats(struct devfreq *df)
{
return -EINVAL;
--
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 v3 02/20] PM / devfreq: exynos: Add documentation for generic exynos bus frequency driver
This patch adds the documentation for generic exynos bus frequency
driver.
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/devfreq/exynos-bus.txt | 93 ++
1 file changed, 93 insertions(+)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
new file mode 100644
index ..e32daef328da
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
@@ -0,0 +1,93 @@
+* Generic Exynos Bus frequency device
+
+The Samsung Exynos SoC have many buses for data transfer between DRAM
+and sub-blocks in SoC. Almost Exynos SoC have the common architecture
+for buses. Generally, the each bus of Exynos SoC includes the source clock
+and power line and then is able to change the clock according to the usage
+of each buses on runtime. When gathering the usage of each buses on runtime,
+the driver uses the PPMU (Platform Performance Monitoring Unit) which
+is able to measure the current load of sub-blocks.
+
+There are a little different composition among Exynos SoC because each Exynos
+SoC has the different sub-blocks. So, this difference should be specified
+in devicetree file instead of each device driver. In result, this driver
+is able to support the bus frequency for all Exynos SoCs.
+
+Required properties for bus device:
+- compatible: Should be "samsung,exynos-bus".
+- clock-names : the name of clock used by the bus, "bus".
+- clocks : phandles for clock specified in "clock-names" property.
+- operating-points-v2: the OPP table including frequency/voltage information
+ to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
+- vdd-supply: the regulator to provide the buses with the voltage.
+- devfreq-events: the devfreq-event device to monitor the current utilization
+ of buses.
+
+Optional properties for bus device:
+- exynos,saturation-ratio: the percentage value which is used to calibrate
+ the performance count against total cycle count.
+
+Example1:
+ Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to
+ power line (regulator). The MIF (Memory Interface) AXI bus is used to
+ transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
+
+ - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
+
+ - MIF bus's frequency/voltage table
+ ---
+ |Lv| Freq | Voltage |
+ ---
+ |L1| 5 |80 |
+ |L2| 10 |80 |
+ |L3| 134000 |80 |
+ |L4| 20 |825000 |
+ |L5| 40 |875000 |
+ ---
+
+Example2 :
+ The bus of DMC (Dynamic Memory Controller) block in exynos3250.dtsi
+ is listed below:
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu_dmc CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <80>;
+ };
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <80>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <80>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <825000>;
+ };
+ opp@4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <875000>;
+ };
+ };
+
+ Usage case to handle the frequency and voltage of bus on runtime
+ in exynos3250-rinato.dts is listed below:
+
+ &bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>; /* VDD_MIF */
+ status = "okay";
+ };
--
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 v3 07/20] PM / devfreq: Show the related information according to governor type
This patch modifies the following sysfs entry of DEVFREQ framework
because the devfreq device using passive governor don't need the same
information of the devfreq device using rest governor.
- polling_interval: passive gov don't use the sampling rate.
- available_governors : passive gov don't be changed on runtime in this version.
- trans_stat : passive governor don't support trans_stat in this
version.
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/devfreq.c | 31 +--
drivers/devfreq/governor.h| 7 +++
drivers/devfreq/governor_passive.c| 1 +
drivers/devfreq/governor_performance.c| 1 +
drivers/devfreq/governor_powersave.c | 1 +
drivers/devfreq/governor_simpleondemand.c | 1 +
drivers/devfreq/governor_userspace.c | 1 +
include/linux/devfreq.h | 2 ++
8 files changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 78ea4cdaa82c..18ad956fec93 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -597,7 +597,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
goto err_init;
}
- if (!strncmp(devfreq->governor_name, "passive", 7)) {
+ if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
struct devfreq *parent_devfreq =
((struct devfreq_passive_data *)data)->parent;
@@ -963,13 +963,23 @@ static ssize_t available_governors_show(struct device *d,
struct device_attribute *attr,
char *buf)
{
- struct devfreq_governor *tmp_governor;
+ struct devfreq *devfreq = to_devfreq(d);
ssize_t count = 0;
mutex_lock(&devfreq_list_lock);
- list_for_each_entry(tmp_governor, &devfreq_governor_list, node)
+ if (devfreq->governor->type == DEVFREQ_GOV_PASSIVE) {
count += scnprintf(&buf[count], (PAGE_SIZE - count - 2),
- "%s ", tmp_governor->name);
+ "%s ", devfreq->governor->name);
+ } else {
+ struct devfreq_governor *tmp_governor;
+
+ list_for_each_entry(tmp_governor, &devfreq_governor_list, node)
{
+ if (tmp_governor->type == DEVFREQ_GOV_PASSIVE)
+ continue;
+ count += scnprintf(&buf[count], (PAGE_SIZE - count - 2),
+ "%s ", tmp_governor->name);
+ }
+ }
mutex_unlock(&devfreq_list_lock);
/* Truncate the trailing space */
@@ -1006,6 +1016,11 @@ static DEVICE_ATTR_RO(target_freq);
static ssize_t polling_interval_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
+ struct devfreq *df = to_devfreq(dev);
+
+ if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+ return sprintf(buf, "Not Supported.\n");
+
return sprintf(buf, "%d\n", to_devfreq(dev)->profile->polling_ms);
}
@@ -1020,6 +1035,9 @@ static ssize_t polling_interval_store(struct device *dev,
if (!df->governor)
return -EINVAL;
+ if (df->governor->type == DEVFREQ_GOV_PASSIVE)
+ return -EINVAL;
+
ret = sscanf(buf, "%u", &value);
if (ret != 1)
return -EINVAL;
@@ -1137,11 +1155,12 @@ static ssize_t trans_stat_show(struct device *dev,
int i, j;
unsigned int max_state = devfreq->profile->max_state;
+ if (max_state == 0 || devfreq->governor->type == DEVFREQ_GOV_PASSIVE)
+ return sprintf(buf, "Not Supported.\n");
+
if (!devfreq->stop_polling &&
devfreq_update_status(devfreq, devfreq->previous_freq))
return 0;
- if (max_state == 0)
- return sprintf(buf, "Not Supported.\n");
len = sprintf(buf, " From : To\n");
len += sprintf(buf + len, " :");
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..43513a58f5bf 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -18,6 +18,13 @@
#define to_devfreq(DEV)container_of((DEV), struct devfreq, dev)
+/* Devfreq governor type */
+#define DEVFREQ_GOV_ONDEMAND 0x1
+#define DEVFREQ_GOV_PERFORMANCE0x2
+#define DEVFREQ_GOV_POWERSAVE 0x3
+#define DEVFREQ_GOV_USERSPACE 0x4
+#define DEVFREQ_GOV_PASSIVE0x4
+
/* Devfreq events */
#define DEVFREQ_GOV_START 0x1
#define DEVFREQ_GOV_STOP 0x2
diff --git a/drivers/devfreq/governor_passive.c
b/drivers/devfreq/governor_passive.c
index 7443ae4b92f9..adfdee9a9cd1 1
[PATCH v3 11/20] PM / devfreq: exynos: Remove unused exynos4/5 busfreq driver
This patch removes the unused exynos4/5 busfreq driver. Instead,
generic exynos-bus frequency driver support the all Exynos SoCs.
Signed-off-by: Chanwoo Choi
---
drivers/devfreq/Kconfig | 22 -
drivers/devfreq/exynos/Makefile |2 -
drivers/devfreq/exynos/exynos4_bus.c | 1055 --
drivers/devfreq/exynos/exynos4_bus.h | 110
drivers/devfreq/exynos/exynos5_bus.c | 431 --
drivers/devfreq/exynos/exynos_ppmu.c | 119
drivers/devfreq/exynos/exynos_ppmu.h | 86 ---
7 files changed, 1825 deletions(-)
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
delete mode 100644 drivers/devfreq/exynos/exynos5_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.c
delete mode 100644 drivers/devfreq/exynos/exynos_ppmu.h
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index 88f7cc4539b8..e82b1d8cd200 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -91,28 +91,6 @@ config ARM_EXYNOS_BUS_DEVFREQ
and adjusts the operating frequencies and voltages with OPP support.
This does not yet operate with optimal voltages.
-config ARM_EXYNOS4_BUS_DEVFREQ
- bool "ARM Exynos4210/4212/4412 Memory Bus DEVFREQ Driver"
- depends on (CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412) &&
!ARCH_MULTIPLATFORM
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- select PM_OPP
- help
- This adds the DEVFREQ driver for Exynos4210 memory bus (vdd_int)
- and Exynos4212/4412 memory interface and bus (vdd_mif + vdd_int).
- It reads PPMU counters of memory controllers and adjusts
- the operating frequencies and voltages with OPP support.
- This does not yet operate with optimal voltages.
-
-config ARM_EXYNOS5_BUS_DEVFREQ
- tristate "ARM Exynos5250 Bus DEVFREQ Driver"
- depends on SOC_EXYNOS5250
- select DEVFREQ_GOV_SIMPLE_ONDEMAND
- select PM_OPP
- help
- This adds the DEVFREQ driver for Exynos5250 bus interface (vdd_int).
- It reads PPMU counters of memory controllers and adjusts the
- operating frequencies and voltages with OPP support.
-
config ARM_TEGRA_DEVFREQ
tristate "Tegra DEVFREQ Driver"
depends on ARCH_TEGRA_124_SOC
diff --git a/drivers/devfreq/exynos/Makefile b/drivers/devfreq/exynos/Makefile
index 4ec06d322996..bc695ad81c7d 100644
--- a/drivers/devfreq/exynos/Makefile
+++ b/drivers/devfreq/exynos/Makefile
@@ -1,4 +1,2 @@
# Exynos DEVFREQ Drivers
obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
-obj-$(CONFIG_ARM_EXYNOS4_BUS_DEVFREQ) += exynos_ppmu.o exynos4_bus.o
-obj-$(CONFIG_ARM_EXYNOS5_BUS_DEVFREQ) += exynos_ppmu.o exynos5_bus.o
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
deleted file mode 100644
index da9509205169..
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ /dev/null
@@ -1,1055 +0,0 @@
-/* drivers/devfreq/exynos4210_memorybus.c
- *
- * Copyright (c) 2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com/
- * MyungJoo Ham
- *
- * EXYNOS4 - Memory/Bus clock frequency scaling support in DEVFREQ framework
- * This version supports EXYNOS4210 only. This changes bus frequencies
- * and vddint voltages. Exynos4412/4212 should be able to be supported
- * with minor modifications.
- *
- * 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
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#include "exynos_ppmu.h"
-#include "exynos4_bus.h"
-
-#define MAX_SAFEVOLT 120 /* 1.2V */
-
-enum exynos4_busf_type {
- TYPE_BUSF_EXYNOS4210,
- TYPE_BUSF_EXYNOS4x12,
-};
-
-/* Assume that the bus is saturated if the utilization is 40% */
-#define BUS_SATURATION_RATIO 40
-
-enum busclk_level_idx {
- LV_0 = 0,
- LV_1,
- LV_2,
- LV_3,
- LV_4,
- _LV_END
-};
-
-enum exynos_ppmu_idx {
- PPMU_DMC0,
- PPMU_DMC1,
- PPMU_END,
-};
-
-#define EX4210_LV_MAX LV_2
-#define EX4x12_LV_MAX LV_4
-#define EX4210_LV_NUM (LV_2 + 1)
-#define EX4x12_LV_NUM (LV_4 + 1)
-
-/**
- * struct busfreq_opp_info - opp information for bus
- * @rate: Frequency in hertz
- * @volt: Voltage in microvolts corresponding to this OPP
- */
-struct busfreq_opp_info {
- unsigned long rate;
- unsigned long volt;
-};
-
-struct busfreq_data {
- enum exynos4_busf_type type;
- struct device *dev;
- struct devfreq *devfreq;
- bool disabled;
- struct regulator *vdd_int;
- struct regulator *vdd_mif; /* Exynos4412/4212 only */
- struct busfreq_opp_info curr_oppinfo;
- struct busfreq_ppmu_data ppmu_data;
-
- struct notif
[PATCH v3 09/20] PM / devfreq: exynos: Update documentation for bus devices using passive governor
This patch updates the documentation for passive bus devices and adds the detailed example of Exynos3250. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos-bus.txt | 250 - 1 file changed, 247 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt index e32daef328da..a251f9120561 100644 --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt @@ -8,22 +8,46 @@ of each buses on runtime. When gathering the usage of each buses on runtime, the driver uses the PPMU (Platform Performance Monitoring Unit) which is able to measure the current load of sub-blocks. +The Exynos SoC includes the various sub-blocks which have the each AXI bus. +The each AXI bus has the owned source clock but, has not the only owned +power line. The power line might be shared among one more sub-blocks. +So, we can divide into two type of device as the role of each sub-block. +There are two type of bus devices as following: +- parent bus device +- passive bus device + +Basically, parent and passive bus device share the same power line. +The parent bus device can only change the voltage of shared power line +and the rest bus devices (passive bus device) depend on the decision of +the parent bus device. If there are three blocks which share the VDD_xxx +power line, Only one block should be parent device and then the rest blocks +should depend on the parent device as passive device. + + VDD_xxx |--- A block (parent) + |--- B block (passive) + |--- C block (passive) + There are a little different composition among Exynos SoC because each Exynos SoC has the different sub-blocks. So, this difference should be specified in devicetree file instead of each device driver. In result, this driver is able to support the bus frequency for all Exynos SoCs. -Required properties for bus device: +Required properties for all bus devices: - compatible: Should be "samsung,exynos-bus". - clock-names : the name of clock used by the bus, "bus". - clocks : phandles for clock specified in "clock-names" property. - operating-points-v2: the OPP table including frequency/voltage information to support DVFS (Dynamic Voltage/Frequency Scaling) feature. + +Required properties only for parent bus device: - vdd-supply: the regulator to provide the buses with the voltage. - devfreq-events: the devfreq-event device to monitor the current utilization of buses. -Optional properties for bus device: +Required properties only for passive bus device: +- devfreq: the parent bus device. + +Optional properties only for parent bus device: - exynos,saturation-ratio: the percentage value which is used to calibrate the performance count against total cycle count. @@ -32,7 +56,20 @@ Example1: power line (regulator). The MIF (Memory Interface) AXI bus is used to transfer data between DRAM and CPU and uses the VDD_MIF regualtor. - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block + - MIF (Memory Interface) block + : VDD_MIF |--- DMC (Dynamic Memory Controller) + + - INT (Internal) block + : VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC + |--- G3D + |--- RIGHTBUS + |--- FSYS + |--- LCD0 + |--- PERIR + |--- ISP + |--- CAM - MIF bus's frequency/voltage table --- @@ -45,6 +82,24 @@ Example1: |L5| 40 |875000 | --- + - INT bus's frequency/voltage table + -- + |Block|LEFTBUS|RIGHTBUS|MCUISP |ISP|PERIL ||VDD_INT | + | name| |LCD0| | | ||| + | | |FSYS| | | ||| + | | |MFC | | | ||| + -- + |Mode |*parent|passive |passive|passive|passive||| + -- + |Lv |Frequency ||Voltage | + -- + |L1 |5 |5 |5 |5 |5 ||90 | + |L2 |8 |8 |8 |8 |8 ||90 | + |L3 |10 |10 |10 |10 |10 ||100 | + |L4 |134000 |134000 |20 |20 | ||100 | + |L5 |20 |20 |40 |30 | ||100 | + -- + Example2 : The bus of DMC (Dynamic Memory Controller) block in exynos325
[PATCH v3 08/20] PM / devfreq: exynos: Add support of bus frequency of sub-blocks using passive governor
This patch adds the support of bus frequency feature for sub-blocks which share
the one power line. If each bus depends on the power line, each bus is not able
to change the voltage by oneself. To optimize the power-consumption on runtime,
some buses using the same power line should change the source clock and
regulator at the same time. So, this patch uses the passive governor to support
the bus frequency for all buses which sharing the one power line.
For example,
Exynos3250 include the two power line for AXI buses as following:
: VDD_MIF : MIF (Memory Interface) provide the DMC (Dynamic Memory Controller)
with the power (regulator).
: VDD_INT : INT (Internal) provide the various sub-blocks with the power
(regulator).
Each bus is included in as follwoing block. In the case of VDD_MIF, only DMC bus
use the power line. So, there is no any depencency between buese. But, in the
case of VDD_INT, various buses share the one power line of VDD_INT. We need to
make the depenency between buses. When using passive governor, there is no
problem to support the bus frequency as DVFS for all buses. One bus should be
operated as the parent bus device which gathering the current load of INT block
and then decides the new frequency with some governors except of passive
governor. After deciding the new frequency by the parent bus device, the rest
bus devices will change the each source clock according to new frequency of the
parent bus device.
- MIF (Memory Interface) block
: VDD_MIF |--- DMC
- INT (Internal) block
: VDD_INT |--- LEFTBUS (parent)
|--- PERIL
|--- MFC
|--- G3D
|--- RIGHTBUS
|--- FSYS
|--- LCD0
|--- PERIR
|--- ISP
|--- CAM
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
drivers/devfreq/Kconfig | 1 +
drivers/devfreq/exynos/exynos-bus.c | 179
2 files changed, 144 insertions(+), 36 deletions(-)
diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index d03f635a93e1..88f7cc4539b8 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -79,6 +79,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
bool "ARM EXYNOS Generic Memory Bus DEVFREQ Driver"
depends on ARCH_EXYNOS
select DEVFREQ_GOV_SIMPLE_ONDEMAND
+ select DEVFREQ_GOV_PASSIVE
select DEVFREQ_EVENT_EXYNOS_PPMU
select PM_DEVFREQ_EVENT
select PM_OPP
diff --git a/drivers/devfreq/exynos/exynos-bus.c
b/drivers/devfreq/exynos/exynos-bus.c
index f1bc20839650..d1c137ea22ca 100644
--- a/drivers/devfreq/exynos/exynos-bus.c
+++ b/drivers/devfreq/exynos/exynos-bus.c
@@ -91,7 +91,7 @@ static int exynos_bus_get_event(struct exynos_bus *bus,
}
/*
- * Must necessary function for devfreq governor
+ * Must necessary function for devfreq simple-ondemand governor
*/
static int exynos_bus_target(struct device *dev, unsigned long *freq, u32
flags)
{
@@ -205,57 +205,74 @@ static void exynos_bus_exit(struct device *dev)
dev_pm_opp_of_remove_table(dev);
}
-static int exynos_bus_parse_of(struct device_node *np,
- struct exynos_bus *bus)
+/*
+ * Must necessary function for devfreq passive governor
+ */
+static int exynos_bus_passive_target(struct device *dev, unsigned long *freq,
+ u32 flags)
{
- struct device *dev = bus->dev;
- unsigned long rate;
- int i, ret, count, size;
+ struct exynos_bus *bus = dev_get_drvdata(dev);
+ struct dev_pm_opp *new_opp;
+ unsigned long old_freq, new_freq;
+ int ret = 0;
- /* Get the clock to provide each bus with source clock */
- bus->clk = devm_clk_get(dev, "bus");
- if (IS_ERR(bus->clk)) {
- dev_err(dev, "failed to get bus clock\n");
- return PTR_ERR(bus->clk);
+ /* Get new opp-bus instance according to new bus clock */
+ rcu_read_lock();
+ new_opp = devfreq_recommended_opp(dev, freq, flags);
+ if (IS_ERR_OR_NULL(new_opp)) {
+ dev_err(dev, "failed to get recommed opp instance\n");
+ rcu_read_unlock();
+ return PTR_ERR(new_opp);
}
- ret = clk_prepare_enable(bus->clk);
- if (ret < 0) {
- dev_err(dev, "failed to get enable clock\n");
- return ret;
- }
+ new_freq = dev_pm_opp_get_freq(new_opp);
+ old_freq = dev_pm_opp_get_freq(bus->curr_opp);
+ rcu_read_unlock();
- /* Get the freq/voltage OPP table to scale the bus frequency */
- rcu_read_lock();
- ret = dev_pm_opp_of_add_table(dev);
+ if (old_freq == new_freq)
+ return 0;
+
+ /* Change the frequency according to new OPP level */
+ mutex_lock(&bus->lock);
+
+ ret = clk_set_rate(bus->clk, new_freq);
if (ret < 0) {
- dev_err(dev, "failed to get OPP table\n");
-
[PATCH v3 10/20] PM / devfreq: exynos: Add the detailed correlation between sub-blocks and power line
This patch adds the detailed corrleation between sub-blocks and power line for Exynos3250, Exynos4210 and Exynos4x12. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos-bus.txt | 51 ++ 1 file changed, 51 insertions(+) diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt index a251f9120561..f3a32b310dc7 100644 --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt @@ -51,6 +51,57 @@ Optional properties only for parent bus device: - exynos,saturation-ratio: the percentage value which is used to calibrate the performance count against total cycle count. +Detailed correlation between sub-blocks and power line according to Exynos SoC: +- In case of Exynos3250, there are two power line as following: + VDD_MIF |--- DMC + + VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC + |--- G3D + |--- RIGHTBUS + |--- PERIR + |--- FSYS + |--- LCD0 + |--- PERIR + |--- ISP + |--- CAM + +- In case of Exynos4210, there is one power line as following: + VDD_INT |--- DMC (parent device) + |--- LEFTBUS + |--- PERIL + |--- MFC(L) + |--- G3D + |--- TV + |--- LCD0 + |--- RIGHTBUS + |--- PERIR + |--- MFC(R) + |--- CAM + |--- FSYS + |--- GPS + |--- LCD0 + |--- LCD1 + +- In case of Exynos4x12, there are two power line as following: + VDD_MIF |--- DMC + + VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC(L) + |--- G3D + |--- TV + |--- IMAGE + |--- RIGHTBUS + |--- PERIR + |--- MFC(R) + |--- CAM + |--- FSYS + |--- GPS + |--- LCD0 + |--- ISP + Example1: Show the AXI buses of Exynos3250 SoC. Exynos3250 divides the buses to power line (regulator). The MIF (Memory Interface) AXI bus is used to -- 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 v3 13/20] ARM: dts: Add bus nodes using VDD_INT for Exynos3250
This patch adds the bus nodes using VDD_INT for Exynos3250 SoC.
Exynos3250 has following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK400 clock for MCUISP
- ACLK266 clock for ISP
- ACLK200 clock for FSYS
- ACLK160 clock for LCD0
- ACLK100 clock for PERIL
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250.dtsi | 147 ++
1 file changed, 147 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 262b3b1995fd..5cc98cf13173 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -735,6 +735,153 @@
opp-microvolt = <875000>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_lcd0: bus_lcd0 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_200>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mcuisp: bus_mcuisp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_400_MCUISP>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_mcuisp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_isp: bus_isp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_266>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_isp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peril: bus_peril {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_DIV_ACLK_100>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_peril_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&cmu CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ opp-microvolt = <90>;
+ };
+ opp@8000 {
+ opp-hz = /bits/ 64 <8000>;
+ opp-microvolt = <90>;
+ };
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <100>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <100>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <100>;
+ };
+ };
+
+ bus_mcuisp_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ };
+
[PATCH v3 12/20] MAINTAINERS: Add samsung bus frequency driver entry
This patch adds the 'SAMSUNG BUS FREQUENCY DRIVER' entry to review the patches as supporter. Patches will be picked up by DEVFREQ maintainer on devfreq git repository. Signed-off-by: Chanwoo Choi --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index ff2d20173d98..89e645688a3c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3434,6 +3434,15 @@ F: drivers/devfreq/devfreq-event.c F: include/linux/devfreq-event.h F: Documentation/devicetree/bindings/devfreq/event/ +SAMSUNG BUS FREQUENCY DRIVER +M: Chanwoo Choi +L: linux...@vger.kernel.org +L: linux-samsung-soc@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git +S: Supported +F: drivers/devfreq/exynos/exynos-bus.c +F: Documentation/devicetree/bindings/devfreq/exynos-bus.txt + DEVICE NUMBER REGISTRY M: Torben Mathiasen W: http://lanana.org/docs/device-list/index.html -- 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 v3 15/20] ARM: dts: Add bus nodes using VDD_INT for Exynos4x12
This patch adds the bus noes using VDD_INT for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data between
DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD
: The minimum clock of ACLK160 should be over 160MHz.
When drop the clock under 160MHz, show the broken image.
- ACLK133 clock for FSYS
- GDL clock for LEFTBUS
- GDR clock for RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
arch/arm/boot/dts/exynos4x12.dtsi | 106 ++
1 file changed, 106 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 99a0f4ca3d47..e5173107ed44 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -349,6 +349,112 @@
opp-hz = /bits/ 64 <26700>;
};
};
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_display: bus_display {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_display_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK133>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_fsys_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peri: bus_peri {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK100>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_peri_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <90>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <925000>;
+ };
+ opp@16000 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <95>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <100>;
+ };
+ };
+
+ bus_display_opp_table: opp_table4 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@16000 {
+ opp-hz = /bits/ 64 <16000>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ };
+ };
+
+ bus_fsys_opp_table: opp_table5 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ };
+ };
+
+ bus_peri_opp_table: opp_table6 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@5000 {
+ opp-hz = /bits/ 64 <5000>;
+ };
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ };
+ };
};
&combiner {
--
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 v3 17/20] ARM: dts: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU node
This patch adds the exynos4412-ppmu-common.dtsi to duplicate PPMU node
because exynos3250-rinato/monk, exynos4412-trats2/odroidu3 has the same
PPMU device tree node.
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos3250-monk.dts | 41 +
arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
arch/arm/boot/dts/exynos4412-ppmu-common.dtsi | 49 +
arch/arm/boot/dts/exynos4412-trats2.dts | 41 +
5 files changed, 53 insertions(+), 120 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
diff --git a/arch/arm/boot/dts/exynos3250-monk.dts
b/arch/arm/boot/dts/exynos3250-monk.dts
index 456844a81189..a4e525e5e6e4 100644
--- a/arch/arm/boot/dts/exynos3250-monk.dts
+++ b/arch/arm/boot/dts/exynos3250-monk.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include "exynos3250.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
#include
#include
#include
@@ -464,46 +465,6 @@
status = "okay";
};
-&ppmu_dmc0 {
- status = "okay";
-
- events {
- ppmu_dmc0_3: ppmu-event3-dmc0 {
- event-name = "ppmu-event3-dmc0";
- };
- };
-};
-
-&ppmu_dmc1 {
- status = "okay";
-
- events {
- ppmu_dmc1_3: ppmu-event3-dmc1 {
- event-name = "ppmu-event3-dmc1";
- };
- };
-};
-
-&ppmu_leftbus {
- status = "okay";
-
- events {
- ppmu_leftbus_3: ppmu-event3-leftbus {
- event-name = "ppmu-event3-leftbus";
- };
- };
-};
-
-&ppmu_rightbus {
- status = "okay";
-
- events {
- ppmu_rightbus_3: ppmu-event3-rightbus {
- event-name = "ppmu-event3-rightbus";
- };
- };
-};
-
&xusbxti {
clock-frequency = <2400>;
};
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index d6bb990ce931..2a1c22598fdc 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -14,6 +14,7 @@
/dts-v1/;
#include "exynos3250.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
#include
#include
#include
@@ -641,46 +642,6 @@
status = "okay";
};
-&ppmu_dmc0 {
- status = "okay";
-
- events {
- ppmu_dmc0_3: ppmu-event3-dmc0 {
- event-name = "ppmu-event3-dmc0";
- };
- };
-};
-
-&ppmu_dmc1 {
- status = "okay";
-
- events {
- ppmu_dmc1_3: ppmu-event3-dmc1 {
- event-name = "ppmu-event3-dmc1";
- };
- };
-};
-
-&ppmu_leftbus {
- status = "okay";
-
- events {
- ppmu_leftbus_3: ppmu-event3-leftbus {
- event-name = "ppmu-event3-leftbus";
- };
- };
-};
-
-&ppmu_rightbus {
- status = "okay";
-
- events {
- ppmu_rightbus_3: ppmu-event3-rightbus {
- event-name = "ppmu-event3-rightbus";
- };
- };
-};
-
&xusbxti {
clock-frequency = <2400>;
};
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 395c3ca9601e..cda1ec86dfba 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -11,6 +11,7 @@
#include
#include
#include "exynos4412.dtsi"
+#include "exynos4412-ppmu-common.dtsi"
#include
/ {
diff --git a/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
new file mode 100644
index ..653904c5d479
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4412-ppmu-common.dtsi
@@ -0,0 +1,49 @@
+/*
+ * Device tree sources for Exynos4412 PPMU common device tree
+ *
+ * Copyright (c) 2015 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.
+ */
+
+&ppmu_dmc0 {
+ status = "okay";
+
+ events {
+ ppmu_dmc0_3: ppmu-event3-dmc0 {
+ event-name = "ppmu-event3-dmc0";
+ };
+ };
+};
+
+&ppmu_dmc1 {
+ status = "okay";
+
+ events {
+ ppmu_dmc1_3: ppmu-event3-dmc1 {
+ event-name = "ppmu-event3-dmc1";
+ };
+ };
+};
+
+&ppmu_leftbus {
+ status = "okay";
+
+ events {
+ ppmu_leftbus_3: ppmu-event3-leftbus {
+ event-name = "ppmu-event3-leftbus";
+ };
+ };
+};
+
+&ppmu_rightbus {
+ status = "okay";
+
+ events {
+ ppmu_rightbus_3: ppmu-event3-rightbus {
+ event-name = "ppmu-event3-rightbus";
+ };
+
[PATCH v3 16/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4210
This patch adds the bus nodes for Exynos4210 SoC. Exynos4210 SoC has
one power line for all buses to translate data between DRAM and sub-blocks.
Following list specifies the detailed relation between DRAM and sub-blocks:
- DMC/ACP clock for DMC (Dynamic Memory Controller)
- ACLK200 clock for LCD0
- ACLK100 clock for PERIL/PERIR/MFC(PCLK)
- ACLK160 clock for CAM/TV/LCD0/LCD1
- ACLK133 clock for FSYS/GPS
- GDL/GDR clock for LEFTBUS/RIGHTBUS
- SCLK_MFC clock for MFC
Signed-off-by: Chanwoo Choi
---
arch/arm/boot/dts/exynos4210.dtsi | 159 ++
1 file changed, 159 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index c1cb8df6da07..2d9b02967105 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -257,6 +257,165 @@
power-domains = <&pd_lcd1>;
#iommu-cells = <0>;
};
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_acp: bus_acp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_ACP>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_acp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_peri: bus_peri {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK100>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_peri_opp_table>;
+ status = "disabled";
+ };
+
+ bus_fsys: bus_fsys {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK133>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_fsys_opp_table>;
+ status = "disabled";
+ };
+
+ bus_display: bus_display {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK160>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_display_opp_table>;
+ status = "disabled";
+ };
+
+ bus_lcd0: bus_lcd0 {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_ACLK200>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_leftbus: bus_leftbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDL>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_rightbus: bus_rightbus {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_GDR>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_mfc: bus_mfc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_SCLK_MFC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_leftbus_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <1025000>;
+ };
+ opp@26700 {
+ opp-hz = /bits/ 64 <26700>;
+ opp-microvolt = <105>;
+ };
+ opp@4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <115>;
+ };
+ };
+
+ bus_acp_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ };
+ opp@16000 {
+ opp-hz = /bits/ 64 <16000>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ };
+ };
+
+ bus_peri_opp_table: opp_table3 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@500 {
+ opp-hz = /bits/ 64 <500>;
+ };
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ };
+ };
+
+ bus_fsys_opp_table: opp_table4 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@1000
[PATCH v3 20/20] ARM: dts: Add support of bus frequency for exynos4412-trats/odroidu3
THis patch adds the bus device tree nodes for both MIF (Memory) and INT
(Internal) block to enable the bus frequency.
The DMC bus is parent device in MIF block using VDD_MIF and the LEFTBUS
bus is parent device in INT block using VDD_INT.
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 47
arch/arm/boot/dts/exynos4412-trats2.dts | 48 +
2 files changed, 95 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 7bd65026761e..b6818aec7cf9 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -501,3 +501,50 @@
&watchdog {
status = "okay";
};
+
+&bus_acp {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_c2c {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
+&bus_display {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peri {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 92438eb6eec6..0b8aff3b8cb7 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -1251,3 +1251,51 @@
vtmu-supply = <&ldo10_reg>;
status = "okay";
};
+
+&bus_acp {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_c2c {
+ devfreq = <&bus_dmc>;
+ status = "okay";
+};
+
+&bus_dmc {
+ devfreq-events = <&ppmu_dmc0_3>, <&ppmu_dmc1_3>;
+ vdd-supply = <&buck1_reg>;
+ status = "okay";
+};
+
+&bus_display {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peri {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
--
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 v3 19/20] ARM: dts: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
This patch expands the voltage range of buck1/3 regulator due to as following:
- MIF (Memory Interface) bus frequency needs the range of '900 - 1050 mV'.
- INT (Internal) bus frequency needs the range of '900 - 1000 mV'.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index cda1ec86dfba..7bd65026761e 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -356,8 +356,8 @@
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
- regulator-min-microvolt = <100>;
- regulator-max-microvolt = <100>;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <105>;
regulator-always-on;
regulator-boot-on;
};
@@ -372,7 +372,7 @@
buck3_reg: BUCK3 {
regulator-name = "vdd_int";
- regulator-min-microvolt = <100>;
+ regulator-min-microvolt = <90>;
regulator-max-microvolt = <100>;
regulator-always-on;
regulator-boot-on;
--
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 v3 18/20] ARM: dts: Add support of bus frequency using VDD_INT for exynos3250-rinato
This patch adds the bus device-tree node of INT (internal) block
to enable the bus frequency scaling. The following sub-blocks share
the VDD_INT power source:
- LEFTBUS (parent device)
- RIGHTBUS
- PERIL
- LCD0
- FSYS
- MCUISP / ISP
- MFC
The LEFTBUS is parent device with devfreq ondemand governor
and the rest devices has the dependency on LEFTBUS bus.
Signed-off-by: Chanwoo Choi
Reviewed-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250-rinato.dts | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 2a1c22598fdc..37c777cad953 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -154,6 +154,47 @@
status = "okay";
};
+&bus_fsys {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_isp {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_lcd0 {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_leftbus {
+ devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
+ vdd-supply = <&buck3_reg>;
+ status = "okay";
+};
+
+&bus_mfc {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_mcuisp {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_peril {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
+&bus_rightbus {
+ devfreq = <&bus_leftbus>;
+ status = "okay";
+};
+
&cpu0 {
cpu0-supply = <&buck2_reg>;
};
--
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 v3 14/20] ARM: dts: Add bus nodes using VDD_MIF for Exynos4x12
This patch adds the bus noes using VDD_MIF for Exynos4x12 SoC.
Exynos4x12 has the following AXI buses to translate data
between DRAM and DMC/ACP/C2C.
Signed-off-by: Chanwoo Choi
[linux.amoon: Tested on Odroid U3]
Tested-by: Anand Moon
---
arch/arm/boot/dts/exynos4x12.dtsi | 68 +++
1 file changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 84a23f962946..99a0f4ca3d47 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -281,6 +281,74 @@
clocks = <&clock CLK_SMMU_LITE1>, <&clock CLK_FIMC_LITE1>;
#iommu-cells = <0>;
};
+
+ bus_dmc: bus_dmc {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_DMC>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_acp: bus_acp {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_ACP>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_acp_opp_table>;
+ status = "disabled";
+ };
+
+ bus_c2c: bus_c2c {
+ compatible = "samsung,exynos-bus";
+ clocks = <&clock CLK_DIV_C2C>;
+ clock-names = "bus";
+ operating-points-v2 = <&bus_dmc_opp_table>;
+ status = "disabled";
+ };
+
+ bus_dmc_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ opp-microvolt = <90>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ opp-microvolt = <90>;
+ };
+ opp@16000 {
+ opp-hz = /bits/ 64 <16000>;
+ opp-microvolt = <90>;
+ };
+ opp@26700 {
+ opp-hz = /bits/ 64 <26700>;
+ opp-microvolt = <95>;
+ };
+ opp@4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <105>;
+ };
+ };
+
+ bus_acp_opp_table: opp_table2 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp@1 {
+ opp-hz = /bits/ 64 <1>;
+ };
+ opp@13400 {
+ opp-hz = /bits/ 64 <13400>;
+ };
+ opp@16000 {
+ opp-hz = /bits/ 64 <16000>;
+ };
+ opp@26700 {
+ opp-hz = /bits/ 64 <26700>;
+ };
+ };
};
&combiner {
--
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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
Hello Viresh,
On 12/11/2015 01:38 AM, Viresh Kumar wrote:
> On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
>> We had such configuration before (before df09df6f9ac3). I don't see any
>> benefit in what you described. Where is the "thing" to be fixed? It is
>> mixed up. The contiguous ordering is easier to read and more natural.
>
> This is what you are doing today (keeping on one CPU per cluster to
> simplify it):
>
> cpu0: cpu@0 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x0>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> };
>
> cpu4: cpu@100 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> reg = <0x100>;
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> };
>
>
> Then you overwrite it with:
>
> &cpu0 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> reg = <0x100>;
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> };
>
> &cpu4 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x0>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> };
>
>
> Don't you think this isn't the right way of solving problems?
>
> The DT overwrite feature isn't there to do such kind of stuff, though
> it doesn't stop you from doing that.
>
I still fail to understand why the override is not a good way to solve
the issue.
> Either you should keep separate paths for both the SoCs, or can solve
There's no point IMHO to duplicate the HW description since is the only
difference between the Exynos5422 and Exynos5800 SoCs AFAIK.
> it the way I suggested earlier.
>
As Krzysztof said, contiguous ordering is more natural and easier to
read and I agree with him.
> This came up because in the current series you are doing this:
>
> cpu0: cpu@0 {
> compatible = "arm,cortex-a15";
> operating-points-v2 = <&cpu0_opp_table>;
> };
>
> cpu4: cpu@100 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> operating-points-v2 = <&cpu1_opp_table>;
> };
>
>
> Then you overwrite it with:
>
> &cpu0 {
> compatible = "arm,cortex-a7";
> operating-points-v2 = <&cpu1_opp_table>;
But yes, I agree with you that the OPP tables names are misleading at the
very least for not saying wrong. So yes, either {cluster0,a7,kfc}_opp_table
as you suggest are much better possible names and the same for the a15 one.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11.12.2015 13:38, Viresh Kumar wrote:
> On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
>> We had such configuration before (before df09df6f9ac3). I don't see any
>> benefit in what you described. Where is the "thing" to be fixed? It is
>> mixed up. The contiguous ordering is easier to read and more natural.
>
> This is what you are doing today (keeping on one CPU per cluster to
> simplify it):
>
> cpu0: cpu@0 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x0>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> };
>
> cpu4: cpu@100 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> reg = <0x100>;
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> };
>
>
> Then you overwrite it with:
>
> &cpu0 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> reg = <0x100>;
> clock-frequency = <10>;
> cci-control-port = <&cci_control0>;
> };
>
> &cpu4 {
> device_type = "cpu";
> compatible = "arm,cortex-a15";
> reg = <0x0>;
> clock-frequency = <18>;
> cci-control-port = <&cci_control1>;
> };
>
>
> Don't you think this isn't the right way of solving problems?
>
> The DT overwrite feature isn't there to do such kind of stuff, though
> it doesn't stop you from doing that.
This is quite ugly, indeed, and it is getting uglier :)... but it does
not violate the idea of DT to describe the hardware. Both hardware
descriptions - the 5420 and overridden - are entirely correct... because
the CPU ordering comes from booting sequence (actually code in IROM
decides according to pulled up GPIO gpg2-1).
> Either you should keep separate paths for both the SoCs,
I like that idea. That makes it much more readable. Thanks for feedback!
I will send a patch for that.
> or can solve
> it the way I suggested earlier.
>
> This came up because in the current series you are doing this:
>
> cpu0: cpu@0 {
> compatible = "arm,cortex-a15";
> operating-points-v2 = <&cpu0_opp_table>;
> };
>
> cpu4: cpu@100 {
> device_type = "cpu";
> compatible = "arm,cortex-a7";
> operating-points-v2 = <&cpu1_opp_table>;
> };
>
>
> Then you overwrite it with:
>
> &cpu0 {
> compatible = "arm,cortex-a7";
> operating-points-v2 = <&cpu1_opp_table>;
> };
>
> &cpu4 {
> compatible = "arm,cortex-a15";
> operating-points-v2 = <&cpu0_opp_table>;
> };
Yes, it is getting uglier with each change...
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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 10-12-15, 17:58, Bartlomiej Zolnierkiewicz wrote:
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi
> b/arch/arm/boot/dts/exynos5420.dtsi
> index 48a0a55..616c2d0 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -50,6 +50,116 @@
> usbdrdphy1 = &usbdrd_phy1;
> };
>
> + cpu0_opp_table: opp_table0 {
Over and above what we are discussing in this thread, this should be
named cluster0_opp_table or cluster_a7_opp_table, not cpu0 as the
other one is never for cpu1 but cpu4.
--
viresh
--
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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 13:18, Krzysztof Kozlowski wrote:
> We had such configuration before (before df09df6f9ac3). I don't see any
> benefit in what you described. Where is the "thing" to be fixed? It is
> mixed up. The contiguous ordering is easier to read and more natural.
This is what you are doing today (keeping on one CPU per cluster to
simplify it):
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
clock-frequency = <18>;
cci-control-port = <&cci_control1>;
};
cpu4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
clock-frequency = <10>;
cci-control-port = <&cci_control0>;
};
Then you overwrite it with:
&cpu0 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
clock-frequency = <10>;
cci-control-port = <&cci_control0>;
};
&cpu4 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
clock-frequency = <18>;
cci-control-port = <&cci_control1>;
};
Don't you think this isn't the right way of solving problems?
The DT overwrite feature isn't there to do such kind of stuff, though
it doesn't stop you from doing that.
Either you should keep separate paths for both the SoCs, or can solve
it the way I suggested earlier.
This came up because in the current series you are doing this:
cpu0: cpu@0 {
compatible = "arm,cortex-a15";
operating-points-v2 = <&cpu0_opp_table>;
};
cpu4: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
operating-points-v2 = <&cpu1_opp_table>;
};
Then you overwrite it with:
&cpu0 {
compatible = "arm,cortex-a7";
operating-points-v2 = <&cpu1_opp_table>;
};
&cpu4 {
compatible = "arm,cortex-a15";
operating-points-v2 = <&cpu0_opp_table>;
};
--
viresh
--
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] pwm: Avoid double mutex lock on pwm_enable
On 11.12.2015 13:07, Anand Moon wrote:
> Hi Krzysztof,
>
> On 22 November 2015 at 05:43, Krzysztof Kozlowski
> wrote:
>> 2015-11-22 3:14 GMT+09:00 Anand Moon :
>>> Hi Krzysztof,
[...]
>> Yes, now you pasted the same warning I did...
>>
>> This is still the same issue. I already wrote it:
>>> 1. BUG: sleeping function called from invalid context
>>> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>>
>> We can repeat it many times but that won't change anything...
>>
>> Best regards,
>> Krzysztof
>
> Would you consider below changes to fix the above issue.
> I have tested this change by enabling CONFIG_DEBUG_ATOMIC_SLEEP
> And I don't observed issue.
>
> 1. BUG: sleeping function called from invalid context
> 2. DEBUG_LOCKS_WARN_ON(in_interrupt())
>
> Please share your thought on this changes.
>
> root@odroidxu4:/usr/src/odroidxu3-4.y-devel# git diff drivers/pwm/core.c
> diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
> index d24ca5f..f3f6cf9 100644
> --- a/drivers/pwm/core.c
> +++ b/drivers/pwm/core.c
> @@ -506,6 +506,9 @@ int pwm_enable(struct pwm_device *pwm)
> if (!pwm)
> return -EINVAL;
>
> + if (!mutex_is_locked(&pwm->lock))
> + return -EINVAL;
> +
> mutex_lock(&pwm->lock);
>
> if (!test_and_set_bit(PWMF_ENABLED, &pwm->flags)) {
First of all, Thierry suggested way of fixing this:
"Any objections to simply removing it and make all users use a workqueue
or some such if they need to control a PWM as a result of an interrupt
trigger?"
what is wrong with his approach?
Second, you are writing something that looks like mutex-try-lock...
which will fail the pwm_enable(). IMHO this *hides* the real issue and
does not solve anything (except hiding also the warning).
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] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 11 December 2015 at 09:37, Anand Moon wrote:
> Hi Krzysztof,
>
> On 22 November 2015 at 05:43, Krzysztof Kozlowski
> wrote:
>> 2015-11-22 3:14 GMT+09:00 Anand Moon :
>>> Hi Krzysztof,
>>>
>>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>>> wrote:
2015-11-21 21:11 GMT+09:00 Anand Moon :
> hi Krzysztof,
>
> On 21 November 2015 at 15:22, Krzysztof Kozlowski
> wrote:
>> 2015-11-21 18:40 GMT+09:00 Anand Moon :
>>> hi Krzysztof,
>>>
>>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>>
>>> wrote:
W dniu 21.11.2015 o 01:59, Anand Moon pisze:
> Commit d1cd21427747f15920cd726f5f67a07880e7dee4
> (pwm: Set enable state properly on failed call to enable)
> introduce double lock of mutex on pwm_enable
>
> Changes fix the following debug lock warning.
>
> [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
> __mutex_lock_slowpath+0x3bc/0x404()
> [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
Hi Anand!
Yeah, I am hitting this as well. Annoying. However your description is
inaccurate. Double lock of mutex does not cause warnings of sleeping or
locking in atomic context (if you build with debug sleep atomic you
will
see different warning). More over you are partially reverting the
commit
d1cd21427747 ("pwm: Set enable state properly on failed call to
enable")
without proper explanation:
1. why this locking is inappropriate;
2. why it is safe to remove the mutex_lock().
Please find the real problem, fix the real problem and throughly
explain
the real issue.
I was suspecting some weird changes in timers. For !irqsafe timer I
think it is safe to use mutexes... but apparently not. Maybe a work
should be scheduled from function called by timer?
Warning with debug atomic sleep:
[ 16.047517] BUG: sleeping function called from invalid context at
../kernel/locking/mutex.c:617
[ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
swapper/0
[ 16.061402] INFO: lockdep is turned off.
[ 16.065281] Preemption disabled at:[< (null)>] (null)
[ 16.070524]
[ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.4.0-rc1-00040-g28c429565d4f #290
[ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 16.086215] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 16.093938] [] (show_stack) from []
(dump_stack+0x70/0xbc)
[ 16.101122] [] (dump_stack) from []
(mutex_lock_nested+0x24/0x474)
[ 16.109009] [] (mutex_lock_nested) from []
(pwm_enable+0x20/0x7c)
[ 16.116799] [] (pwm_enable) from []
(led_heartbeat_function+0xdc/0x140)
[ 16.125119] [] (led_heartbeat_function) from []
(call_timer_fn+0x6c/0xf4)
[ 16.133606] [] (call_timer_fn) from []
(run_timer_softirq+0x1a8/0x230)
[ 16.141846] [] (run_timer_softirq) from []
(__do_softirq+0x134/0x2c0)
[ 16.149982] [] (__do_softirq) from []
(irq_exit+0xd0/0x114)
[ 16.157255] [] (irq_exit) from []
(__handle_domain_irq+0x70/0xe4)
[ 16.165056] [] (__handle_domain_irq) from []
(gic_handle_irq+0x4c/0x94)
[ 16.173376] [] (gic_handle_irq) from []
(__irq_svc+0x58/0x98)
[ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
[ 16.185823] df40:
c0010dcc
[ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
c08ce4bc c08c7364 c08ce4b4
[ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
c0010dd0 600f0013
[ 16.210291] [] (__irq_svc) from []
(arch_cpu_idle+0x20/0x3c)
[ 16.217661] [] (arch_cpu_idle) from []
(cpu_startup_entry+0x17c/0x26c)
[ 16.225899] [] (cpu_startup_entry) from []
(start_kernel+0x368/0x3d0)
Best regards,
Krzysztof
> [2.701737] Modules linked in:
> [2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted
> 4.4.0-rc1-xu4f
> #24
> [2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [2.701787] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [2.701808] [] (show_stack) from []
> (dump_stack+0x84/0xc4)
> [2.701824] [] (dump_stack) from []
> (warn_slowpath_common+0x80/0xb0)
> [2.701836] [] (warn_slowpath_common) from []
> (warn_slowpath_fmt+0x30/0x40)
>
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11.12.2015 13:13, Viresh Kumar wrote: > On 11-12-15, 13:00, Krzysztof Kozlowski wrote: >> It wasn't working like this. The cpu0 got the index from booting cpu, so >> on 5420 cpu0 was A15 and on 5422 it was A7. >> >> Maybe I am not aware of some changes recently in the kernel but how do >> you want to assign the booting CPU proper number (not CPU0)? > > Okay, this is how it works and I don't think you need to change the > order of CPUs based on machines. > > The boot CPU isn't controlled by the DT file but your bootloader, so > it will be A15 on 5420 and A7 on 5422. > > Now if you keep the order in DT as: 0-3 A7 and 4-7 A15 irrespective of > the SoCs, then this is how they will be assigned. > > Linux CPU numbers Actual CPU assigned to them > 54205422 > > CPU0A15-0 (boot)A7-0 (boot) > CPU1A7-0A7-1 > CPU2A7-1A7-2 > CPU3A7-2A7-3 > CPU4A7-3A15-0 > CPU5A15-1 A15-1 > CPU6A15-2 A15-2 > CPU7A15-3 A15-3 > > This happens because all non-boot CPUs will be added in the order they > are present in DT. > > Now, there should be no *real* reason for you to want your CPUs to be > always contiguous, isn't it? > > In the case of 5420, cpufreq will show related CPUs as: > Policy0: CPU0,5-7, Policy1: CPU1-4 > > and in the case of 5422, cpufreq will show related CPUs as: > Policy0: CPU0-3, Policy1: CPU4-7 > > And I think you should really fix this now.. We had such configuration before (before df09df6f9ac3). I don't see any benefit in what you described. Where is the "thing" to be fixed? It is mixed up. The contiguous ordering is easier to read and more natural. 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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 13:00, Krzysztof Kozlowski wrote: > It wasn't working like this. The cpu0 got the index from booting cpu, so > on 5420 cpu0 was A15 and on 5422 it was A7. > > Maybe I am not aware of some changes recently in the kernel but how do > you want to assign the booting CPU proper number (not CPU0)? Okay, this is how it works and I don't think you need to change the order of CPUs based on machines. The boot CPU isn't controlled by the DT file but your bootloader, so it will be A15 on 5420 and A7 on 5422. Now if you keep the order in DT as: 0-3 A7 and 4-7 A15 irrespective of the SoCs, then this is how they will be assigned. Linux CPU numbers Actual CPU assigned to them 54205422 CPU0A15-0 (boot)A7-0 (boot) CPU1A7-0A7-1 CPU2A7-1A7-2 CPU3A7-2A7-3 CPU4A7-3A15-0 CPU5A15-1 A15-1 CPU6A15-2 A15-2 CPU7A15-3 A15-3 This happens because all non-boot CPUs will be added in the order they are present in DT. Now, there should be no *real* reason for you to want your CPUs to be always contiguous, isn't it? In the case of 5420, cpufreq will show related CPUs as: Policy0: CPU0,5-7, Policy1: CPU1-4 and in the case of 5422, cpufreq will show related CPUs as: Policy0: CPU0-3, Policy1: CPU4-7 And I think you should really fix this now.. -- viresh -- 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] pwm: Avoid double mutex lock on pwm_enable
Hi Krzysztof,
On 22 November 2015 at 05:43, Krzysztof Kozlowski
wrote:
> 2015-11-22 3:14 GMT+09:00 Anand Moon :
>> Hi Krzysztof,
>>
>> On 21 November 2015 at 18:37, Krzysztof Kozlowski
>> wrote:
>>> 2015-11-21 21:11 GMT+09:00 Anand Moon :
hi Krzysztof,
On 21 November 2015 at 15:22, Krzysztof Kozlowski
wrote:
> 2015-11-21 18:40 GMT+09:00 Anand Moon :
>> hi Krzysztof,
>>
>> On 21 November 2015 at 09:56, Krzysztof Kozlowski
>>
>> wrote:
>>>
>>> W dniu 21.11.2015 o 01:59, Anand Moon pisze:
>>> > Commit d1cd21427747f15920cd726f5f67a07880e7dee4
>>> > (pwm: Set enable state properly on failed call to enable)
>>> > introduce double lock of mutex on pwm_enable
>>> >
>>> > Changes fix the following debug lock warning.
>>> >
>>> > [2.701720] WARNING: CPU: 3 PID: 0 at kernel/locking/mutex.c:526
>>> > __mutex_lock_slowpath+0x3bc/0x404()
>>> > [2.701731] DEBUG_LOCKS_WARN_ON(in_interrupt())
>>>
>>> Hi Anand!
>>>
>>> Yeah, I am hitting this as well. Annoying. However your description is
>>> inaccurate. Double lock of mutex does not cause warnings of sleeping or
>>> locking in atomic context (if you build with debug sleep atomic you will
>>> see different warning). More over you are partially reverting the commit
>>> d1cd21427747 ("pwm: Set enable state properly on failed call to enable")
>>> without proper explanation:
>>> 1. why this locking is inappropriate;
>>> 2. why it is safe to remove the mutex_lock().
>>>
>>> Please find the real problem, fix the real problem and throughly explain
>>> the real issue.
>>>
>>> I was suspecting some weird changes in timers. For !irqsafe timer I
>>> think it is safe to use mutexes... but apparently not. Maybe a work
>>> should be scheduled from function called by timer?
>>>
>>> Warning with debug atomic sleep:
>>> [ 16.047517] BUG: sleeping function called from invalid context at
>>> ../kernel/locking/mutex.c:617
>>> [ 16.054866] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name:
>>> swapper/0
>>> [ 16.061402] INFO: lockdep is turned off.
>>> [ 16.065281] Preemption disabled at:[< (null)>] (null)
>>> [ 16.070524]
>>> [ 16.072002] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>>> 4.4.0-rc1-00040-g28c429565d4f #290
>>> [ 16.080150] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> [ 16.086215] [] (unwind_backtrace) from []
>>> (show_stack+0x10/0x14)
>>> [ 16.093938] [] (show_stack) from []
>>> (dump_stack+0x70/0xbc)
>>> [ 16.101122] [] (dump_stack) from []
>>> (mutex_lock_nested+0x24/0x474)
>>> [ 16.109009] [] (mutex_lock_nested) from []
>>> (pwm_enable+0x20/0x7c)
>>> [ 16.116799] [] (pwm_enable) from []
>>> (led_heartbeat_function+0xdc/0x140)
>>> [ 16.125119] [] (led_heartbeat_function) from []
>>> (call_timer_fn+0x6c/0xf4)
>>> [ 16.133606] [] (call_timer_fn) from []
>>> (run_timer_softirq+0x1a8/0x230)
>>> [ 16.141846] [] (run_timer_softirq) from []
>>> (__do_softirq+0x134/0x2c0)
>>> [ 16.149982] [] (__do_softirq) from []
>>> (irq_exit+0xd0/0x114)
>>> [ 16.157255] [] (irq_exit) from []
>>> (__handle_domain_irq+0x70/0xe4)
>>> [ 16.165056] [] (__handle_domain_irq) from []
>>> (gic_handle_irq+0x4c/0x94)
>>> [ 16.173376] [] (gic_handle_irq) from []
>>> (__irq_svc+0x58/0x98)
>>> [ 16.180817] Exception stack(0xc08cdf58 to 0xc08cdfa0)
>>> [ 16.185823] df40:
>>>c0010dcc
>>> [ 16.193997] df60: c08cdfa8 c05f57c4 c08ca520
>>> c08ce4bc c08c7364 c08ce4b4
>>> [ 16.202141] df80: c09121ca 0001 c08cdfa8 c0010dcc
>>> c0010dd0 600f0013
>>> [ 16.210291] [] (__irq_svc) from []
>>> (arch_cpu_idle+0x20/0x3c)
>>> [ 16.217661] [] (arch_cpu_idle) from []
>>> (cpu_startup_entry+0x17c/0x26c)
>>> [ 16.225899] [] (cpu_startup_entry) from []
>>> (start_kernel+0x368/0x3d0)
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>>
>>> > [2.701737] Modules linked in:
>>> > [2.701748] CPU: 3 PID: 0 Comm: swapper/3 Not tainted
>>> > 4.4.0-rc1-xu4f
>>> > #24
>>> > [2.701753] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>>> > [2.701787] [] (unwind_backtrace) from []
>>> > (show_stack+0x10/0x14)
>>> > [2.701808] [] (show_stack) from []
>>> > (dump_stack+0x84/0xc4)
>>> > [2.701824] [] (dump_stack) from []
>>> > (warn_slowpath_common+0x80/0xb0)
>>> > [2.701836] [] (warn_slowpath_common) from []
>>> > (warn_slowpath_fmt+0x30/0x40)
>>> > [2.701849] [] (warn_slowpath_fmt) from []
>>> > (__mutex_lock_slowpath+0x3bc/0x404)
>>> > [2.701864] [] (__mutex_lock_slowpath) from []
>>> > (mutex_lock+0xc/0x24)
>>> > [2.701884] [] (mutex_lock
Re: [PATCH v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11.12.2015 12:32, Viresh Kumar wrote: > On 11-12-15, 00:25, Javier Martinez Canillas wrote: >> The problem is that the big and LITTLE cores have different ordering per >> SoCs: >> >> - Exynos5420 and Exynos5800: cpu0-3 (Cortex-A15) and cpu4-7 (Coretx-A7) >> - Exynos5422: cpu0-3 (Cortex-A7) and cpu4-7 (Cortex-A15) >> >> So the OPP tables are set in this DTSI file, to prevent the OPP tables >> in the Exynos5422 to be inverted for the cluster 0 and 1. > > Oh dude, that's really *ugly*. :) > > Reusing files/definitions is fine to the point where things are > readable. But you have screwed it up so very badly. > > Over that, why can't you keep cpu0-3 as A7 and 4-7 as a15 for all the > cases? The only worrying thing for you should be that CPU0 within the > kenrel should be controllable, right? i.e. you want a A15 to boot 5800 > and A7 to boot 5422. > > If yes, than you could have kept the CPUs in 5422 as: > 0-3: A7 > 4-7: A15 > > and in 5420 as: > 4-7: A15 > 0-3: A7 > > Wouldnt' that work ? It wasn't working like this. The cpu0 got the index from booting cpu, so on 5420 cpu0 was A15 and on 5422 it was A7. Maybe I am not aware of some changes recently in the kernel but how do you want to assign the booting CPU proper number (not CPU0)? 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 v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On 2015년 12월 11일 12:24, Rob Herring wrote: > On Fri, Dec 11, 2015 at 12:10:13AM +0900, Chanwoo Choi wrote: >> On Thu, Dec 10, 2015 at 11:21 PM, Rob Herring wrote: >>> On Wed, Dec 09, 2015 at 01:08:01PM +0900, Chanwoo Choi wrote: This patch updates the documentation for passive bus devices and adds the detailed example of Exynos3250. Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/devfreq/exynos-bus.txt | 244 - 1 file changed, 241 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt index 54a1f9c46c88..c4fdc70f8eac 100644 --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt @@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference should be specified in devicetree file instead of each device driver. In result, this driver is able to support the bus frequency for all Exynos SoCs. -Required properties for bus device: +Required properties for all bus devices: - compatible: Should be "samsung,exynos-bus". - clock-names : the name of clock used by the bus, "bus". - clocks : phandles for clock specified in "clock-names" property. - #clock-cells: should be 1. - operating-points-v2: the OPP table including frequency/voltage information to support DVFS (Dynamic Voltage/Frequency Scaling) feature. + +Required properties for only parent bus device: - vdd-supply: the regulator to provide the buses with the voltage. - devfreq-events: the devfreq-event device to monitor the curret utilization of buses. -Optional properties for bus device: +Required properties for only passive bus device: +- devfreq: the parent bus device. + +Optional properties for only parent bus device: - exynos,saturation-ratio: the percentage value which is used to calibrate the performance count againt total cycle count. @@ -33,7 +38,20 @@ Example1: power line (regulator). The MIF (Memory Interface) AXI bus is used to transfer data between DRAM and CPU and uses the VDD_MIF regualtor. - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block + - MIF (Memory Interface) block + : VDD_MIF |--- DMC (Dynamic Memory Controller) + + - INT (Internal) block + : VDD_INT |--- LEFTBUS (parent device) + |--- PERIL + |--- MFC + |--- G3D + |--- RIGHTBUS + |--- FSYS + |--- LCD0 + |--- PERIR + |--- ISP + |--- CAM >>> >>> This still has the same problem as before. I would expect that the bus >>> hierarchy in the dts match the hierarchy here. You just have flat nodes >>> in the example below. So all IP blocks affected by frequency scaling >>> should be under the bus node defining the OPPs. Something like this: >> >> The each bus of sub-block has not h/w dependency among sub-blocks >> and has the owned source clock / OPP table. Just they share the same >> power line. So, I think that flat nodes in the example below is not problem. > > I'm talking about the peripherals not described here. Is the ISP block > not a child of the bus_isp node? Same for the display controller block > and bus_lcd0. And so on. >From the H/W point of view, ISP block is really not included in ISP's AXI bus >(bus_isp). Just, the bus_isp connect to between ISP block and DRAM. Thanks, 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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11-12-15, 00:25, Javier Martinez Canillas wrote: > The problem is that the big and LITTLE cores have different ordering per SoCs: > > - Exynos5420 and Exynos5800: cpu0-3 (Cortex-A15) and cpu4-7 (Coretx-A7) > - Exynos5422: cpu0-3 (Cortex-A7) and cpu4-7 (Cortex-A15) > > So the OPP tables are set in this DTSI file, to prevent the OPP tables > in the Exynos5422 to be inverted for the cluster 0 and 1. Oh dude, that's really *ugly*. :) Reusing files/definitions is fine to the point where things are readable. But you have screwed it up so very badly. Over that, why can't you keep cpu0-3 as A7 and 4-7 as a15 for all the cases? The only worrying thing for you should be that CPU0 within the kenrel should be controllable, right? i.e. you want a A15 to boot 5800 and A7 to boot 5422. If yes, than you could have kept the CPUs in 5422 as: 0-3: A7 4-7: A15 and in 5420 as: 4-7: A15 0-3: A7 Wouldnt' that work ? -- viresh -- 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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
Hello Viresh, On 12/11/2015 12:16 AM, Viresh Kumar wrote: > On 10-12-15, 17:58, Bartlomiej Zolnierkiewicz wrote: >> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi >> b/arch/arm/boot/dts/exynos5422-cpus.dtsi >> index b7f60c8..9a5131d 100644 >> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi >> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi >> @@ -20,8 +20,10 @@ >> device_type = "cpu"; >> compatible = "arm,cortex-a7"; >> reg = <0x100>; >> +clocks = <&clock CLK_KFC_CLK>; >> clock-frequency = <10>; >> cci-control-port = <&cci_control0>; >> +operating-points-v2 = <&cpu1_opp_table>; >> }; > > Why do you need to update this file? This file is included by > exynos5422-odroidxu3-common.dtsi, which already inherits cpus nodes > from exynos5800.dtsi (which inherits exynos5420.dtsi). > > i.e. operating-points-v2 should already be set. > The problem is that the big and LITTLE cores have different ordering per SoCs: - Exynos5420 and Exynos5800: cpu0-3 (Cortex-A15) and cpu4-7 (Coretx-A7) - Exynos5422: cpu0-3 (Cortex-A7) and cpu4-7 (Cortex-A15) So the OPP tables are set in this DTSI file, to prevent the OPP tables in the Exynos5422 to be inverted for the cluster 0 and 1. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On Fri, Dec 11, 2015 at 12:10:13AM +0900, Chanwoo Choi wrote: > On Thu, Dec 10, 2015 at 11:21 PM, Rob Herring wrote: > > On Wed, Dec 09, 2015 at 01:08:01PM +0900, Chanwoo Choi wrote: > >> This patch updates the documentation for passive bus devices and adds the > >> detailed example of Exynos3250. > >> > >> Signed-off-by: Chanwoo Choi > >> --- > >> .../devicetree/bindings/devfreq/exynos-bus.txt | 244 > >> - > >> 1 file changed, 241 insertions(+), 3 deletions(-) > >> > >> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > >> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > >> index 54a1f9c46c88..c4fdc70f8eac 100644 > >> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > >> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt > >> @@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference > >> should be specified > >> in devicetree file instead of each device driver. In result, this driver > >> is able to support the bus frequency for all Exynos SoCs. > >> > >> -Required properties for bus device: > >> +Required properties for all bus devices: > >> - compatible: Should be "samsung,exynos-bus". > >> - clock-names : the name of clock used by the bus, "bus". > >> - clocks : phandles for clock specified in "clock-names" property. > >> - #clock-cells: should be 1. > >> - operating-points-v2: the OPP table including frequency/voltage > >> information > >>to support DVFS (Dynamic Voltage/Frequency Scaling) feature. > >> + > >> +Required properties for only parent bus device: > >> - vdd-supply: the regulator to provide the buses with the voltage. > >> - devfreq-events: the devfreq-event device to monitor the curret > >> utilization > >>of buses. > >> > >> -Optional properties for bus device: > >> +Required properties for only passive bus device: > >> +- devfreq: the parent bus device. > >> + > >> +Optional properties for only parent bus device: > >> - exynos,saturation-ratio: the percentage value which is used to calibrate > >> the performance count againt total cycle count. > >> > >> @@ -33,7 +38,20 @@ Example1: > >> power line (regulator). The MIF (Memory Interface) AXI bus is used to > >> transfer data between DRAM and CPU and uses the VDD_MIF regualtor. > >> > >> - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) > >> block > >> + - MIF (Memory Interface) block > >> + : VDD_MIF |--- DMC (Dynamic Memory Controller) > >> + > >> + - INT (Internal) block > >> + : VDD_INT |--- LEFTBUS (parent device) > >> + |--- PERIL > >> + |--- MFC > >> + |--- G3D > >> + |--- RIGHTBUS > >> + |--- FSYS > >> + |--- LCD0 > >> + |--- PERIR > >> + |--- ISP > >> + |--- CAM > > > > This still has the same problem as before. I would expect that the bus > > hierarchy in the dts match the hierarchy here. You just have flat nodes > > in the example below. So all IP blocks affected by frequency scaling > > should be under the bus node defining the OPPs. Something like this: > > The each bus of sub-block has not h/w dependency among sub-blocks > and has the owned source clock / OPP table. Just they share the same > power line. So, I think that flat nodes in the example below is not problem. I'm talking about the peripherals not described here. Is the ISP block not a child of the bus_isp node? Same for the display controller block and bus_lcd0. And so on. Rob -- 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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 10-12-15, 17:58, Bartlomiej Zolnierkiewicz wrote: > diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi > b/arch/arm/boot/dts/exynos5422-cpus.dtsi > index b7f60c8..9a5131d 100644 > --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi > +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi > @@ -20,8 +20,10 @@ > device_type = "cpu"; > compatible = "arm,cortex-a7"; > reg = <0x100>; > + clocks = <&clock CLK_KFC_CLK>; > clock-frequency = <10>; > cci-control-port = <&cci_control0>; > + operating-points-v2 = <&cpu1_opp_table>; > }; Why do you need to update this file? This file is included by exynos5422-odroidxu3-common.dtsi, which already inherits cpus nodes from exynos5800.dtsi (which inherits exynos5420.dtsi). i.e. operating-points-v2 should already be set. -- viresh -- 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 38/58] mtd: nand: s3c2410: use the mtd instance embedded in struct nand_chip
On 10.12.2015 17:00, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Make use of this mtd instance.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes generated with the following coccinelle script
>
> --->8---
> virtual patch
>
> @fix1@
> identifier __chipfield, __mtdfield;
> type __type;
> @@
> (
> __type {
> ...
> struct nand_chip __chipfield;
> ...
> - struct mtd_info __mtdfield;
> ...
> };
> |
> __type {
> ...
> - struct mtd_info __mtdfield;
> ...
> struct nand_chip __chipfield;
> ...
> };
> )
>
> @fix2 depends on fix1@
> identifier fix1.__chipfield, fix1.__mtdfield;
> identifier __subfield;
> type fix1.__type;
> __type *__priv;
> @@
> (
> - __priv->__mtdfield.__subfield
> + nand_to_mtd(&__priv->__chipfield)->__subfield
> |
> - &(__priv->__mtdfield)
> + nand_to_mtd(&__priv->__chipfield)
> )
> --->8---
> ---
> drivers/mtd/nand/s3c2410.c | 23 ++-
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
Looks correct:
Reviewed-by: Krzysztof Kozlowski
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 v2 16/19] ARM: dts: Add PPMU node for exynos4412-odroidu3
On 2015년 12월 10일 15:44, Krzysztof Kozlowski wrote:
> On 09.12.2015 13:08, Chanwoo Choi wrote:
>> This patch add dt node for PPMU_{DMC0|DMC1|LEFTBUS|RIGHTBUS} for
>> exynos4412-odroidu3 board. Each PPMU dt node includes one event of
>> 'PPMU Count3'.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 40
>> +
>> 1 file changed, 40 insertions(+)
>>
>
> The patch itself is good but now I see that it is duplicated with
> Rinato, Monk and Trats2. Probably for all other Exynos4 and
> one-cluster-Exynos5 boards this would be exactly the same as well.
>
> How about making a DTSI file with common PPMU events configuration?
OK. I'll make the exynos4412-ppmu-common.dtsi.
The Exynos4 series used the PPMU firstly. That is why deciding the filename
of exynos4412-ppmu-common.dtsi.
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 v5 0/7] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patch series adds generic cpufreq-dt driver support for > Exynos542x/5800 (using the new CPU clock type which allows it). > > It has been tested on Exynos5422 based ODROID-XU3 Lite board. > > Depends on: > - next-20151124 branch of linux-next kernel tree Bartlomiej, Thanks for update! Nice work. Everything looks good for me. As for merging, my last pull requests are waiting on Kukjin, so I am not grabbing more stuff till they get in. This (I hope) should happen this weekend so: 1. Either Kukjin will pick it up directly, 2. I could apply this later and hopefully still send them for v4.5. Sylwester, However in case of any delay, how about merging clock changes now through clock tree and preparing a tag for samsung-soc? If the series won't make till v4.5 then at least dependency would be merged. In that case you could also pick the first patch from Marek's GSCL clock. 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 v5 7/7] ARM: Exynos: use generic cpufreq driver for Exynos5422/5800
On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote: > The new CPU clock type allows the use of generic cpufreq-dt driver > for Exynos5422/5800. > > Cc: Tomasz Figa > Cc: Kukjin Kim > Cc: Javier Martinez Canillas > Cc: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > arch/arm/mach-exynos/exynos.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Krzysztof Kozlowski 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 v5 6/7] ARM: dts: Exynos5800: fix CPU OPP
On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote: > Fix CPU operating points for Exynos5800 (it use different > voltages than Exynos5420 and supports additional frequencies). > However don't use 2000MHz & 1900MHz OPPs (for A15 cores) and > 1400MHz OPP (for A7 cores) for now as they are not available > on all boards. > > Based on Hardkernel's kernel for ODROID-XU3 board. > > Changes by Ben Gamari: > - Port to operating-points-v2 > > Cc: Kukjin Kim > Cc: Doug Anderson > Cc: Javier Martinez Canillas > Cc: Andreas Faerber > Cc: Thomas Abraham > Signed-off-by: Ben Gamari > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > arch/arm/boot/dts/exynos5800.dtsi | 108 > ++ > 1 file changed, 108 insertions(+) > Reviewed-by: Krzysztof Kozlowski 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 v5 4/7] ARM: Exynos: use generic cpufreq driver for Exynos5420
On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote: > The new CPU clock type allows the use of cpufreq-dt driver > for Exynos5420. > > Cc: Tomasz Figa > Cc: Kukjin Kim > Cc: Javier Martinez Canillas > Cc: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > arch/arm/mach-exynos/exynos.c | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Krzysztof Kozlowski 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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote: > From: Thomas Abraham > > For Exynos542x/5800 platforms, add CPU operating points > for migrating from Exynos specific cpufreq driver to using > generic cpufreq driver. > > Changes by Bartlomiej: > - split Exynos5420 support from the original patch > - merged Exynos5422 fixes from Ben > > Changes by Ben Gamari: > - Port to operating-points-v2 > > Cc: Kukjin Kim > Cc: Doug Anderson > Cc: Javier Martinez Canillas > Cc: Andreas Faerber > Signed-off-by: Thomas Abraham > Signed-off-by: Ben Gamari > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > arch/arm/boot/dts/exynos5420.dtsi | 122 > + > arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 +++ > 2 files changed, 132 insertions(+) > Reviewed-by: Krzysztof Kozlowski 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 v5 1/7] ARM: dts: Exynos542x/5800: add cluster regulator supply properties
On 11.12.2015 01:58, Bartlomiej Zolnierkiewicz wrote: > Add cluster regulator supply properties as a preparation to > adding generic cpufreq-dt driver support for Exynos542x and > Exynos5800 based boards. > > Cc: Kukjin Kim > Cc: Doug Anderson > Cc: Javier Martinez Canillas > Cc: Andreas Faerber > Cc: Thomas Abraham > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 8 > arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 > arch/arm/boot/dts/exynos5420-smdk5420.dts | 8 > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 > arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 > 5 files changed, 40 insertions(+) > Reviewed-by: Krzysztof Kozlowski 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 v4 4/8] ARM: Exynos: use generic cpufreq driver for Exynos5420
On 10.12.2015 23:18, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Tuesday, December 08, 2015 04:36:12 PM Krzysztof Kozlowski wrote:
>> On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
>>> From: Thomas Abraham
>>>
>>> The new CPU clock type allows the use of cpufreq-dt driver
>>> for Exynos5420.
>>>
>>> Changes by Bartlomiej:
>>> - split Exynos5420 support from the original patch
>>> - disable cpufreq if big.LITTLE switcher support is enabled
>>> - switch to using cpufreq-dt driver
>>>
>>> Cc: Tomasz Figa
>>> Cc: Kukjin Kim
>>> Cc: Javier Martinez Canillas
>>> Signed-off-by: Thomas Abraham
>>> Signed-off-by: Bartlomiej Zolnierkiewicz
>>> ---
>>> arch/arm/mach-exynos/exynos.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>
>> I think this is actually now your patch, not Thomas any more. :)
>
> It seems so, I'll update the patch.
>
>>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>>> index 1c47aee..7a89c9d 100644
>>> --- a/arch/arm/mach-exynos/exynos.c
>>> +++ b/arch/arm/mach-exynos/exynos.c
>>> @@ -230,6 +230,9 @@ static const struct of_device_id
>>> exynos_cpufreq_matches[] = {
>>> { .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
>>> { .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
>>> { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
>>> +#ifndef CONFIG_BL_SWITCHER
>>> + { .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
>>> +#endif
>>
>> Why not on BL_SWITCHER? Shouldn't be enough to disable ARM_DT_BL_CPUFREQ?
>
> ARM_DT_BL_CPUFREQ is not relevant here (it requires to be explicitly
> enabled by platform code, just like cpufreq-dt) and the dependency on
> !BL_SWITCHER is needed because when BL_SWITCHER is enabled big and
> LITTLE cores are grouped in pairs and presented as "virtual" CPUs to
> the system:
>
> ...
> [0.002630] CPU0: update cpu_capacity 448
> [0.002646] CPU0: thread -1, cpu 0, socket 1, mpidr 8100
> [0.002835] Setting up static identity map for 0x40008280 - 0x400082d8
> [0.003106] ARM CCI driver probed
> [0.003351] Exynos MCPM support installed
> [0.045350] CPU1: update cpu_capacity 448
> [0.045358] CPU1: thread -1, cpu 1, socket 1, mpidr 8101
> [0.060326] CPU2: update cpu_capacity 448
> [0.060334] CPU2: thread -1, cpu 2, socket 1, mpidr 8102
> [0.075326] CPU3: update cpu_capacity 448
> [0.075334] CPU3: thread -1, cpu 3, socket 1, mpidr 8103
> [0.090337] CPU4: update cpu_capacity 1535
> [0.090345] CPU4: thread -1, cpu 0, socket 0, mpidr 8000
> [0.105314] CPU5: update cpu_capacity 1535
> [0.105321] CPU5: thread -1, cpu 1, socket 0, mpidr 8001
> [0.120338] CPU6: update cpu_capacity 1535
> [0.120345] CPU6: thread -1, cpu 2, socket 0, mpidr 8002
> [0.135330] CPU7: update cpu_capacity 1535
> [0.135338] CPU7: thread -1, cpu 3, socket 0, mpidr 8003
> [0.135466] Brought up 8 CPUs
> ...
> [3.027498] big.LITTLE switcher initializing
> [3.031761] CPU0 paired with CPU7
> [3.035055] CPU1 paired with CPU6
> [3.038332] CPU2 paired with CPU5
> [3.041598] CPU3 paired with CPU4
> [3.044930] GIC ID for CPU 0 cluster 1 is 4
> [3.049078] GIC ID for CPU 1 cluster 1 is 5
> [3.053258] GIC ID for CPU 2 cluster 1 is 6
> [3.057370] GIC ID for CPU 3 cluster 1 is 7
> [3.061558] GIC ID for CPU 0 cluster 0 is 0
> [3.083336] IRQ53 no longer affine to CPU4
> [3.084336] CPU4: shutdown
> [3.107059] GIC ID for CPU 1 cluster 0 is 1
> [3.123303] IRQ54 no longer affine to CPU5
> [3.124213] CPU5: shutdown
> [3.146387] GIC ID for CPU 2 cluster 0 is 2
> [3.158143] cpu cpu0: 1100 MHz, 1250 mV --> 900 MHz, 1100 mV
> [3.168228] IRQ55 no longer affine to CPU6
> [3.169135] CPU6: shutdown
> [3.191485] GIC ID for CPU 3 cluster 0 is 3
> [3.208264] IRQ56 no longer affine to CPU7
> [3.209166] CPU7: shutdown
> [3.236752] big.LITTLE switcher initialized
> ...
>
> Only arm_big_little_dt driver knows how to handle this setup
> correctly. cpufreq-dt just treats "virtual" CPUs as a LITTLE
> ones. Thus when "virtual CPU"'s current core is switched to
> a big one cpufreq-dt is unable to update its voltage.
>
> [ I tried using BL_SWITCHER_DUMMY_IF functionality to simulate
> this with:
>
> echo 0,0 > /dev/b.L_switcher
>
> but it doesn't seem to work for some reason (from looking at
> arch/arm/common/bL_switcher_dummy_if.c code it seems that at
> least "bL_switcher_write" line should get logged but it does
> not happen). ]
Thank you for explanation, seems good approach.
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 v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()
On Thu, Dec 10, 2015 at 08:59:45AM +0100, Boris Brezillon wrote:
> Unregister the NAND device from the NAND subsystem when removing a denali
> NAND controller, otherwise the MTD attached to the NAND device is still
> exposed by the MTD layer, and accesses to this device will likely crash
> the system.
>
> Signed-off-by: Boris Brezillon
> Cc: #3.8+
Does this follow these rules, from
Documentation/stable_kernel_rules.txt?
- It must be obviously correct and tested.
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).
> Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
> ---
> drivers/mtd/nand/denali.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
> index 67eb2be..8feece3 100644
> --- a/drivers/mtd/nand/denali.c
> +++ b/drivers/mtd/nand/denali.c
> @@ -1622,6 +1622,7 @@ EXPORT_SYMBOL(denali_init);
> /* driver exit point */
> void denali_remove(struct denali_nand_info *denali)
> {
> + nand_release(&denali->mtd);
> denali_irq_cleanup(denali->irq, denali);
> dma_unmap_single(denali->dev, denali->buf.dma_buf,
>denali->mtd.writesize + denali->mtd.oobsize,
It feels a bit odd to allow usage of MTD fields after it has been
unregistered. Maybe precompute this before the nand_release()?
Brian
--
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] ARM: Exynos fixes for v4.4
On Wednesday 02 December 2015 01:04:05 Kukjin Kim wrote: > Krzysztof Kozlowski wrote: > > > Hi Krzysztof, > > Looks good to me, but I have no other fixes in my tree so this would be sent > to > out arm-soc directly > > Hi Arnd, Olof, Kevin, > Please pull this for v4.4. > Pulled into fixes now, 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
[PATCH v3] PCI: hosts: mark pcie/pci (msi) irq cascade handler as IRQF_NO_THREAD
On -RT and if kernel is booting with "threadirqs" cmd line parameter
pcie/pci (msi) irq cascade handlers (like dra7xx_pcie_msi_irq_handler())
will be forced threaded and, as result, will generate warnings like:
WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150
handle_irq_event_percpu+0x14c/0x174()
irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts
Backtrace:
(warn_slowpath_common) from [] (warn_slowpath_fmt+0x38/0x40)
(warn_slowpath_fmt) from [] (handle_irq_event_percpu+0x14c/0x174)
(handle_irq_event_percpu) from [] (handle_irq_event+0x84/0xb8)
(handle_irq_event) from [] (handle_simple_irq+0x90/0x118)
(handle_simple_irq) from [] (generic_handle_irq+0x30/0x44)
(generic_handle_irq) from [] (dra7xx_pcie_msi_irq_handler+0x7c/0x8c)
(dra7xx_pcie_msi_irq_handler) from []
(irq_forced_thread_fn+0x28/0x5c)
(irq_forced_thread_fn) from [] (irq_thread+0x128/0x204)
This happens because all of them invoke generic_handle_irq() from the
requsted handler. generic_handle_irq grabs raw_locks and this needs to
run in raw-irq context.
This issue was originally reproduced on TI dra7-evem, but, as was
identified during dicussion [1], other PCI(e) hosts can also suffer
from this issue. So let's fix all them at once and mark pcie/pci (msi)
irq cascade handlers IRQF_NO_THREAD explicitly.
[1] https://lkml.org/lkml/2015/11/20/356
Cc: Kishon Vijay Abraham I
Cc: Bjorn Helgaas
Cc: Jingoo Han
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Richard Zhu
Cc: Lucas Stach
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Alexandre Courbot
Cc: Simon Horman
Cc: Pratyush Anand
Cc: Michal Simek
Cc: "Sören Brinkmann"
Cc: Sebastian Andrzej Siewior
Signed-off-by: Grygorii Strashko
---
Changes in v3:
- change applied to all affected pci(e) host drivers in drivers/pci/hosts.
After some invsetigation I've decided to not touch arch code - it is not easy
to identify all places which need to be fixed.
if it's still required - i can send separate patches for
arch/mips/pci/msi-octeon.c and arch/sparc/kernel/pci_msi.c.
Links
v2: https://lkml.org/lkml/2015/11/20/356
v1: https://lkml.org/lkml/2015/11/5/593
ref: https://lkml.org/lkml/2015/11/3/660
drivers/pci/host/pci-dra7xx.c | 13 -
drivers/pci/host/pci-exynos.c | 3 ++-
drivers/pci/host/pci-imx6.c | 3 ++-
drivers/pci/host/pci-tegra.c | 2 +-
drivers/pci/host/pcie-rcar.c | 6 --
drivers/pci/host/pcie-spear13xx.c | 3 ++-
drivers/pci/host/pcie-xilinx.c| 3 ++-
7 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
index 8c36880..0415192 100644
--- a/drivers/pci/host/pci-dra7xx.c
+++ b/drivers/pci/host/pci-dra7xx.c
@@ -301,8 +301,19 @@ static int __init dra7xx_add_pcie_port(struct dra7xx_pcie
*dra7xx,
return -EINVAL;
}
+ /*
+* Mark dra7xx_pcie_msi IRQ as IRQF_NO_THREAD
+* On -RT and if kernel is booting with "threadirqs" cmd line parameter
+* the dra7xx_pcie_msi_irq_handler() will be forced threaded but,
+* in the same time, it's IRQ dispatcher and calls generic_handle_irq(),
+* which, in turn, will be resolved to handle_simple_irq() call.
+* The handle_simple_irq() expected to be called with IRQ disabled, as
+* result kernle will display warning:
+* "irq XXX handler YYY+0x0/0x14 enabled interrupts".
+*/
ret = devm_request_irq(&pdev->dev, pp->irq,
- dra7xx_pcie_msi_irq_handler, IRQF_SHARED,
+ dra7xx_pcie_msi_irq_handler,
+ IRQF_SHARED | IRQF_NO_THREAD,
"dra7-pcie-msi", pp);
if (ret) {
dev_err(&pdev->dev, "failed to request irq\n");
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index 01095e1..d997d22 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -522,7 +522,8 @@ static int __init exynos_add_pcie_port(struct pcie_port *pp,
ret = devm_request_irq(&pdev->dev, pp->msi_irq,
exynos_pcie_msi_irq_handler,
- IRQF_SHARED, "exynos-pcie", pp);
+ IRQF_SHARED | IRQF_NO_THREAD,
+ "exynos-pcie", pp);
if (ret) {
dev_err(&pdev->dev, "failed to request msi irq\n");
return ret;
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index 22e8224..9ce7cd1 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -537,7 +537,8 @@ static int __init imx6_add_pcie_port(struct pcie_port *pp,
ret = devm_request_irq(&pdev->dev, pp->msi_irq,
imx6_pcie_msi_handler,
- IRQF_SHARED, "mx6-pcie-msi"
[PATCH v5 0/7] cpufreq: add generic cpufreq driver support for Exynos542x/5800 platforms
Hi, This patch series adds generic cpufreq-dt driver support for Exynos542x/5800 (using the new CPU clock type which allows it). It has been tested on Exynos5422 based ODROID-XU3 Lite board. Depends on: - next-20151124 branch of linux-next kernel tree Changes since v4: - renamed oppXX@hz to opp@hz - put Odroid changes in exynos5422-odroidxu3-common.dtsi - override CPU OPP properties for Exynos5422/5800 instead of duplicating them - merged "ARM: dts: Exynos5422: fix OPP tables" patch with "ARM: dts: Exynos5420: add CPU OPP properties" one - added missing Thomas' SoB line to "ARM: dts: Exynos5420: add CPU OPP properties" patch - updated authorship of "ARM: Exynos: use generic cpufreq driver for Exynos5420" and "ARM: Exynos: use generic cpufreq driver for Exynos5422/5800" patches - updated Javier's and Mike's e-mail adresses - removed non-working e-mail address of Sachin Kamat Changes since v3: - switched to using cpufreq-dt driver - updated patch descriptions to cover Exynos5422 support - added Acked-by from Sylwester to clock driver patches Changes since v2: - ported over next-20151124 branch - integrated missing CLK_RECALC_NEW_RATES flags fix to patch #3 (from Anand Moon) - added regulator supply properties for ODROID-XU3 Lite and ODROID-XU4 in patch #2 - ported CPU OPPs to operating-points-v2 (from Ben Gamari) - added "ARM: dts: Exynos5422: fix OPP tables" patch (from Ben Gamari) - added "cpufreq: arm-big-little: accept operating-points-v2 nodes" patch (from Ben Gamari) - renamed OPP nodes as opp@ Changes since v1: - added CPU cluster regulator supply properties to exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts, exynos5420-smdk5420.dts and exynos5800-peach-pi.dts Changes over Thomas' original v12 code: - split Exynos5420 and Exynos5800 support - moved E5420_[EGL,KFC]_DIV0() macros to clk-exynos5420.c - disabled cpufreq if big.LITTLE switcher support is enabled - enhanced arm_big_little[_dt] driver with CPU cluster regulator support - fixed CPU clock configuration data for Exynos5800 - fixed CPU operating points setup for Exynos5800 - added CPU cluster regulator supplies for ODROID-XU3 board Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (5): ARM: dts: Exynos542x/5800: add cluster regulator supply properties ARM: Exynos: use generic cpufreq driver for Exynos5420 clk: samsung: exynos5422/5800: fix cpu clock configuration data ARM: dts: Exynos5800: fix CPU OPP ARM: Exynos: use generic cpufreq driver for Exynos5422/5800 Thomas Abraham (2): clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock ARM: dts: Exynos542x/5800: add CPU OPP properties arch/arm/boot/dts/exynos5420-arndale-octa.dts | 8 ++ arch/arm/boot/dts/exynos5420-peach-pit.dts | 8 ++ arch/arm/boot/dts/exynos5420-smdk5420.dts | 8 ++ arch/arm/boot/dts/exynos5420.dtsi | 122 + arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++ arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8 ++ arch/arm/boot/dts/exynos5800-peach-pi.dts | 8 ++ arch/arm/boot/dts/exynos5800.dtsi | 108 ++ arch/arm/mach-exynos/exynos.c | 4 + drivers/clk/samsung/clk-exynos5420.c | 88 ++- include/dt-bindings/clock/exynos5420.h | 2 + 11 files changed, 372 insertions(+), 2 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 v5 1/7] ARM: dts: Exynos542x/5800: add cluster regulator supply properties
Add cluster regulator supply properties as a preparation to
adding generic cpufreq-dt driver support for Exynos542x and
Exynos5800 based boards.
Cc: Kukjin Kim
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Cc: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 8
arch/arm/boot/dts/exynos5420-peach-pit.dts | 8
arch/arm/boot/dts/exynos5420-smdk5420.dts | 8
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 8
arch/arm/boot/dts/exynos5800-peach-pi.dts | 8
5 files changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 4ecef69..4229641 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -52,6 +52,14 @@
};
};
+&cpu0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-supply = <&buck6_reg>;
+};
+
&usbdrd_dwc3_1 {
dr_mode = "host";
};
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..df071b33 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -143,6 +143,14 @@
vdd-supply = <&ldo9_reg>;
};
+&cpu0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-supply = <&buck6_reg>;
+};
+
&dp {
status = "okay";
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..124a9ba 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -89,6 +89,14 @@
};
+&cpu0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-supply = <&buck6_reg>;
+};
+
&dp {
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 9134217..1bd507b 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -67,6 +67,14 @@
<1920>;
};
+&cpu0 {
+ cpu-supply = <&buck6_reg>;
+};
+
+&cpu4 {
+ cpu-supply = <&buck2_reg>;
+};
+
&hdmi {
status = "okay";
hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e4..2f6d8ac 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -137,6 +137,14 @@
vdd-supply = <&ldo9_reg>;
};
+&cpu0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&cpu4 {
+ cpu-supply = <&buck6_reg>;
+};
+
&dp {
status = "okay";
pinctrl-names = "default";
--
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 v5 3/7] ARM: dts: Exynos542x/5800: add CPU OPP properties
From: Thomas Abraham
For Exynos542x/5800 platforms, add CPU operating points
for migrating from Exynos specific cpufreq driver to using
generic cpufreq driver.
Changes by Bartlomiej:
- split Exynos5420 support from the original patch
- merged Exynos5422 fixes from Ben
Changes by Ben Gamari:
- Port to operating-points-v2
Cc: Kukjin Kim
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Signed-off-by: Thomas Abraham
Signed-off-by: Ben Gamari
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/boot/dts/exynos5420.dtsi | 122 +
arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 +++
2 files changed, 132 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 48a0a55..616c2d0 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -50,6 +50,116 @@
usbdrdphy1 = &usbdrd_phy1;
};
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+ opp@18 {
+ opp-hz = /bits/ 64 <18>;
+ opp-microvolt = <125>;
+ clock-latency-ns = <14>;
+ };
+ opp@17 {
+ opp-hz = /bits/ 64 <17>;
+ opp-microvolt = <1212500>;
+ clock-latency-ns = <14>;
+ };
+ opp@16 {
+ opp-hz = /bits/ 64 <16>;
+ opp-microvolt = <1175000>;
+ clock-latency-ns = <14>;
+ };
+ opp@15 {
+ opp-hz = /bits/ 64 <15>;
+ opp-microvolt = <1137500>;
+ clock-latency-ns = <14>;
+ };
+ opp@14 {
+ opp-hz = /bits/ 64 <14>;
+ opp-microvolt = <1112500>;
+ clock-latency-ns = <14>;
+ };
+ opp@13 {
+ opp-hz = /bits/ 64 <13>;
+ opp-microvolt = <1062500>;
+ clock-latency-ns = <14>;
+ };
+ opp@12 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt = <1037500>;
+ clock-latency-ns = <14>;
+ };
+ opp@11 {
+ opp-hz = /bits/ 64 <11>;
+ opp-microvolt = <1012500>;
+ clock-latency-ns = <14>;
+ };
+ opp@10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = < 987500>;
+ clock-latency-ns = <14>;
+ };
+ opp@9 {
+ opp-hz = /bits/ 64 <9>;
+ opp-microvolt = < 962500>;
+ clock-latency-ns = <14>;
+ };
+ opp@8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = < 937500>;
+ clock-latency-ns = <14>;
+ };
+ opp@7 {
+ opp-hz = /bits/ 64 <7>;
+ opp-microvolt = < 912500>;
+ clock-latency-ns = <14>;
+ };
+ };
+
+ cpu1_opp_table: opp_table1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+ opp@13 {
+ opp-hz = /bits/ 64 <13>;
+ opp-microvolt = <1275000>;
+ clock-latency-ns = <14>;
+ };
+ opp@12 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt = <1212500>;
+ clock-latency-ns = <14>;
+ };
+ opp@11 {
+ opp-hz = /bits/ 64 <11>;
+ opp-microvolt = <1162500>;
+ clock-latency-ns = <14>;
+ };
+ opp@10 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt = <1112500>;
+ clock-latency-ns = <14>;
+ };
+ opp@9 {
+ opp-hz = /bits/ 64 <9>;
+ opp-microvolt = <1062500>;
+ clock-latency-ns = <14>;
+ };
+ opp@8 {
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <1025000>;
+ clock-latency-ns = <14
[PATCH v5 2/7] clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock
From: Thomas Abraham
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos5420.
Changes by Bartlomiej:
- split Exynos5420 support from the original patches
- moved E5420_[EGL,KFC]_DIV0() macros to clk-exynos5420.c
Cc: Tomasz Figa
Cc: Mike Turquette
Cc: Javier Martinez Canillas
Acked-by: Sylwester Nawrocki
Signed-off-by: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/clk/samsung/clk-exynos5420.c | 58 --
include/dt-bindings/clock/exynos5420.h | 2 ++
2 files changed, 58 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 389af3c..2a92546 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -18,6 +18,7 @@
#include
#include "clk.h"
+#include "clk-cpu.h"
#define APLL_LOCK 0x0
#define APLL_CON0 0x100
@@ -616,9 +617,11 @@ static struct samsung_mux_clock exynos5x_mux_clks[]
__initdata = {
MUX(0, "mout_mspll_kfc", mout_mspll_cpu_p, SRC_TOP7, 8, 2),
MUX(0, "mout_mspll_cpu", mout_mspll_cpu_p, SRC_TOP7, 12, 2),
- MUX(0, "mout_apll", mout_apll_p, SRC_CPU, 0, 1),
+ MUX_F(0, "mout_apll", mout_apll_p, SRC_CPU, 0, 1,
+ CLK_SET_RATE_PARENT | CLK_RECALC_NEW_RATES, 0),
MUX(0, "mout_cpu", mout_cpu_p, SRC_CPU, 16, 1),
- MUX(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1),
+ MUX_F(0, "mout_kpll", mout_kpll_p, SRC_KFC, 0, 1,
+ CLK_SET_RATE_PARENT | CLK_RECALC_NEW_RATES, 0),
MUX(0, "mout_kfc", mout_kfc_p, SRC_KFC, 16, 1),
MUX(0, "mout_aclk200", mout_group1_p, SRC_TOP0, 8, 2),
@@ -1246,6 +1249,50 @@ static struct samsung_pll_clock exynos5x_plls[nr_plls]
__initdata = {
KPLL_CON0, NULL),
};
+#define E5420_EGL_DIV0(apll, pclk_dbg, atb, cpud) \
+ apll) << 24) | ((pclk_dbg) << 20) | ((atb) << 16) | \
+((cpud) << 4)))
+
+static const struct exynos_cpuclk_cfg_data exynos5420_eglclk_d[] __initconst =
{
+ { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 100, E5420_EGL_DIV0(3, 6, 6, 2), },
+ { 90, E5420_EGL_DIV0(3, 6, 6, 2), },
+ { 80, E5420_EGL_DIV0(3, 5, 5, 2), },
+ { 70, E5420_EGL_DIV0(3, 5, 5, 2), },
+ { 60, E5420_EGL_DIV0(3, 4, 4, 2), },
+ { 50, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 40, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 30, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 20, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 0 },
+};
+
+#define E5420_KFC_DIV(kpll, pclk, aclk)
\
+ kpll) << 24) | ((pclk) << 20) | ((aclk) << 4)))
+
+static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[] __initconst =
{
+ { 130, E5420_KFC_DIV(3, 5, 2), },
+ { 120, E5420_KFC_DIV(3, 5, 2), },
+ { 110, E5420_KFC_DIV(3, 5, 2), },
+ { 100, E5420_KFC_DIV(3, 5, 2), },
+ { 90, E5420_KFC_DIV(3, 5, 2), },
+ { 80, E5420_KFC_DIV(3, 5, 2), },
+ { 70, E5420_KFC_DIV(3, 4, 2), },
+ { 60, E5420_KFC_DIV(3, 4, 2), },
+ { 50, E5420_KFC_DIV(3, 4, 2), },
+ { 40, E5420_KFC_DIV(3, 3, 2), },
+ { 30, E5420_KFC_DIV(3, 3, 2), },
+ { 20, E5420_KFC_DIV(3, 3, 2), },
+ { 0 },
+};
+
static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = "samsung,exynos5420-oscclk", .data = (void *)0, },
{ },
@@ -1310,6 +1357,13 @@ static void __init exynos5x_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos5800_gate_clks));
}
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5420_eglclk_d, ARRAY_SIZE(exynos5420_eglclk_d), 0);
+ exynos_register_cpu_clock(ctx, CLK_KFC_CLK, "kfcclk",
+ mout_kfc_p[0], mout_kfc_p[1], 0x28200,
+ exynos5420_kfcclk_d, ARRAY_SIZE(exynos5420_kfcclk_d), 0);
+
exynos5420_clk_sleep_init();
samsung_clk_of_add_provider(np, ctx);
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h
index 99da0d1..dde9664 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -25,6 +25,8 @@
#define CLK_FOUT_MPLL 10
#define CLK_FOUT_BPLL 11
[PATCH v5 6/7] ARM: dts: Exynos5800: fix CPU OPP
Fix CPU operating points for Exynos5800 (it use different
voltages than Exynos5420 and supports additional frequencies).
However don't use 2000MHz & 1900MHz OPPs (for A15 cores) and
1400MHz OPP (for A7 cores) for now as they are not available
on all boards.
Based on Hardkernel's kernel for ODROID-XU3 board.
Changes by Ben Gamari:
- Port to operating-points-v2
Cc: Kukjin Kim
Cc: Doug Anderson
Cc: Javier Martinez Canillas
Cc: Andreas Faerber
Cc: Thomas Abraham
Signed-off-by: Ben Gamari
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/boot/dts/exynos5800.dtsi | 108 ++
1 file changed, 108 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5800.dtsi
b/arch/arm/boot/dts/exynos5800.dtsi
index c0bb356..b3c16f6 100644
--- a/arch/arm/boot/dts/exynos5800.dtsi
+++ b/arch/arm/boot/dts/exynos5800.dtsi
@@ -23,6 +23,114 @@
compatible = "samsung,exynos5800-clock";
};
+&cpu0_opp_table {
+ opp@17 {
+ opp-microvolt = <125>;
+ };
+ opp@16 {
+ opp-microvolt = <125>;
+ };
+ opp@15 {
+ opp-microvolt = <110>;
+ };
+ opp@14 {
+ opp-microvolt = <110>;
+ };
+ opp@13 {
+ opp-microvolt = <110>;
+ };
+ opp@12 {
+ opp-microvolt = <100>;
+ };
+ opp@11 {
+ opp-microvolt = <100>;
+ };
+ opp@10 {
+ opp-microvolt = <100>;
+ };
+ opp@9 {
+ opp-microvolt = <100>;
+ };
+ opp@8 {
+ opp-microvolt = <90>;
+ };
+ opp@7 {
+ opp-microvolt = <90>;
+ };
+ opp@6 {
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp@5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp@4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp@3 {
+ opp-hz = /bits/ 64 <3>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+};
+
+&cpu1_opp_table {
+ opp@13 {
+ opp-microvolt = <125>;
+ };
+ opp@12 {
+ opp-microvolt = <125>;
+ };
+ opp@11 {
+ opp-microvolt = <125>;
+ };
+ opp@10 {
+ opp-microvolt = <110>;
+ };
+ opp@9 {
+ opp-microvolt = <110>;
+ };
+ opp@8 {
+ opp-microvolt = <110>;
+ };
+ opp@7 {
+ opp-microvolt = <100>;
+ };
+ opp@6 {
+ opp-microvolt = <100>;
+ };
+ opp@5 {
+ opp-hz = /bits/ 64 <5>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <14>;
+ };
+ opp@4 {
+ opp-hz = /bits/ 64 <4>;
+ opp-microvolt = <100>;
+ clock-latency-ns = <14>;
+ };
+ opp@3 {
+ opp-hz = /bits/ 64 <3>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+ opp@2 {
+ opp-hz = /bits/ 64 <2>;
+ opp-microvolt = <90>;
+ clock-latency-ns = <14>;
+ };
+};
+
&mfc {
compatible = "samsung,mfc-v8";
};
--
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 v5 5/7] clk: samsung: exynos5422/5800: fix cpu clock configuration data
Fix cpu clock configuration data for Exynos5422/5800 SoCs
(they use higher PCLK_DBG divider values than Exynos5420 and
support additional frequencies).
Based on Hardkernel's kernel for ODROID-XU3 board.
Cc: Tomasz Figa
Cc: Mike Turquette
Cc: Javier Martinez Canillas
Cc: Thomas Abraham
Acked-by: Sylwester Nawrocki
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/clk/samsung/clk-exynos5420.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 2a92546..837329d 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1274,10 +1274,34 @@ static const struct exynos_cpuclk_cfg_data
exynos5420_eglclk_d[] __initconst = {
{ 0 },
};
+static const struct exynos_cpuclk_cfg_data exynos5800_eglclk_d[] __initconst =
{
+ { 200, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 190, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 100, E5420_EGL_DIV0(3, 7, 6, 2), },
+ { 90, E5420_EGL_DIV0(3, 7, 6, 2), },
+ { 80, E5420_EGL_DIV0(3, 7, 5, 2), },
+ { 70, E5420_EGL_DIV0(3, 7, 5, 2), },
+ { 60, E5420_EGL_DIV0(3, 7, 4, 2), },
+ { 50, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 40, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 30, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 20, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 0 },
+};
+
#define E5420_KFC_DIV(kpll, pclk, aclk)
\
kpll) << 24) | ((pclk) << 20) | ((aclk) << 4)))
static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[] __initconst =
{
+ { 140, E5420_KFC_DIV(3, 5, 3), }, /* for Exynos5800 */
{ 130, E5420_KFC_DIV(3, 5, 2), },
{ 120, E5420_KFC_DIV(3, 5, 2), },
{ 110, E5420_KFC_DIV(3, 5, 2), },
@@ -1357,9 +1381,15 @@ static void __init exynos5x_clk_init(struct device_node
*np,
ARRAY_SIZE(exynos5800_gate_clks));
}
- exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
- mout_cpu_p[0], mout_cpu_p[1], 0x200,
- exynos5420_eglclk_d, ARRAY_SIZE(exynos5420_eglclk_d), 0);
+ if (soc == EXYNOS5420) {
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5420_eglclk_d, ARRAY_SIZE(exynos5420_eglclk_d),
0);
+ } else {
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, "armclk",
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5800_eglclk_d, ARRAY_SIZE(exynos5800_eglclk_d),
0);
+ }
exynos_register_cpu_clock(ctx, CLK_KFC_CLK, "kfcclk",
mout_kfc_p[0], mout_kfc_p[1], 0x28200,
exynos5420_kfcclk_d, ARRAY_SIZE(exynos5420_kfcclk_d), 0);
--
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 v5 7/7] ARM: Exynos: use generic cpufreq driver for Exynos5422/5800
The new CPU clock type allows the use of generic cpufreq-dt driver
for Exynos5422/5800.
Cc: Tomasz Figa
Cc: Kukjin Kim
Cc: Javier Martinez Canillas
Cc: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 7a89c9d..cec8aeb 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -232,6 +232,7 @@ static const struct of_device_id exynos_cpufreq_matches[] =
{
{ .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
#ifndef CONFIG_BL_SWITCHER
{ .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
+ { .compatible = "samsung,exynos5800", .data = "cpufreq-dt" },
#endif
{ /* sentinel */ }
};
--
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 v5 4/7] ARM: Exynos: use generic cpufreq driver for Exynos5420
The new CPU clock type allows the use of cpufreq-dt driver
for Exynos5420.
Cc: Tomasz Figa
Cc: Kukjin Kim
Cc: Javier Martinez Canillas
Cc: Thomas Abraham
Signed-off-by: Bartlomiej Zolnierkiewicz
---
arch/arm/mach-exynos/exynos.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 1c47aee..7a89c9d 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -230,6 +230,9 @@ static const struct of_device_id exynos_cpufreq_matches[] =
{
{ .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
{ .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
{ .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
+#ifndef CONFIG_BL_SWITCHER
+ { .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
+#endif
{ /* sentinel */ }
};
--
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 v4 7/8] ARM: dts: Exynos5422: fix OPP tables
Hi, On Tuesday, December 08, 2015 05:13:26 PM Krzysztof Kozlowski wrote: > On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote: > > From: Ben Gamari > > > > The Exynos 5422 is identical to the 5800 except for the fact that it > > boots from the A7 cores. Consequently, the core numbering is different: > > cores 0-3 are A7s whereas 4-7 are A15s. > > > > We can reuse the device tree of the 5800 for the 5422 but we must take > > care to override the OPP tables and CPU clocks. These are otherwise > > inherited from the exynos5800 devicetree, which has the CPU clusters > > reversed compared to the 5422. This results in the A15 cores only > > reaching 1.4GHz, the maximum rate of the KFC clock. > > > > Cc: Javier Martinez Canillas > > Signed-off-by: Ben Gamari > > Signed-off-by: Bartlomiej Zolnierkiewicz > > --- > > arch/arm/boot/dts/exynos5422-cpus.dtsi | 10 ++ > > 1 file changed, 10 insertions(+) > > > > This looks like a very-non-atomic way of handling a change. You added > opp tables to exynos5420 before so at that time they will be applied to > Odroid XU3 family which uses different CPU order. After that you are > fixing the tables to proper CPU order. Direct bisectability probably > won't be an issue because all of DTS would go to separate branch... but > the logic behind confuses. It was done this way to preserve original authorship of changes and bisectability should not be affected unless patch #8 is merged before patch #7. > I think this should be squashed into 3/8. OK. > Best regards, > Krzysztof Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics -- 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 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size
Hi Inki, On 10 December 2015 at 12:59, Marek Szyprowski wrote: > On 2015-12-10 12:35, Inki Dae wrote: >> 2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글: >>> This patch fixes trashed display of buffers cropped to very small width. >>> Even if DMA is unstable and causes tearing when changing the burst size, >>> it is still better than displaying a garbage. >> >> It seems that this patch is different from above description. I think >> below patch is just cleanup, >> which passes each member necessary instead of passing a drm_framebuffer >> object. > > > Please note the last chunk of this patch. After applying it width is > taken from state->src.w instead of fb->width. If you want, I can split > this patch into 2 parts - one cleanup without functional change, and > second, replacement of fb->width with state->src.w. As Marek says: http://lists.freedesktop.org/archives/dri-devel/2015-November/094321.html It fixes the case where state->src.w (what we're actually scanning out) < MIN_FB_WIDTH_FOR_16WORD_BURST < fb->width (total size of allocated buffer). Quite subtle, but also correct. Cheers, Daniel -- 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 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On Thu, Dec 10, 2015 at 11:21 PM, Rob Herring wrote:
> On Wed, Dec 09, 2015 at 01:08:01PM +0900, Chanwoo Choi wrote:
>> This patch updates the documentation for passive bus devices and adds the
>> detailed example of Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi
>> ---
>> .../devicetree/bindings/devfreq/exynos-bus.txt | 244
>> -
>> 1 file changed, 241 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> index 54a1f9c46c88..c4fdc70f8eac 100644
>> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
>> @@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference
>> should be specified
>> in devicetree file instead of each device driver. In result, this driver
>> is able to support the bus frequency for all Exynos SoCs.
>>
>> -Required properties for bus device:
>> +Required properties for all bus devices:
>> - compatible: Should be "samsung,exynos-bus".
>> - clock-names : the name of clock used by the bus, "bus".
>> - clocks : phandles for clock specified in "clock-names" property.
>> - #clock-cells: should be 1.
>> - operating-points-v2: the OPP table including frequency/voltage information
>>to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
>> +
>> +Required properties for only parent bus device:
>> - vdd-supply: the regulator to provide the buses with the voltage.
>> - devfreq-events: the devfreq-event device to monitor the curret utilization
>>of buses.
>>
>> -Optional properties for bus device:
>> +Required properties for only passive bus device:
>> +- devfreq: the parent bus device.
>> +
>> +Optional properties for only parent bus device:
>> - exynos,saturation-ratio: the percentage value which is used to calibrate
>> the performance count againt total cycle count.
>>
>> @@ -33,7 +38,20 @@ Example1:
>> power line (regulator). The MIF (Memory Interface) AXI bus is used to
>> transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>>
>> - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
>> + - MIF (Memory Interface) block
>> + : VDD_MIF |--- DMC (Dynamic Memory Controller)
>> +
>> + - INT (Internal) block
>> + : VDD_INT |--- LEFTBUS (parent device)
>> + |--- PERIL
>> + |--- MFC
>> + |--- G3D
>> + |--- RIGHTBUS
>> + |--- FSYS
>> + |--- LCD0
>> + |--- PERIR
>> + |--- ISP
>> + |--- CAM
>
> This still has the same problem as before. I would expect that the bus
> hierarchy in the dts match the hierarchy here. You just have flat nodes
> in the example below. So all IP blocks affected by frequency scaling
> should be under the bus node defining the OPPs. Something like this:
The each bus of sub-block has not h/w dependency among sub-blocks
and has the owned source clock / OPP table. Just they share the same
power line. So, I think that flat nodes in the example below is not problem.
Because of using the same power line, the sub-blocks would be tied
by devfreq framework only for the behavior of bus frequency scaling .
>
> soc {
> compatible = "simple-bus";
> bus {
> compatible = "my-awesome-dvfs-bus"; /* simple-bus too if
> no setup needed first */
> reg = <0x0 0x0>; // Bus control registers
> clocks = <&ccm BUS_CLK>;
> operating-points-v2 = <&opp>;
> device@0 {
> compatible = "my-awesome-device-1";
> };
> device@1 {
> compatible = "my-awesome-device-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
Re: [PATCH v2 09/19] PM / devfreq: exynos: Update documentation for bus devices using passive governor
On Wed, Dec 09, 2015 at 01:08:01PM +0900, Chanwoo Choi wrote:
> This patch updates the documentation for passive bus devices and adds the
> detailed example of Exynos3250.
>
> Signed-off-by: Chanwoo Choi
> ---
> .../devicetree/bindings/devfreq/exynos-bus.txt | 244
> -
> 1 file changed, 241 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> index 54a1f9c46c88..c4fdc70f8eac 100644
> --- a/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> +++ b/Documentation/devicetree/bindings/devfreq/exynos-bus.txt
> @@ -13,18 +13,23 @@ SoC has the different sub-blocks. So, this difference
> should be specified
> in devicetree file instead of each device driver. In result, this driver
> is able to support the bus frequency for all Exynos SoCs.
>
> -Required properties for bus device:
> +Required properties for all bus devices:
> - compatible: Should be "samsung,exynos-bus".
> - clock-names : the name of clock used by the bus, "bus".
> - clocks : phandles for clock specified in "clock-names" property.
> - #clock-cells: should be 1.
> - operating-points-v2: the OPP table including frequency/voltage information
>to support DVFS (Dynamic Voltage/Frequency Scaling) feature.
> +
> +Required properties for only parent bus device:
> - vdd-supply: the regulator to provide the buses with the voltage.
> - devfreq-events: the devfreq-event device to monitor the curret utilization
>of buses.
>
> -Optional properties for bus device:
> +Required properties for only passive bus device:
> +- devfreq: the parent bus device.
> +
> +Optional properties for only parent bus device:
> - exynos,saturation-ratio: the percentage value which is used to calibrate
> the performance count againt total cycle count.
>
> @@ -33,7 +38,20 @@ Example1:
> power line (regulator). The MIF (Memory Interface) AXI bus is used to
> transfer data between DRAM and CPU and uses the VDD_MIF regualtor.
>
> - - power line(VDD_MIF) --> bus for DMC (Dynamic Memory Controller) block
> + - MIF (Memory Interface) block
> + : VDD_MIF |--- DMC (Dynamic Memory Controller)
> +
> + - INT (Internal) block
> + : VDD_INT |--- LEFTBUS (parent device)
> + |--- PERIL
> + |--- MFC
> + |--- G3D
> + |--- RIGHTBUS
> + |--- FSYS
> + |--- LCD0
> + |--- PERIR
> + |--- ISP
> + |--- CAM
This still has the same problem as before. I would expect that the bus
hierarchy in the dts match the hierarchy here. You just have flat nodes
in the example below. So all IP blocks affected by frequency scaling
should be under the bus node defining the OPPs. Something like this:
soc {
compatible = "simple-bus";
bus {
compatible = "my-awesome-dvfs-bus"; /* simple-bus too if
no setup needed first */
reg = <0x0 0x0>; // Bus control registers
clocks = <&ccm BUS_CLK>;
operating-points-v2 = <&opp>;
device@0 {
compatible = "my-awesome-device-1";
};
device@1 {
compatible = "my-awesome-device-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
Re: [PATCH v4 4/8] ARM: Exynos: use generic cpufreq driver for Exynos5420
Hi,
On Tuesday, December 08, 2015 04:36:12 PM Krzysztof Kozlowski wrote:
> On 08.12.2015 03:18, Bartlomiej Zolnierkiewicz wrote:
> > From: Thomas Abraham
> >
> > The new CPU clock type allows the use of cpufreq-dt driver
> > for Exynos5420.
> >
> > Changes by Bartlomiej:
> > - split Exynos5420 support from the original patch
> > - disable cpufreq if big.LITTLE switcher support is enabled
> > - switch to using cpufreq-dt driver
> >
> > Cc: Tomasz Figa
> > Cc: Kukjin Kim
> > Cc: Javier Martinez Canillas
> > Signed-off-by: Thomas Abraham
> > Signed-off-by: Bartlomiej Zolnierkiewicz
> > ---
> > arch/arm/mach-exynos/exynos.c | 3 +++
> > 1 file changed, 3 insertions(+)
>
> I think this is actually now your patch, not Thomas any more. :)
It seems so, I'll update the patch.
> > diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
> > index 1c47aee..7a89c9d 100644
> > --- a/arch/arm/mach-exynos/exynos.c
> > +++ b/arch/arm/mach-exynos/exynos.c
> > @@ -230,6 +230,9 @@ static const struct of_device_id
> > exynos_cpufreq_matches[] = {
> > { .compatible = "samsung,exynos4212", .data = "cpufreq-dt" },
> > { .compatible = "samsung,exynos4412", .data = "cpufreq-dt" },
> > { .compatible = "samsung,exynos5250", .data = "cpufreq-dt" },
> > +#ifndef CONFIG_BL_SWITCHER
> > + { .compatible = "samsung,exynos5420", .data = "cpufreq-dt" },
> > +#endif
>
> Why not on BL_SWITCHER? Shouldn't be enough to disable ARM_DT_BL_CPUFREQ?
ARM_DT_BL_CPUFREQ is not relevant here (it requires to be explicitly
enabled by platform code, just like cpufreq-dt) and the dependency on
!BL_SWITCHER is needed because when BL_SWITCHER is enabled big and
LITTLE cores are grouped in pairs and presented as "virtual" CPUs to
the system:
...
[0.002630] CPU0: update cpu_capacity 448
[0.002646] CPU0: thread -1, cpu 0, socket 1, mpidr 8100
[0.002835] Setting up static identity map for 0x40008280 - 0x400082d8
[0.003106] ARM CCI driver probed
[0.003351] Exynos MCPM support installed
[0.045350] CPU1: update cpu_capacity 448
[0.045358] CPU1: thread -1, cpu 1, socket 1, mpidr 8101
[0.060326] CPU2: update cpu_capacity 448
[0.060334] CPU2: thread -1, cpu 2, socket 1, mpidr 8102
[0.075326] CPU3: update cpu_capacity 448
[0.075334] CPU3: thread -1, cpu 3, socket 1, mpidr 8103
[0.090337] CPU4: update cpu_capacity 1535
[0.090345] CPU4: thread -1, cpu 0, socket 0, mpidr 8000
[0.105314] CPU5: update cpu_capacity 1535
[0.105321] CPU5: thread -1, cpu 1, socket 0, mpidr 8001
[0.120338] CPU6: update cpu_capacity 1535
[0.120345] CPU6: thread -1, cpu 2, socket 0, mpidr 8002
[0.135330] CPU7: update cpu_capacity 1535
[0.135338] CPU7: thread -1, cpu 3, socket 0, mpidr 8003
[0.135466] Brought up 8 CPUs
...
[3.027498] big.LITTLE switcher initializing
[3.031761] CPU0 paired with CPU7
[3.035055] CPU1 paired with CPU6
[3.038332] CPU2 paired with CPU5
[3.041598] CPU3 paired with CPU4
[3.044930] GIC ID for CPU 0 cluster 1 is 4
[3.049078] GIC ID for CPU 1 cluster 1 is 5
[3.053258] GIC ID for CPU 2 cluster 1 is 6
[3.057370] GIC ID for CPU 3 cluster 1 is 7
[3.061558] GIC ID for CPU 0 cluster 0 is 0
[3.083336] IRQ53 no longer affine to CPU4
[3.084336] CPU4: shutdown
[3.107059] GIC ID for CPU 1 cluster 0 is 1
[3.123303] IRQ54 no longer affine to CPU5
[3.124213] CPU5: shutdown
[3.146387] GIC ID for CPU 2 cluster 0 is 2
[3.158143] cpu cpu0: 1100 MHz, 1250 mV --> 900 MHz, 1100 mV
[3.168228] IRQ55 no longer affine to CPU6
[3.169135] CPU6: shutdown
[3.191485] GIC ID for CPU 3 cluster 0 is 3
[3.208264] IRQ56 no longer affine to CPU7
[3.209166] CPU7: shutdown
[3.236752] big.LITTLE switcher initialized
...
Only arm_big_little_dt driver knows how to handle this setup
correctly. cpufreq-dt just treats "virtual" CPUs as a LITTLE
ones. Thus when "virtual CPU"'s current core is switched to
a big one cpufreq-dt is unable to update its voltage.
[ I tried using BL_SWITCHER_DUMMY_IF functionality to simulate
this with:
echo 0,0 > /dev/b.L_switcher
but it doesn't seem to work for some reason (from looking at
arch/arm/common/bL_switcher_dummy_if.c code it seems that at
least "bL_switcher_write" line should get logged but it does
not happen). ]
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
--
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 06/22] drm/exynos: move dma_addr attribute from exynos plane to exynos fb
2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
> DMA address is a framebuffer attribute and the right place for it is
> exynos_drm_framebuffer not exynos_drm_plane. This patch also introduces
> helper function for getting dma address of the given framebuffer.
>
> Signed-off-by: Marek Szyprowski
> Reviewed-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 13 -
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 16 +---
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 ---
> drivers/gpu/drm/exynos/exynos_drm_fb.c| 16 ++--
> drivers/gpu/drm/exynos/exynos_drm_fb.h| 3 +--
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 ++
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 18 --
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 5 -
> drivers/gpu/drm/exynos/exynos_mixer.c | 7 ---
> 9 files changed, 38 insertions(+), 53 deletions(-)
>
<--snip-->
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 669362c53f49..3ce141236fad 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -24,6 +24,7 @@
>
> #include "exynos_drm_drv.h"
> #include "exynos_drm_crtc.h"
> +#include "exynos_drm_fb.h"
> #include "exynos_drm_plane.h"
> #include "exynos_drm_vidi.h"
>
> @@ -126,11 +127,13 @@ static void vidi_update_plane(struct exynos_drm_crtc
> *crtc,
> struct exynos_drm_plane *plane)
> {
> struct vidi_context *ctx = crtc->ctx;
> + dma_addr_t addr;
>
> if (ctx->suspended)
> return;
>
> - DRM_DEBUG_KMS("dma_addr = %pad\n", plane->dma_addr);
> + addr = exynos_drm_fb_dma_addr(plane->base.fb, 0);
At this point, plane->base.fb is NULL so null pointer access happens like below,
[5.969422] Unable to handle kernel NULL pointer dereference at virtual
address 0090
[5.977481] pgd = ee59
[5.980142] [0090] *pgd=6e526831, *pte=, *ppte=
[5.986347] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[5.991712] Modules linked in:
[5.994770] CPU: 3 PID: 1598 Comm: sh Not tainted
4.4.0-rc3-00052-gc60d7e2-dirty #199
[6.002565] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[6.008647] task: ef328000 ti: ee4d4000 task.ti: ee4d4000
[6.014053] PC is at exynos_drm_fb_dma_addr+0x8/0x14
[6.018990] LR is at vidi_update_plane+0x4c/0xc4
[6.023581] pc : []lr : []psr: 8013
[6.023581] sp : ee4d5d90 ip : 0001 fp :
[6.035029] r10: r9 : c05b965c r8 : ee813e00
[6.040241] r7 : r6 : ee8e3330 r5 : r4 : ee8e3010
[6.046749] r3 : r2 : r1 : 0024 r0 :
[6.053264] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[6.060379] Control: 10c5387d Table: 6e59004a DAC: 0051
[6.066107] Process sh (pid: 1598, stack limit = 0xee4d4210)
[6.071748] Stack: (0xee4d5d90 to 0xee4d6000)
[6.076100] 5d80: ee813300
ee476e40 0005
[6.084236] 5da0: ee8e3330 c028ac14 0008 ee476e40 ee476fc0 ef3b3800
ee476fc0 eeb3e380
[6.092395] 5dc0: 0002 c02b08e4 eeb3e3a4 ee476fc0 ee476e40
ef3b3800 eeb3e380
[6.100554] 5de0: 0002 c02b12b8 ee854400 0001 ee8501a8
ee476e40
[6.108714] 5e00: ef3b3800 0001 ee476e40 0050 ee850c80 0001
ee476e40 ef3b3aac
[6.116873] 5e20: 0002 00ff c028e0ec 000a82b4 c02acc50
ee8e36a0 ee476c80
[6.125032] 5e40: ef3b3aac ef3b3800 ee476c9c ee850c80 ef3b3800 ef3b3800
ef3b3800 ef3b398c
[6.133191] 5e60: c088c390 0002 000a82b4 c028f8d4 ef3b3800
ef0f4300 c028f948
[6.141350] 5e80: ee850c80 c028f864 ef3b3a84 0001 ef3b3a90 c02853e4
0001
[6.149509] 5ea0: 000a82b4 ee4d5ec0 0002 ee8e3010 0002 0002
ee4d5f88
[6.157669] 5ec0: eeb8df00 000a82b4 c02c4278 0002 ee476b00
eeb8df0c c01390ac
[6.165828] 5ee0: ee4e1f00 0002 000a9540 ee4d5f88
c000f844 ee4d4000
[6.173987] 5f00: c00dbf70 000a82b4 c00093dc ee4d4000 ee4d5f78
ef328234 c0579bec
[6.182146] 5f20: 0001 0001 ee4d5f3c 0001 ee45e9c4 0001
000a82b4 c005ca74
[6.190306] 5f40: ee45e9c4 0002 000a9540 c005cad4 ee4e1f00 0002
000a9540 ee4d5f88
[6.198465] 5f60: c000f844 c00dc770 ee4e1f00 ee4e1f00
0002 000a9540
[6.206624] 5f80: c000f844 c00dcf98 0003 000a7c40
0001 000a9540
[6.214783] 5fa0: 0004 c000f680 000a7c40 0001 0001 000a9540
0002
[6.222942] 5fc0: 000a7c40 0001 000a9540 0004 0020 000a82c8
000a8294 000a82b4
[6.231102] 5fe0: be8b1624 00012345 b6e94166 4030 0001
[6.239270] [
Re: [PATCH v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size
Hello,
On 2015-12-10 12:35, Inki Dae wrote:
Hi Marek,
2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
This patch fixes trashed display of buffers cropped to very small width.
Even if DMA is unstable and causes tearing when changing the burst size,
it is still better than displaying a garbage.
It seems that this patch is different from above description. I think below
patch is just cleanup,
which passes each member necessary instead of passing a drm_framebuffer object.
Please note the last chunk of this patch. After applying it width is
taken from state->src.w instead of fb->width. If you want, I can split
this patch into 2 parts - one cleanup without functional change, and
second, replacement of fb->width with state->src.w.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 70cd2681e343..2e2247126581 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -487,7 +487,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
- struct drm_framebuffer *fb)
+ uint32_t pixel_format, int width)
{
unsigned long val;
@@ -498,11 +498,11 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
* So the request format is ARGB then change it to XRGB.
*/
if (ctx->driver_data->has_limited_fmt && !win) {
- if (fb->pixel_format == DRM_FORMAT_ARGB)
- fb->pixel_format = DRM_FORMAT_XRGB;
+ if (pixel_format == DRM_FORMAT_ARGB)
+ pixel_format = DRM_FORMAT_XRGB;
}
- switch (fb->pixel_format) {
+ switch (pixel_format) {
case DRM_FORMAT_C8:
val |= WINCON0_BPPMODE_8BPP_PALETTE;
val |= WINCONx_BURSTLEN_8WORD;
@@ -538,17 +538,15 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx,
unsigned int win,
break;
}
- DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
-
/*
-* In case of exynos, setting dma-burst to 16Word causes permanent
-* tearing for very small buffers, e.g. cursor buffer. Burst Mode
-* switching which is based on plane size is not recommended as
-* plane size varies alot towards the end of the screen and rapid
-* movement causes unstable DMA which results into iommu crash/tear.
+* Setting dma-burst to 16Word causes permanent tearing for very small
+* buffers, e.g. cursor buffer. Burst Mode switching which based on
+* plane size is not recommended as plane size varies alot towards the
+* end of the screen and rapid movement causes unstable DMA, but it is
+* still better to change dma-burst than displaying garbage.
*/
- if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
val &= ~WINCONx_BURSTLEN_MASK;
val |= WINCONx_BURSTLEN_4WORD;
}
@@ -723,7 +721,7 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
}
- fimd_win_set_pixfmt(ctx, win, fb);
+ fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w);
/* hardware window 0 doesn't support color key. */
if (win != 0)
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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 10/22] drm/exynos: introduce exynos_drm_plane_config structure
Hi Marek,
2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
> This patch adds common structure for keeping plane configuration and
> capabilities data. This patch is inspired by similar code developed by
> Tobias Jakobi.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18 ---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c| 23 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 19
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 25 ++-
> drivers/gpu/drm/exynos/exynos_drm_plane.c | 34 +
> drivers/gpu/drm/exynos/exynos_drm_plane.h | 7 ++---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 25 ++-
> drivers/gpu/drm/exynos/exynos_mixer.c | 44
> +++
> 8 files changed, 121 insertions(+), 74 deletions(-)
>
<--snip-->
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> index 3ce141236fad..90701647aef1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
> @@ -30,7 +30,6 @@
>
> /* vidi has totally three virtual windows. */
> #define WINDOWS_NR 3
> -#define CURSOR_WIN 2
>
> #define ctx_from_connector(c)container_of(c, struct vidi_context, \
> connector)
> @@ -90,6 +89,12 @@ static const uint32_t formats[] = {
> DRM_FORMAT_NV12,
> };
>
> +static const enum drm_plane_type vidi_win_types[WINDOWS_NR] = {
> + DRM_PLANE_TYPE_PRIMARY,
> + DRM_PLANE_TYPE_OVERLAY,
> + DRM_PLANE_TYPE_CURSOR,
> +};
> +
> static int vidi_enable_vblank(struct exynos_drm_crtc *crtc)
> {
> struct vidi_context *ctx = crtc->ctx;
> @@ -442,17 +447,21 @@ static int vidi_bind(struct device *dev, struct device
> *master, void *data)
> struct drm_device *drm_dev = data;
> struct drm_encoder *encoder = &ctx->encoder;
> struct exynos_drm_plane *exynos_plane;
> - enum drm_plane_type type;
> - unsigned int zpos;
> + struct exynos_drm_plane_config plane_config = { 0 };
> + unsigned int i;
> int pipe, ret;
>
> vidi_ctx_initialize(ctx, drm_dev);
>
> - for (zpos = 0; zpos < WINDOWS_NR; zpos++) {
> - type = exynos_plane_get_type(zpos, CURSOR_WIN);
> - ret = exynos_plane_init(drm_dev, &ctx->planes[zpos],
> - 1 << ctx->pipe, type, formats,
> - ARRAY_SIZE(formats), zpos);
> + plane_config.pixel_formats = formats;
> + plane_config.num_pixel_formats = ARRAY_SIZE(formats);
> +
> + for (i = 0; i < WINDOWS_NR; i++) {
> + plane_config.zpos = i;
> + plane_config.type = vidi_win_types(i);
vidi_win_types is not really a function. So this should be 'vidi_win_type[i]'
This is a trivial so I can fix it.
Thanks,
Inki Dae
> +
> + ret = exynos_plane_init(drm_dev, &ctx->planes[i],
> + 1 << ctx->pipe, &plane_config);
> if (ret)
> return ret;
> }
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 8d2ce13eb725..a229f86d221a 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -43,7 +43,6 @@
>
> #define MIXER_WIN_NR 3
> #define VP_DEFAULT_WIN 2
> -#define CURSOR_WIN 1
>
> /* The pixelformats that are natively supported by the mixer. */
> #define MXR_FORMAT_RGB5654
> @@ -112,6 +111,25 @@ struct mixer_drv_data {
> boolhas_sclk;
> };
>
> +static const struct exynos_drm_plane_config plane_configs[MIXER_WIN_NR] = {
> + {
> + .zpos = 0,
> + .type = DRM_PLANE_TYPE_PRIMARY,
> + .pixel_formats = mixer_formats,
> + .num_pixel_formats = ARRAY_SIZE(mixer_formats),
> + }, {
> + .zpos = 1,
> + .type = DRM_PLANE_TYPE_CURSOR,
> + .pixel_formats = mixer_formats,
> + .num_pixel_formats = ARRAY_SIZE(mixer_formats),
> + }, {
> + .zpos = 2,
> + .type = DRM_PLANE_TYPE_OVERLAY,
> + .pixel_formats = vp_formats,
> + .num_pixel_formats = ARRAY_SIZE(vp_formats),
> + },
> +};
> +
> static const u8 filter_y_horiz_tap8[] = {
> 0, -1, -1, -1, -1, -1, -1, -1,
> -1, -1, -1, -1, -1, 0, 0, 0,
> @@ -1155,33 +1173,19 @@ static int mixer_bind(struct device *dev, struct
> device *manager, void *data)
> struct mixer_context *ctx = dev_get_drvdata(dev);
> struct drm_device *drm_dev = data;
> struct exynos_drm_plane *exynos_plane;
> - unsigned int zpos;
> + unsigned int i;
> int ret;
>
> ret = mixer_initialize(ctx, drm_d
Re: [PATCH v2 14/22] drm/exynos: fimd: fix dma burst size setting for small plane size
Hi Marek,
2015년 11월 30일 22:53에 Marek Szyprowski 이(가) 쓴 글:
> This patch fixes trashed display of buffers cropped to very small width.
> Even if DMA is unstable and causes tearing when changing the burst size,
> it is still better than displaying a garbage.
It seems that this patch is different from above description. I think below
patch is just cleanup,
which passes each member necessary instead of passing a drm_framebuffer object.
Thanks,
Inki Dae
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 +++-
> 1 file changed, 11 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 70cd2681e343..2e2247126581 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -487,7 +487,7 @@ static void fimd_commit(struct exynos_drm_crtc *crtc)
>
>
> static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
> - struct drm_framebuffer *fb)
> + uint32_t pixel_format, int width)
> {
> unsigned long val;
>
> @@ -498,11 +498,11 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
>* So the request format is ARGB then change it to XRGB.
>*/
> if (ctx->driver_data->has_limited_fmt && !win) {
> - if (fb->pixel_format == DRM_FORMAT_ARGB)
> - fb->pixel_format = DRM_FORMAT_XRGB;
> + if (pixel_format == DRM_FORMAT_ARGB)
> + pixel_format = DRM_FORMAT_XRGB;
> }
>
> - switch (fb->pixel_format) {
> + switch (pixel_format) {
> case DRM_FORMAT_C8:
> val |= WINCON0_BPPMODE_8BPP_PALETTE;
> val |= WINCONx_BURSTLEN_8WORD;
> @@ -538,17 +538,15 @@ static void fimd_win_set_pixfmt(struct fimd_context
> *ctx, unsigned int win,
> break;
> }
>
> - DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
> -
> /*
> - * In case of exynos, setting dma-burst to 16Word causes permanent
> - * tearing for very small buffers, e.g. cursor buffer. Burst Mode
> - * switching which is based on plane size is not recommended as
> - * plane size varies alot towards the end of the screen and rapid
> - * movement causes unstable DMA which results into iommu crash/tear.
> + * Setting dma-burst to 16Word causes permanent tearing for very small
> + * buffers, e.g. cursor buffer. Burst Mode switching which based on
> + * plane size is not recommended as plane size varies alot towards the
> + * end of the screen and rapid movement causes unstable DMA, but it is
> + * still better to change dma-burst than displaying garbage.
>*/
>
> - if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> + if (width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
> val &= ~WINCONx_BURSTLEN_MASK;
> val |= WINCONx_BURSTLEN_4WORD;
> }
> @@ -723,7 +721,7 @@ static void fimd_update_plane(struct exynos_drm_crtc
> *crtc,
> DRM_DEBUG_KMS("osd size = 0x%x\n", (unsigned int)val);
> }
>
> - fimd_win_set_pixfmt(ctx, win, fb);
> + fimd_win_set_pixfmt(ctx, win, fb->pixel_format, state->src.w);
>
> /* hardware window 0 doesn't support color key. */
> if (win != 0)
>
--
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 v10 19/19] drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable time
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
OUT <-- analogix_dp_bridge
OUT <-- DRM IOCTL
The dead lock flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
IN --> analogix_dp_hotplug
IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in
previous step 1)
** Dead Lock Now **
It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.
The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.
Signed-off-by: Yakir Yang
---
This patch was introduced in v10.1, suggested by Heiko
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++
drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 3 +-
drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 26 +
3 files changed, 55 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 79ba88e..5977e06 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -848,47 +848,40 @@ static void analogix_dp_enable_scramble(struct
analogix_dp_device *dp,
}
}
-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
{
struct analogix_dp_device *dp = arg;
-
+ irqreturn_t ret = IRQ_NONE;
enum dp_irq_type irq_type;
irq_type = analogix_dp_get_irq_type(dp);
- switch (irq_type) {
- case DP_IRQ_TYPE_HP_CABLE_IN:
- dev_dbg(dp->dev, "Received irq - cable in\n");
- schedule_work(&dp->hotplug_work);
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CABLE_OUT:
- dev_dbg(dp->dev, "Received irq - cable out\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- case DP_IRQ_TYPE_HP_CHANGE:
- /*
-* We get these change notifications once in a while, but there
-* is nothing we can do with them. Just ignore it for now and
-* only handle cable changes.
-*/
- dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
- analogix_dp_clear_hotplug_interrupts(dp);
- break;
- default:
- dev_err(dp->dev, "Received irq - unknown type!\n");
- break;
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_mute_hpd_interrupt(dp);
+ ret = IRQ_WAKE_THREAD;
}
- return IRQ_HANDLED;
+
+ return ret;
}
-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
{
- struct analogix_dp_device *dp;
+ struct analogix_dp_device *dp = arg;
+ enum dp_irq_type irq_type;
+
+ irq_type = analogix_dp_get_irq_type(dp);
+ if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+ irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+ dev_dbg(dp->dev, "Detected cable status changed!\n");
+ if (dp->drm_dev)
+ drm_helper_hpd_irq_event(dp->drm_dev);
+ }
- dp = container_of(work, struct analogix_dp_device, hotplug_work);
+ if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+ analogix_dp_clear_hotplug_interrupts(dp);
+ analogix_dp_unmute_hpd_interrupt(dp);
+ }
- if (dp->drm_dev)
- drm_helper_hpd_irq_event(dp->drm_dev);
+ return IRQ_HANDLED;
}
static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1041,7 +1034,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
}
disable_irq(dp->irq);
- flush_work(&dp->hotplug_work);
phy_power_off(dp->phy);
if (dp->plat_data->power_off)
@@ -1300,8 +1292,6 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
return -ENODEV;
}
- INIT_WORK(&dp->hotplug_work, analogix_dp_hotplug);
-
pm_runtime_enable(dev);
[PATCH v10 18/19] drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time
Turn off the panel power in suspend time would help to reduce
power waste.
Signed-off-by: Yakir Yang
---
This patch was introduced in v10.1, suggested by Heiko
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f5047ac..79ba88e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1364,6 +1364,12 @@ int analogix_dp_suspend(struct device *dev)
struct analogix_dp_device *dp = dev_get_drvdata(dev);
clk_disable_unprepare(dp->clock);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1379,6 +1385,13 @@ int analogix_dp_resume(struct device *dev)
return ret;
}
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(analogix_dp_resume);
--
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 v10.1 15/19] drm: bridge: analogix/dp: move hpd detect to connector detect function
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase
But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v10.1:
- Move the panel prepare from get_modes time to bind time, and move
the panel unprepare from bridge->disable to unbind time. (Heiko)
Changes in v10:
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
Add dp phy poweron function in bind time.
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.
Changes in v3:
- move dp hpd detect to connector detect function.
Changes in v2: None
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 00aee44..6a13167 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
DRM_ERROR("failed to disable the panel\n");
}
- ret = analogix_dp_detect_hpd(dp);
- if (ret) {
- /* Cable has been disconnected, we're done */
- return;
- }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device
*dp)
enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
{
+ struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+ if (analogix_dp_detect_hpd(dp))
+ return connector_status_disconnected;
+
return connector_status_connected;
}
EXPORT_SYMBOL_GPL(analogix_dp_detect);
@@ -1006,13 +1005,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge
*bridge)
pm_runtime_get_sync(dp->dev);
- if (dp->plat_data->panel) {
- if (drm_panel_prepare(dp->plat_data->panel)) {
- DRM_ERROR("failed to setup the panel\n");
- return;
- }
- }
-
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);
@@ -1045,11 +1037,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge
*bridge)
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);
- if (dp->plat_data->panel) {
- if (drm_panel_unprepare(dp->plat_data->panel))
- DRM_ERROR("failed to turnoff the panel\n");
- }
-
pm_runtime_put_sync(dp->dev);
dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1307,6 +1294,15 @@ int analogix_dp_bind(struct device *dev, struct
drm_device *drm_dev,
pm_runtime_enable(dev);
+ phy_power_on(dp->phy);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_prepare(dp->plat_data->panel)) {
+ DRM_ERROR("failed to setup the panel\n");
+ return -EBUSY;
+ }
+ }
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
irq_flags, "analogix-dp", dp);
if (ret) {
@@ -1340,6 +1336,12 @@ void analogix_dp_unbind(struct device *dev, struct
device *master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);
analogix_dp_bridge_disable(dp->bridge);
+
+ if (dp->plat_data->panel) {
+ if (drm_panel_unprepare(dp->plat_data->panel))
+ DRM_ERROR("failed to turnoff the panel\n");
+ }
+
pm_runtime_disable(&pdev->dev);
}
EXPORT_SYMBOL_GPL(analogix_dp_unbind);
--
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 04/58] mtd: nand: omap2: create and use mtd_to_omap()
Define and use mtd_to_omap() instead of container_of();
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/omap2.c | 55 ++--
1 file changed, 21 insertions(+), 34 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 944a74e..1fb40db 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -177,6 +177,10 @@ struct omap_nand_info {
struct device_node *of_node;
};
+static inline struct omap_nand_info *mtd_to_omap(struct mtd_info *mtd)
+{
+ return container_of(mtd, struct omap_nand_info, mtd);
+}
/**
* omap_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
@@ -247,8 +251,7 @@ static int omap_prefetch_reset(int cs, struct
omap_nand_info *info)
*/
static void omap_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
if (cmd != NAND_CMD_NONE) {
if (ctrl & NAND_CLE)
@@ -283,8 +286,7 @@ static void omap_read_buf8(struct mtd_info *mtd, u_char
*buf, int len)
*/
static void omap_write_buf8(struct mtd_info *mtd, const u_char *buf, int len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
u_char *p = (u_char *)buf;
u32 status = 0;
@@ -319,8 +321,7 @@ static void omap_read_buf16(struct mtd_info *mtd, u_char
*buf, int len)
*/
static void omap_write_buf16(struct mtd_info *mtd, const u_char * buf, int len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
u16 *p = (u16 *) buf;
u32 status = 0;
/* FIXME try bursts of writesw() or DMA ... */
@@ -344,8 +345,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const
u_char * buf, int len)
*/
static void omap_read_buf_pref(struct mtd_info *mtd, u_char *buf, int len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
uint32_t r_count = 0;
int ret = 0;
u32 *p = (u32 *)buf;
@@ -392,8 +392,7 @@ static void omap_read_buf_pref(struct mtd_info *mtd, u_char
*buf, int len)
static void omap_write_buf_pref(struct mtd_info *mtd,
const u_char *buf, int len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
uint32_t w_count = 0;
int i = 0, ret = 0;
u16 *p = (u16 *)buf;
@@ -458,8 +457,7 @@ static void omap_nand_dma_callback(void *data)
static inline int omap_nand_dma_transfer(struct mtd_info *mtd, void *addr,
unsigned int len, int is_write)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
struct dma_async_tx_descriptor *tx;
enum dma_data_direction dir = is_write ? DMA_TO_DEVICE :
DMA_FROM_DEVICE;
@@ -623,8 +621,7 @@ done:
*/
static void omap_read_buf_irq_pref(struct mtd_info *mtd, u_char *buf, int len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
int ret = 0;
if (len <= mtd->oobsize) {
@@ -671,8 +668,7 @@ out_copy:
static void omap_write_buf_irq_pref(struct mtd_info *mtd,
const u_char *buf, int len)
{
- struct omap_nand_info *info = container_of(mtd,
- struct omap_nand_info, mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
int ret = 0;
unsigned long tim, limit;
u32 val;
@@ -886,8 +882,7 @@ static int omap_compare_ecc(u8 *ecc_data1, /* read from
NAND memory */
static int omap_correct_data(struct mtd_info *mtd, u_char *dat,
u_char *read_ecc, u_char *calc_ecc)
{
- struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
- mtd);
+ struct omap_nand_info *info = mtd_to_omap(mtd);
int blockCnt = 0, i = 0, ret = 0;
int stat = 0;
@@ -928,8 +923,7 @@ static int omap_correct_data(struct mtd_info *mtd, u_char
*dat,
static int omap_calculate_ecc(
[PATCH v4 06/58] mtd: nand: atmel: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
Changes generated with the following coccinelle script
--->8---
virtual patch
@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
- struct mtd_info __mtdfield;
...
};
|
__type {
...
- struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)
@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
- __priv->__mtdfield.__subfield
+ nand_to_mtd(&__priv->__chipfield)->__subfield
|
- &(__priv->__mtdfield)
+ nand_to_mtd(&__priv->__chipfield)
)
--->8---
---
drivers/mtd/nand/atmel_nand.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index edd191a..9ba2831 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -116,7 +116,6 @@ static struct atmel_nfc nand_nfc;
struct atmel_nand_host {
struct nand_chipnand_chip;
- struct mtd_info mtd;
void __iomem*io_base;
dma_addr_t io_phys;
struct atmel_nand_data board;
@@ -317,8 +316,10 @@ static int nfc_set_sram_bank(struct atmel_nand_host *host,
unsigned int bank)
return -EINVAL;
if (bank) {
+ struct mtd_info *mtd = nand_to_mtd(&host->nand_chip);
+
/* Only for a 2k-page or lower flash, NFC can handle 2 banks */
- if (host->mtd.writesize > 2048)
+ if (mtd->writesize > 2048)
return -EINVAL;
nfc_writel(host->nfc->hsmc_regs, BANK, ATMEL_HSMC_NFC_BANK1);
} else {
@@ -1159,8 +1160,8 @@ static uint16_t *create_lookup_table(struct device *dev,
int sector_size)
static int atmel_pmecc_nand_init_params(struct platform_device *pdev,
struct atmel_nand_host *host)
{
- struct mtd_info *mtd = &host->mtd;
struct nand_chip *nand_chip = &host->nand_chip;
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
struct resource *regs, *regs_pmerr, *regs_rom;
uint16_t *galois_table;
int cap, sector_size, err_no;
@@ -1586,8 +1587,8 @@ static int atmel_of_init_port(struct atmel_nand_host
*host,
static int atmel_hw_nand_init_params(struct platform_device *pdev,
struct atmel_nand_host *host)
{
- struct mtd_info *mtd = &host->mtd;
struct nand_chip *nand_chip = &host->nand_chip;
+ struct mtd_info *mtd = nand_to_mtd(nand_chip);
struct resource *regs;
regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -2112,8 +2113,8 @@ static int atmel_nand_probe(struct platform_device *pdev)
}
host->io_phys = (dma_addr_t)mem->start;
- mtd = &host->mtd;
nand_chip = &host->nand_chip;
+ mtd = nand_to_mtd(nand_chip);
host->dev = &pdev->dev;
if (IS_ENABLED(CONFIG_OF) && pdev->dev.of_node) {
nand_set_flash_node(nand_chip, pdev->dev.of_node);
@@ -2283,7 +2284,7 @@ err_nand_ioremap:
static int atmel_nand_remove(struct platform_device *pdev)
{
struct atmel_nand_host *host = platform_get_drvdata(pdev);
- struct mtd_info *mtd = &host->mtd;
+ struct mtd_info *mtd = nand_to_mtd(&host->nand_chip);
nand_release(mtd);
--
2.1.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
[PATCH v4 07/58] mtd: nand: au1550nd: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
Changes generated with the following coccinelle script
--->8---
virtual patch
@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
- struct mtd_info __mtdfield;
...
};
|
__type {
...
- struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)
@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
- __priv->__mtdfield.__subfield
+ nand_to_mtd(&__priv->__chipfield)->__subfield
|
- &(__priv->__mtdfield)
+ nand_to_mtd(&__priv->__chipfield)
)
--->8---
---
drivers/mtd/nand/au1550nd.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/au1550nd.c b/drivers/mtd/nand/au1550nd.c
index 73fceb8..280e5b6 100644
--- a/drivers/mtd/nand/au1550nd.c
+++ b/drivers/mtd/nand/au1550nd.c
@@ -23,7 +23,6 @@
struct au1550nd_ctx {
- struct mtd_info info;
struct nand_chip chip;
int cs;
@@ -197,8 +196,9 @@ static void au_read_buf16(struct mtd_info *mtd, u_char
*buf, int len)
static void au1550_hwcontrol(struct mtd_info *mtd, int cmd)
{
- struct au1550nd_ctx *ctx = container_of(mtd, struct au1550nd_ctx, info);
struct nand_chip *this = mtd_to_nand(mtd);
+ struct au1550nd_ctx *ctx = container_of(this, struct au1550nd_ctx,
+ chip);
switch (cmd) {
@@ -267,8 +267,9 @@ static void au1550_select_chip(struct mtd_info *mtd, int
chip)
*/
static void au1550_command(struct mtd_info *mtd, unsigned command, int column,
int page_addr)
{
- struct au1550nd_ctx *ctx = container_of(mtd, struct au1550nd_ctx, info);
struct nand_chip *this = mtd_to_nand(mtd);
+ struct au1550nd_ctx *ctx = container_of(this, struct au1550nd_ctx,
+ chip);
int ce_override = 0, i;
unsigned long flags = 0;
@@ -405,6 +406,7 @@ static int au1550nd_probe(struct platform_device *pdev)
struct au1550nd_platdata *pd;
struct au1550nd_ctx *ctx;
struct nand_chip *this;
+ struct mtd_info *mtd;
struct resource *r;
int ret, cs;
@@ -438,8 +440,9 @@ static int au1550nd_probe(struct platform_device *pdev)
}
this = &ctx->chip;
- ctx->info.priv = this;
- ctx->info.dev.parent = &pdev->dev;
+ mtd = nand_to_mtd(this);
+ mtd->priv = this;
+ mtd->dev.parent = &pdev->dev;
/* figure out which CS# r->start belongs to */
cs = find_nand_cs(r->start);
@@ -467,13 +470,13 @@ static int au1550nd_probe(struct platform_device *pdev)
this->write_buf = (pd->devwidth) ? au_write_buf16 : au_write_buf;
this->read_buf = (pd->devwidth) ? au_read_buf16 : au_read_buf;
- ret = nand_scan(&ctx->info, 1);
+ ret = nand_scan(mtd, 1);
if (ret) {
dev_err(&pdev->dev, "NAND scan failed with %d\n", ret);
goto out3;
}
- mtd_device_register(&ctx->info, pd->parts, pd->num_parts);
+ mtd_device_register(mtd, pd->parts, pd->num_parts);
platform_set_drvdata(pdev, ctx);
@@ -493,7 +496,7 @@ static int au1550nd_remove(struct platform_device *pdev)
struct au1550nd_ctx *ctx = platform_get_drvdata(pdev);
struct resource *r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- nand_release(&ctx->info);
+ nand_release(nand_to_mtd(&ctx->chip));
iounmap(ctx->base);
release_mem_region(r->start, 0x1000);
kfree(ctx);
--
2.1.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
[PATCH v4 01/58] mtd: nand: denali: add missing nand_release() call in denali_remove()
Unregister the NAND device from the NAND subsystem when removing a denali
NAND controller, otherwise the MTD attached to the NAND device is still
exposed by the MTD layer, and accesses to this device will likely crash
the system.
Signed-off-by: Boris Brezillon
Cc: #3.8+
Fixes: 2a0a288ec258 ("mtd: denali: split the generic driver and PCI layer")
---
drivers/mtd/nand/denali.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
index 67eb2be..8feece3 100644
--- a/drivers/mtd/nand/denali.c
+++ b/drivers/mtd/nand/denali.c
@@ -1622,6 +1622,7 @@ EXPORT_SYMBOL(denali_init);
/* driver exit point */
void denali_remove(struct denali_nand_info *denali)
{
+ nand_release(&denali->mtd);
denali_irq_cleanup(denali->irq, denali);
dma_unmap_single(denali->dev, denali->buf.dma_buf,
denali->mtd.writesize + denali->mtd.oobsize,
--
2.1.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
[PATCH v4 03/58] mtd: nand: nuc900: create and use mtd_to_nuc900()
Create and use mtd_to_nuc900() instead of direct container_of() calls.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/nuc900_nand.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/nand/nuc900_nand.c b/drivers/mtd/nand/nuc900_nand.c
index 8148cd6..65908c0 100644
--- a/drivers/mtd/nand/nuc900_nand.c
+++ b/drivers/mtd/nand/nuc900_nand.c
@@ -62,6 +62,11 @@ struct nuc900_nand {
spinlock_t lock;
};
+static inline struct nuc900_nand *mtd_to_nuc900(struct mtd_info *mtd)
+{
+ return container_of(mtd, struct nuc900_nand, mtd);
+}
+
static const struct mtd_partition partitions[] = {
{
.name = "NAND FS 0",
@@ -78,9 +83,7 @@ static const struct mtd_partition partitions[] = {
static unsigned char nuc900_nand_read_byte(struct mtd_info *mtd)
{
unsigned char ret;
- struct nuc900_nand *nand;
-
- nand = container_of(mtd, struct nuc900_nand, mtd);
+ struct nuc900_nand *nand = mtd_to_nuc900(mtd);
ret = (unsigned char)read_data_reg(nand);
@@ -91,9 +94,7 @@ static void nuc900_nand_read_buf(struct mtd_info *mtd,
unsigned char *buf, int len)
{
int i;
- struct nuc900_nand *nand;
-
- nand = container_of(mtd, struct nuc900_nand, mtd);
+ struct nuc900_nand *nand = mtd_to_nuc900(mtd);
for (i = 0; i < len; i++)
buf[i] = (unsigned char)read_data_reg(nand);
@@ -103,9 +104,7 @@ static void nuc900_nand_write_buf(struct mtd_info *mtd,
const unsigned char *buf, int len)
{
int i;
- struct nuc900_nand *nand;
-
- nand = container_of(mtd, struct nuc900_nand, mtd);
+ struct nuc900_nand *nand = mtd_to_nuc900(mtd);
for (i = 0; i < len; i++)
write_data_reg(nand, buf[i]);
@@ -124,11 +123,9 @@ static int nuc900_check_rb(struct nuc900_nand *nand)
static int nuc900_nand_devready(struct mtd_info *mtd)
{
- struct nuc900_nand *nand;
+ struct nuc900_nand *nand = mtd_to_nuc900(mtd);
int ready;
- nand = container_of(mtd, struct nuc900_nand, mtd);
-
ready = (nuc900_check_rb(nand)) ? 1 : 0;
return ready;
}
@@ -137,9 +134,7 @@ static void nuc900_nand_command_lp(struct mtd_info *mtd,
unsigned int command,
int column, int page_addr)
{
register struct nand_chip *chip = mtd_to_nand(mtd);
- struct nuc900_nand *nand;
-
- nand = container_of(mtd, struct nuc900_nand, mtd);
+ struct nuc900_nand *nand = mtd_to_nuc900(mtd);
if (command == NAND_CMD_READOOB) {
column += mtd->writesize;
--
2.1.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
[PATCH v4 00/58] mtd: nand: refactor the NAND subsystem (part 1)
Hello, This huge series aims at clarifying the relationship between the mtd and nand_chip structures and hiding NAND framework internals to NAND controller drivers. The first part of the series (patch 1 to 4) is a set of fixes/simple reworks easing the migration to mtd_to_nand(). The second part of the series embeds the mtd structure into the nand_chip one so that NAND controller drivers don't have to bother allocating the MTD device and linking it with the NAND chip. The last part of the series hides accesses to the chip->priv field behind two helper functions. This allows removal of some of the boilerplate code done in all NAND controller drivers, but most importantly, it unifies a bit the way NAND chip structures are instantiated (even though we still have two different kinds of drivers: those embedding the nand_chip struct into their private nand chip representation, and those allocating two different structures and linking them together with the chip->priv field). As said in the title, this refactoring is only the first step. I plan to rework the NAND controller / NAND chip separation for pretty much the same reasons: clarifying the separation between the two concepts, and getting rid of more boilerplate code in NAND controller drivers. Stay tuned ;-). Best Regards, Boris Changes since v3: - fix some bugs introduced when migrating to nand_to_mtd() - split the huge commit switching all drivers to nand_to_mtd() into several commits (one per driver) to ease review and integration - add a simple fixes/reworks at the beginning of the series (mainly to ease migration to nand_to_mtd()) - drop already applied patches. Changes since v2: - fix some build warnings/erros Changes since v1: - dropped already applied patches - fixed some typos - manually fixed some modifications omitted by the coccinelle scripts - manually reworked modifactions done by coccinelle scripts to improve readability and fix coding style issues *** BLURB HERE *** Boris Brezillon (58): mtd: nand: denali: add missing nand_release() call in denali_remove() mtd: nand: fsmc: create and use mtd_to_fsmc() mtd: nand: nuc900: create and use mtd_to_nuc900() mtd: nand: omap2: create and use mtd_to_omap() mtd: nand: ams-delta: use the mtd instance embedded in struct nand_chip mtd: nand: atmel: use the mtd instance embedded in struct nand_chip mtd: nand: au1550nd: use the mtd instance embedded in struct nand_chip mtd: nand: bcm47xx: use the mtd instance embedded in struct nand_chip mtd: nand: bf5xx: use the mtd instance embedded in struct nand_chip mtd: nand: brcm: use the mtd instance embedded in struct nand_chip mtd: nand: cafe: use the mtd instance embedded in struct nand_chip mtd: nand: cmx270: use the mtd instance embedded in struct nand_chip mtd: nand: cs553x: use the mtd instance embedded in struct nand_chip mtd: nand: davinci: use the mtd instance embedded in struct nand_chip mtd: nand: denali: use the mtd instance embedded in struct nand_chip mtd: nand: diskonchip: use the mtd instance embedded in struct nand_chip mtd: nand: docg4: use the mtd instance embedded in struct nand_chip mtd: nand: fsl_elbc: use the mtd instance embedded in struct nand_chip mtd: nand: fsl_ifc: use the mtd instance embedded in struct nand_chip mtd: nand: fsl_upm: use the mtd instance embedded in struct nand_chip mtd: nand: fsmc: use the mtd instance embedded in struct nand_chip mtd: nand: gpio: use the mtd instance embedded in struct nand_chip mtd: nand: gpmi: use the mtd instance embedded in struct nand_chip mtd: nand: hisi504: use the mtd instance embedded in struct nand_chip mtd: nand: jz4740: use the mtd instance embedded in struct nand_chip mtd: nand: lpc32xx: use the mtd instance embedded in struct nand_chip mtd: nand: mpc5121: use the mtd instance embedded in struct nand_chip mtd: nand: mxc: use the mtd instance embedded in struct nand_chip mtd: nand: nandsim: use the mtd instance embedded in struct nand_chip mtd: nand: ndfc: use the mtd instance embedded in struct nand_chip mtd: nand: nuc900: use the mtd instance embedded in struct nand_chip mtd: nand: omap2: use the mtd instance embedded in struct nand_chip mtd: nand: orion: use the mtd instance embedded in struct nand_chip mtd: nand: pasemi: use the mtd instance embedded in struct nand_chip mtd: nand: plat: use the mtd instance embedded in struct nand_chip mtd: nand: pxa3xx: use the mtd instance embedded in struct nand_chip mtd: nand: r852: use the mtd instance embedded in struct nand_chip mtd: nand: s3c2410: use the mtd instance embedded in struct nand_chip mtd: nand: sh_flctl: use the mtd instance embedded in struct nand_chip mtd: nand: sharpsl: use the mtd instance embedded in struct nand_chip mtd: nand: socrates: use the mtd instance embedded in struct nand_chip mtd: nand: sunxi: use the mtd instance embedded in struct nand_chip mtd: nand: tmio: use the mtd instance embedded in struct nand_ch
[PATCH v4 02/58] mtd: nand: fsmc: create and use mtd_to_fsmc()
Create and use mtd_to_fsmc() to avoid duplication of
container_of(mtd, struct fsmc_nand_data, mtd) calls.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/fsmc_nand.c | 31 ++-
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 1c6c399..499fc59 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -326,13 +326,18 @@ struct fsmc_nand_data {
void(*select_chip)(uint32_t bank, uint32_t busw);
};
+static inline struct fsmc_nand_data *mtd_to_fsmc(struct mtd_info *mtd)
+{
+ return container_of(mtd, struct fsmc_nand_data, mtd);
+}
+
/* Assert CS signal based on chipnr */
static void fsmc_select_chip(struct mtd_info *mtd, int chipnr)
{
struct nand_chip *chip = mtd_to_nand(mtd);
struct fsmc_nand_data *host;
- host = container_of(mtd, struct fsmc_nand_data, mtd);
+ host = mtd_to_fsmc(mtd);
switch (chipnr) {
case -1:
@@ -359,8 +364,7 @@ static void fsmc_select_chip(struct mtd_info *mtd, int
chipnr)
static void fsmc_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
{
struct nand_chip *this = mtd_to_nand(mtd);
- struct fsmc_nand_data *host = container_of(mtd,
- struct fsmc_nand_data, mtd);
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
void __iomem *regs = host->regs_va;
unsigned int bank = host->bank;
@@ -445,8 +449,7 @@ static void fsmc_nand_setup(void __iomem *regs, uint32_t
bank,
*/
static void fsmc_enable_hwecc(struct mtd_info *mtd, int mode)
{
- struct fsmc_nand_data *host = container_of(mtd,
- struct fsmc_nand_data, mtd);
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
void __iomem *regs = host->regs_va;
uint32_t bank = host->bank;
@@ -466,8 +469,7 @@ static void fsmc_enable_hwecc(struct mtd_info *mtd, int
mode)
static int fsmc_read_hwecc_ecc4(struct mtd_info *mtd, const uint8_t *data,
uint8_t *ecc)
{
- struct fsmc_nand_data *host = container_of(mtd,
- struct fsmc_nand_data, mtd);
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
void __iomem *regs = host->regs_va;
uint32_t bank = host->bank;
uint32_t ecc_tmp;
@@ -517,8 +519,7 @@ static int fsmc_read_hwecc_ecc4(struct mtd_info *mtd, const
uint8_t *data,
static int fsmc_read_hwecc_ecc1(struct mtd_info *mtd, const uint8_t *data,
uint8_t *ecc)
{
- struct fsmc_nand_data *host = container_of(mtd,
- struct fsmc_nand_data, mtd);
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
void __iomem *regs = host->regs_va;
uint32_t bank = host->bank;
uint32_t ecc_tmp;
@@ -674,9 +675,8 @@ static void fsmc_read_buf(struct mtd_info *mtd, uint8_t
*buf, int len)
*/
static void fsmc_read_buf_dma(struct mtd_info *mtd, uint8_t *buf, int len)
{
- struct fsmc_nand_data *host;
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
- host = container_of(mtd, struct fsmc_nand_data, mtd);
dma_xfer(host, buf, len, DMA_FROM_DEVICE);
}
@@ -689,9 +689,8 @@ static void fsmc_read_buf_dma(struct mtd_info *mtd, uint8_t
*buf, int len)
static void fsmc_write_buf_dma(struct mtd_info *mtd, const uint8_t *buf,
int len)
{
- struct fsmc_nand_data *host;
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
- host = container_of(mtd, struct fsmc_nand_data, mtd);
dma_xfer(host, (void *)buf, len, DMA_TO_DEVICE);
}
@@ -712,8 +711,7 @@ static void fsmc_write_buf_dma(struct mtd_info *mtd, const
uint8_t *buf,
static int fsmc_read_page_hwecc(struct mtd_info *mtd, struct nand_chip *chip,
uint8_t *buf, int oob_required, int page)
{
- struct fsmc_nand_data *host = container_of(mtd,
- struct fsmc_nand_data, mtd);
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
struct fsmc_eccplace *ecc_place = host->ecc_place;
int i, j, s, stat, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
@@ -782,9 +780,8 @@ static int fsmc_read_page_hwecc(struct mtd_info *mtd,
struct nand_chip *chip,
static int fsmc_bch8_correct_data(struct mtd_info *mtd, uint8_t *dat,
uint8_t *read_ecc, uint8_t *calc_ecc)
{
- struct fsmc_nand_data *host = container_of(mtd,
- struct fsmc_nand_data, mtd);
struct nand_chip *chip = mtd_to_nand(mtd);
+ struct fsmc_nand_data *host = mtd_to_fsmc(mtd);
void __iomem *regs = host->regs_va;
unsigned int bank = host->bank;
uint32_t err_idx[8];
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linu
[PATCH v4 09/58] mtd: nand: bf5xx: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
Changes generated with the following coccinelle script
--->8---
virtual patch
@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
- struct mtd_info __mtdfield;
...
};
|
__type {
...
- struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)
@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
- __priv->__mtdfield.__subfield
+ nand_to_mtd(&__priv->__chipfield)->__subfield
|
- &(__priv->__mtdfield)
+ nand_to_mtd(&__priv->__chipfield)
)
--->8---
---
drivers/mtd/nand/bf5xx_nand.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index d9da5ed..928d599 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -142,7 +142,6 @@ static struct nand_ecclayout bootrom_ecclayout = {
struct bf5xx_nand_info {
/* mtd info */
struct nand_hw_control controller;
- struct mtd_info mtd;
struct nand_chipchip;
/* platform info */
@@ -160,7 +159,8 @@ struct bf5xx_nand_info {
*/
static struct bf5xx_nand_info *mtd_to_nand_info(struct mtd_info *mtd)
{
- return container_of(mtd, struct bf5xx_nand_info, mtd);
+ return container_of(mtd_to_nand(mtd), struct bf5xx_nand_info,
+ chip);
}
static struct bf5xx_nand_info *to_nand_info(struct platform_device *pdev)
@@ -660,7 +660,7 @@ static int bf5xx_nand_hw_init(struct bf5xx_nand_info *info)
*/
static int bf5xx_nand_add_partition(struct bf5xx_nand_info *info)
{
- struct mtd_info *mtd = &info->mtd;
+ struct mtd_info *mtd = nand_to_mtd(&info->chip);
struct mtd_partition *parts = info->platform->partitions;
int nr = info->platform->nr_partitions;
@@ -675,7 +675,7 @@ static int bf5xx_nand_remove(struct platform_device *pdev)
* and their partitions, then go through freeing the
* resources used
*/
- nand_release(&info->mtd);
+ nand_release(nand_to_mtd(&info->chip));
peripheral_free_list(bfin_nfc_pin_req);
bf5xx_nand_dma_remove(info);
@@ -756,6 +756,7 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
/* initialise chip data struct */
chip = &info->chip;
+ mtd = nand_to_mtd(&info->chip);
if (plat->data_width)
chip->options |= NAND_BUSWIDTH_16;
@@ -772,7 +773,7 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
chip->cmd_ctrl = bf5xx_nand_hwcontrol;
chip->dev_ready= bf5xx_nand_devready;
- chip->priv = &info->mtd;
+ chip->priv = mtd;
chip->controller = &info->controller;
chip->IO_ADDR_R= (void __iomem *) NFC_READ;
@@ -781,7 +782,6 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
chip->chip_delay = 0;
/* initialise mtd info data struct */
- mtd = &info->mtd;
mtd->priv = chip;
mtd->dev.parent = &pdev->dev;
--
2.1.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
[PATCH v4 12/58] mtd: nand: cmx270: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/cmx270_nand.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
index 43bded6..6b26e0c 100644
--- a/drivers/mtd/nand/cmx270_nand.c
+++ b/drivers/mtd/nand/cmx270_nand.c
@@ -160,10 +160,8 @@ static int __init cmx270_init(void)
gpio_direction_input(GPIO_NAND_RB);
/* Allocate memory for MTD device structure and private data */
- cmx270_nand_mtd = kzalloc(sizeof(struct mtd_info) +
- sizeof(struct nand_chip),
- GFP_KERNEL);
- if (!cmx270_nand_mtd) {
+ this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
+ if (!this) {
ret = -ENOMEM;
goto err_kzalloc;
}
@@ -175,8 +173,7 @@ static int __init cmx270_init(void)
goto err_ioremap;
}
- /* Get pointer to private data */
- this = (struct nand_chip *)(&cmx270_nand_mtd[1]);
+ cmx270_nand_mtd = nand_to_mtd(this);
/* Link the private data with the MTD structure */
cmx270_nand_mtd->owner = THIS_MODULE;
@@ -216,7 +213,7 @@ static int __init cmx270_init(void)
err_scan:
iounmap(cmx270_nand_io);
err_ioremap:
- kfree(cmx270_nand_mtd);
+ kfree(this);
err_kzalloc:
gpio_free(GPIO_NAND_RB);
err_gpio_request:
@@ -241,7 +238,7 @@ static void __exit cmx270_cleanup(void)
iounmap(cmx270_nand_io);
/* Free the MTD device structure */
- kfree (cmx270_nand_mtd);
+ kfree(mtd_to_nand(cmx270_nand_mtd));
}
module_exit(cmx270_cleanup);
--
2.1.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
[PATCH v4 10/58] mtd: nand: brcm: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
Changes generated with the following coccinelle script
--->8---
virtual patch
@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
- struct mtd_info __mtdfield;
...
};
|
__type {
...
- struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)
@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
- __priv->__mtdfield.__subfield
+ nand_to_mtd(&__priv->__chipfield)->__subfield
|
- &(__priv->__mtdfield)
+ nand_to_mtd(&__priv->__chipfield)
)
--->8---
---
drivers/mtd/nand/brcmnand/brcmnand.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 190a99a..26b64bc 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -178,7 +178,6 @@ struct brcmnand_host {
struct list_headnode;
struct nand_chipchip;
- struct mtd_info mtd;
struct platform_device *pdev;
int cs;
@@ -1074,7 +1073,7 @@ static int brcmnand_low_level_op(struct brcmnand_host
*host,
enum brcmnand_llop_type type, u32 data,
bool last_op)
{
- struct mtd_info *mtd = &host->mtd;
+ struct mtd_info *mtd = nand_to_mtd(&host->chip);
struct nand_chip *chip = &host->chip;
struct brcmnand_controller *ctrl = host->ctrl;
u32 tmp;
@@ -1802,7 +1801,7 @@ static inline int get_blk_adr_bytes(u64 size, u32
writesize)
static int brcmnand_setup_dev(struct brcmnand_host *host)
{
- struct mtd_info *mtd = &host->mtd;
+ struct mtd_info *mtd = nand_to_mtd(&host->chip);
struct nand_chip *chip = &host->chip;
struct brcmnand_controller *ctrl = host->ctrl;
struct brcmnand_cfg *cfg = &host->hwcfg;
@@ -1916,7 +1915,7 @@ static int brcmnand_init_cs(struct brcmnand_host *host,
struct device_node *dn)
return -ENXIO;
}
- mtd = &host->mtd;
+ mtd = nand_to_mtd(&host->chip);
chip = &host->chip;
nand_set_flash_node(chip, dn);
@@ -2060,8 +2059,8 @@ static int brcmnand_resume(struct device *dev)
}
list_for_each_entry(host, &ctrl->host_list, node) {
- struct mtd_info *mtd = &host->mtd;
- struct nand_chip *chip = mtd_to_nand(mtd);
+ struct nand_chip *chip = &host->chip;
+ struct mtd_info *mtd = nand_to_mtd(chip);
brcmnand_save_restore_cs_config(host, 1);
@@ -2262,7 +2261,7 @@ int brcmnand_remove(struct platform_device *pdev)
struct brcmnand_host *host;
list_for_each_entry(host, &ctrl->host_list, node)
- nand_release(&host->mtd);
+ nand_release(nand_to_mtd(&host->chip));
dev_set_drvdata(&pdev->dev, NULL);
--
2.1.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
[PATCH v4 08/58] mtd: nand: bcm47xx: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
Changes generated with the following coccinelle script
--->8---
virtual patch
@fix1@
identifier __chipfield, __mtdfield;
type __type;
@@
(
__type {
...
struct nand_chip __chipfield;
...
- struct mtd_info __mtdfield;
...
};
|
__type {
...
- struct mtd_info __mtdfield;
...
struct nand_chip __chipfield;
...
};
)
@fix2 depends on fix1@
identifier fix1.__chipfield, fix1.__mtdfield;
identifier __subfield;
type fix1.__type;
__type *__priv;
@@
(
- __priv->__mtdfield.__subfield
+ nand_to_mtd(&__priv->__chipfield)->__subfield
|
- &(__priv->__mtdfield)
+ nand_to_mtd(&__priv->__chipfield)
)
--->8---
---
drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h | 1 -
drivers/mtd/nand/bcm47xxnflash/main.c | 8 +---
drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c | 2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h
b/drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h
index c005a62..8ea7571 100644
--- a/drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h
+++ b/drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h
@@ -12,7 +12,6 @@ struct bcm47xxnflash {
struct bcma_drv_cc *cc;
struct nand_chip nand_chip;
- struct mtd_info mtd;
unsigned curr_command;
int curr_page_addr;
diff --git a/drivers/mtd/nand/bcm47xxnflash/main.c
b/drivers/mtd/nand/bcm47xxnflash/main.c
index 9ba0c0f..4711ca2b 100644
--- a/drivers/mtd/nand/bcm47xxnflash/main.c
+++ b/drivers/mtd/nand/bcm47xxnflash/main.c
@@ -27,6 +27,7 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
{
struct bcma_nflash *nflash = dev_get_platdata(&pdev->dev);
struct bcm47xxnflash *b47n;
+ struct mtd_info *mtd;
int err = 0;
b47n = devm_kzalloc(&pdev->dev, sizeof(*b47n), GFP_KERNEL);
@@ -34,8 +35,9 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
return -ENOMEM;
b47n->nand_chip.priv = b47n;
- b47n->mtd.dev.parent = &pdev->dev;
- b47n->mtd.priv = &b47n->nand_chip; /* Required */
+ mtd = nand_to_mtd(&b47n->nand_chip);
+ mtd->dev.parent = &pdev->dev;
+ mtd->priv = &b47n->nand_chip; /* Required */
b47n->cc = container_of(nflash, struct bcma_drv_cc, nflash);
if (b47n->cc->core->bus->chipinfo.id == BCMA_CHIP_ID_BCM4706) {
@@ -49,7 +51,7 @@ static int bcm47xxnflash_probe(struct platform_device *pdev)
return err;
}
- err = mtd_device_parse_register(&b47n->mtd, probes, NULL, NULL, 0);
+ err = mtd_device_parse_register(mtd, probes, NULL, NULL, 0);
if (err) {
pr_err("Failed to register MTD device: %d\n", err);
return err;
diff --git a/drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c
b/drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c
index e5b2e48..6524780 100644
--- a/drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c
+++ b/drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c
@@ -421,7 +421,7 @@ int bcm47xxnflash_ops_bcm4706_init(struct bcm47xxnflash
*b47n)
(w4 << 24 | w3 << 18 | w2 << 12 | w1 << 6 | w0));
/* Scan NAND */
- err = nand_scan(&b47n->mtd, 1);
+ err = nand_scan(nand_to_mtd(&b47n->nand_chip), 1);
if (err) {
pr_err("Could not scan NAND flash: %d\n", err);
goto exit;
--
2.1.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
[PATCH v4 11/58] mtd: nand: cafe: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/cafe_nand.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index 77c92f1..7d6a142 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -605,11 +605,11 @@ static int cafe_nand_probe(struct pci_dev *pdev,
pci_set_master(pdev);
- mtd = kzalloc(sizeof(*mtd) + sizeof(struct cafe_priv), GFP_KERNEL);
- if (!mtd)
+ cafe = kzalloc(sizeof(*cafe), GFP_KERNEL);
+ if (!cafe)
return -ENOMEM;
- cafe = (void *)(&mtd[1]);
+ mtd = nand_to_mtd(&cafe->nand);
mtd->dev.parent = &pdev->dev;
mtd->priv = &cafe->nand;
cafe->nand.priv = cafe;
@@ -792,7 +792,7 @@ static int cafe_nand_probe(struct pci_dev *pdev,
out_ior:
pci_iounmap(pdev, cafe->mmio);
out_free_mtd:
- kfree(mtd);
+ kfree(cafe);
out:
return err;
}
@@ -813,7 +813,7 @@ static void cafe_nand_remove(struct pci_dev *pdev)
2112 + sizeof(struct nand_buffers) +
mtd->writesize + mtd->oobsize,
cafe->dmabuf, cafe->dmaaddr);
- kfree(mtd);
+ kfree(cafe);
}
static const struct pci_device_id cafe_nand_tbl[] = {
--
2.1.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
[PATCH v4 13/58] mtd: nand: cs553x: use the mtd instance embedded in struct nand_chip
struct nand_chip now embeds an mtd device. Make use of this mtd instance.
Signed-off-by: Boris Brezillon
---
drivers/mtd/nand/cs553x_nand.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/cs553x_nand.c b/drivers/mtd/nand/cs553x_nand.c
index 8904d68..386ae83 100644
--- a/drivers/mtd/nand/cs553x_nand.c
+++ b/drivers/mtd/nand/cs553x_nand.c
@@ -197,14 +197,13 @@ static int __init cs553x_init_one(int cs, int mmio,
unsigned long adr)
}
/* Allocate memory for MTD device structure and private data */
- new_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip),
GFP_KERNEL);
- if (!new_mtd) {
+ this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
+ if (!this) {
err = -ENOMEM;
goto out;
}
- /* Get pointer to private data */
- this = (struct nand_chip *)(&new_mtd[1]);
+ new_mtd = nand_to_mtd(this);
/* Link the private data with the MTD structure */
new_mtd->priv = this;
@@ -257,7 +256,7 @@ out_free:
out_ior:
iounmap(this->IO_ADDR_R);
out_mtd:
- kfree(new_mtd);
+ kfree(this);
out:
return err;
}
@@ -337,19 +336,19 @@ static void __exit cs553x_cleanup(void)
if (!mtd)
continue;
- this = mtd_to_nand(cs553x_mtd[i]);
+ this = mtd_to_nand(mtd);
mmio_base = this->IO_ADDR_R;
/* Release resources, unregister device */
- nand_release(cs553x_mtd[i]);
- kfree(cs553x_mtd[i]->name);
+ nand_release(mtd);
+ kfree(mtd->name);
cs553x_mtd[i] = NULL;
/* unmap physical address */
iounmap(mmio_base);
/* Free the MTD device structure */
- kfree(mtd);
+ kfree(this);
}
}
--
2.1.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
