[PATCH v3 4/7] ARM: config: hisi: enable CONFIG_RESET_CONTROLLER
enable CONFIG_RESET_CONTROLLER in hisi_defconfig Signed-off-by: Jiancheng Xue --- arch/arm/configs/hisi_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig index b2e340b..ba62c07 100644 --- a/arch/arm/configs/hisi_defconfig +++ b/arch/arm/configs/hisi_defconfig @@ -75,6 +75,7 @@ CONFIG_DMADEVICES=y CONFIG_DW_DMAC=y CONFIG_PL330_DMA=y CONFIG_PWM=y +CONFIG_RESET_CONTROLLER=y CONFIG_PHY_HIX5HD2_SATA=y CONFIG_EXT4_FS=y CONFIG_TMPFS=y -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] ARM: hisi: add dt_machine definition for Hi3519
add dt_machine definition for hi3519.
Signed-off-by: Jiancheng Xue
---
arch/arm/mach-hisi/hisilicon.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-hisi/hisilicon.c b/arch/arm/mach-hisi/hisilicon.c
index 8cc6215..010d8a2 100644
--- a/arch/arm/mach-hisi/hisilicon.c
+++ b/arch/arm/mach-hisi/hisilicon.c
@@ -81,3 +81,12 @@ static const char *const hip01_compat[] __initconst = {
DT_MACHINE_START(HIP01, "Hisilicon HIP01 (Flattened Device Tree)")
.dt_compat = hip01_compat,
MACHINE_END
+
+static const char *const hi3519_compat[] __initconst = {
+ "hisilicon,hi3519",
+ NULL,
+};
+
+DT_MACHINE_START(HI3519_DT, "Hisilicon Hi3519")
+ .dt_compat = hi3519_compat,
+MACHINE_END
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 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 v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
On 10.12.2015 18:25, Bjorn Helgaas wrote: > On Thu, Dec 10, 2015 at 08:02:05AM +0100, Michal Simek wrote: >> Hi Bjorn, >> >> On 10.12.2015 00:19, Bjorn Helgaas wrote: >>> [+cc Michal, Paul, Thierry, Stephen, Alexandre (see irq_dispose_mapping >>> questions below)] >>> >>> On Sun, Nov 29, 2015 at 05:33:53PM +0530, Bharat Kumar Gogada wrote: Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP. Signed-off-by: Bharat Kumar Gogada Signed-off-by: Ravi Kiran Gummaluri Acked-by: Rob Herring >>> >>> This needs either a MAINTAINERS update or an ack from Michal (whose >>> MAINTAINERS entry matches anything containing "xilinx"). >> >> We have done it in this way because driver owners are changing time to >> time and my entry cover it that I can pass it to appropriate person who >> is responsible for it. >> >> For this Maintainers part here is my: >> Acked-by: Michal Simek > > Thanks. > > For things under drivers/pci/host, I ask for an ack from the > individual maintainer before applying patches. As-is (without a > MAINTAINERS update) I'll be looking for acks from you, Michal, for all > future changes to pcie-xilinx-nwl.c. If you want something else, we > need a MAINTAINERS change. ok. No problem with it. I will get HW pretty soon and I will be able to do some testing my self when some others changes come. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 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 devicetree" 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/5] memory: mediatek: Add SMI driver
On Tue, 2015-12-08 at 17:49 +0800, Yong Wu wrote: > This patch add SMI(Smart Multimedia Interface) driver. This driver > is responsible to enable/disable iommu and control the power domain > and clocks of each local arbiter. > > Signed-off-by: Yong Wu > --- Hi Matthias, Because drivers/memory/ don't have the maintainer, and our IOMMU, V4L2 and DRM rely on the SMI. From Joerg and Thierry[1], we need your help. Could you have a loot at our SMI while free? Look forward to any comment from you. Thanks. [1]http://lists.linuxfoundation.org/pipermail/iommu/2015-November/014981.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 devicetree" 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 devicetree" 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PICKME 0/2] cpufreq: New ST driver
On Fri, 11 Dec 2015, Viresh Kumar wrote: > On 10-12-15, 22:38, Rafael J. Wysocki wrote: > > Do they depend on anything special? > > My opp-binding-parsing patches which you applied to bleeding-edge. I thought these had already been applied. > Yes, Lee should have mentioned that explicitly. Aye, apologies for that. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/12] ARM: dts: imx6: add Vivante GPU nodes
On Fri, Dec 04, 2015 at 03:00:04PM +0100, Lucas Stach wrote:
> This adds the device nodes for 2D, 3D and VG GPU cores.
>
> Signed-off-by: Russell King
> Signed-off-by: Lucas Stach
> ---
> arch/arm/boot/dts/imx6dl.dtsi | 5 +
> arch/arm/boot/dts/imx6q.dtsi | 15 +++
> arch/arm/boot/dts/imx6qdl.dtsi | 22 ++
> 3 files changed, 42 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
> index 4b0ec0703825..51c517a5cafd 100644
> --- a/arch/arm/boot/dts/imx6dl.dtsi
> +++ b/arch/arm/boot/dts/imx6dl.dtsi
> @@ -104,6 +104,11 @@
> compatible = "fsl,imx-display-subsystem";
> ports = <&ipu1_di0>, <&ipu1_di1>;
> };
> +
> + gpu-subsystem {
> + compatible = "fsl,imx-gpu-subsystem";
> + cores = <&gpu_2d>, <&gpu_3d>;
> + };
> };
>
> &gpt {
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index 399103b8e2c9..77d618b2870c 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -153,6 +153,16 @@
> status = "disabled";
> };
>
> + gpu_vg: gpu@02204000 {
> + compatible = "vivante,gc";
> + reg = <0x02204000 0x4000>;
> + interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_OPENVG_AXI>,
> + <&clks IMX6QDL_CLK_GPU2D_CORE>;
> + clock-names = "bus", "core";
> + power-domains = <&gpc 1>;
Shouldn't property 'power-domains' be mentioned a bit in bindings doc?
> + };
> +
> ipu2: ipu@0280 {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -225,6 +235,11 @@
> compatible = "fsl,imx-display-subsystem";
> ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
> };
> +
> + gpu-subsystem {
> + compatible = "fsl,imx-gpu-subsystem";
> + cores = <&gpu_2d>, <&gpu_3d>, <&gpu_vg>;
> + };
> };
>
> &hdmi {
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 2b6cc8bf3c5c..018975b867e1 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -119,6 +119,28 @@
> status = "disabled";
> };
>
> +
> + gpu_2d: gpu@00134000 {
> + compatible = "vivante,gc";
> + reg = <0x00134000 0x4000>;
> + interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_GPU2D_AXI>,
> + <&clks IMX6QDL_CLK_GPU2D_CORE>;
> + clock-names = "bus", "core";
> + power-domains = <&gpc 1>;
> + };
> +
> + gpu_3d: gpu@0013 {
> + compatible = "vivante,gc";
> + reg = <0x0013 0x4000>;
> + interrupts = <0 9 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks IMX6QDL_CLK_GPU3D_AXI>,
> + <&clks IMX6QDL_CLK_GPU3D_CORE>,
> + <&clks IMX6QDL_CLK_GPU3D_SHADER>;
> + clock-names = "bus", "core", "shader";
> + power-domains = <&gpc 1>;
> + };
> +
Please keep these added nodes sorted in unit-address.
Shawn
> hdmi: hdmi@012 {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> 2.6.2
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 devicetree" 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 devicetree" 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 devicetree" 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 devicetree" 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 devicetree" 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 devicetree" 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 devicetree" 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] MAINTAINERS: Add missing platform maintainers for dts files
On Thu, Dec 10, 2015 at 05:38:23PM -0600, Rob Herring wrote: > Platform dts files need to be reviewed primarily by the platform > maintainers as dts files typically go in thru their trees. Add the missing > paths where there are existing maintainers listed. > > Signed-off-by: Rob Herring > --- > ARM/Marvell Dove/MV78xx0/Orion SOC support > @@ -1406,7 +1415,9 @@ M: David Brown > L: linux-arm-...@vger.kernel.org > L: linux-...@vger.kernel.org > S: Maintained > +F: arch/arm/boot/dts/qcom-* > F: arch/arm/mach-qcom/ > +F: arch/arm64/boot/dts/qcom/* > F: drivers/soc/qcom/ > F: drivers/tty/serial/msm_serial.h > F: drivers/tty/serial/msm_serial.c for QCOM, Acked-by: Andy Gross -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v4 2/2] arm: dts: Add APQ8084 SMEM nodes
From: Andy Gross
This patch adds all the required nodes to support SMEM on APQ8084
Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index fcffeca..3d3b394 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -10,6 +10,17 @@
compatible = "qcom,apq8084";
interrupt-parent = <&intc>;
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ smem_mem: smem_region@fa0 {
+ reg = <0xfa0 0x20>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -89,6 +100,15 @@
clock-frequency = <1920>;
};
+ smem {
+ compatible = "qcom,smem";
+
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+ memory-region = <&smem_mem>;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -225,6 +245,22 @@
reg = <0xfc40 0x4000>;
};
+ tcsr_mutex_regs: syscon@fd484000 {
+ compatible = "syscon";
+ reg = <0xfd484000 0x2000>;
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x80>;
+ #hwlock-cells = <1>;
+ };
+
+ rpm_msg_ram: memory@fc428000 {
+ compatible = "qcom,rpm-msg-ram";
+ reg = <0xfc428000 0x4000>;
+ };
+
tlmm: pinctrl@fd51 {
compatible = "qcom,apq8084-pinctrl";
reg = <0xfd51 0x4000>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v4 0/2] Add SMEM nodes for APQ8084 and MSM8916
This patch set adds the SMEM nodes for the APQ8084 and MSM8916 platforms. These patches were originally part of: https://lkml.org/lkml/headers/2015/9/24/561 I split these two patches out because these were the only DTS patches that required modifications. The rest have been accepted. I continued to add the previous change log for continuity sake. Changes since v3: - Moved smem node outside of soc and fixed up the rpm-msg-ram Changes since v2: - Fixed some missed review comments - Corrected the SMD RPM example binding indentation Changes since v1: - Fixed various review comments - Removed MSM8974 patches as there was already an outstanding patch Andy Gross (2): arm64: dts: qcom: Add MSM8916 SMEM nodes arm: dts: Add APQ8084 SMEM nodes arch/arm/boot/dts/qcom-apq8084.dtsi | 36 ++ arch/arm64/boot/dts/qcom/msm8916.dtsi | 41 +++ 2 files changed, 77 insertions(+) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch v4 1/2] arm64: dts: qcom: Add MSM8916 SMEM nodes
From: Andy Gross
This patch adds the nodes necessary to support the SMEM driver on MSM8916
platforms.
Signed-off-by: Andy Gross
Acked-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 41 +++
1 file changed, 41 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 8d184ff..fe4541f 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -37,6 +37,22 @@
reg = <0 0 0 0>;
};
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ reserve_aligned@8600 {
+ reg = <0x0 0x8600 0x0 0x030>;
+ no-map;
+ };
+
+ smem_mem: smem_region@8630 {
+ reg = <0x0 0x8630 0x0 0x010>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -74,6 +90,15 @@
;
};
+ smem {
+ compatible = "qcom,smem";
+
+ memory-region = <&smem_mem>;
+ qcom,rpm-msg-ram = <&rpm_msg_ram>;
+
+ hwlocks = <&tcsr_mutex 3>;
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -103,6 +128,22 @@
reg = <0x180 0x8>;
};
+ tcsr_mutex_regs: syscon@1905000 {
+ compatible = "syscon";
+ reg = <0x1905000 0x2>;
+ };
+
+ tcsr_mutex: hwlock {
+ compatible = "qcom,tcsr-mutex";
+ syscon = <&tcsr_mutex_regs 0 0x1000>;
+ #hwlock-cells = <1>;
+ };
+
+ rpm_msg_ram: memory@6 {
+ compatible = "qcom,rpm-msg-ram";
+ reg = <0x6 0x8000>;
+ };
+
blsp1_uart1: serial@78af000 {
compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
reg = <0x78af000 0x200>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files
Rob Herring writes: > Platform dts files need to be reviewed primarily by the platform > maintainers as dts files typically go in thru their trees. Add the missing > paths where there are existing maintainers listed. > > Signed-off-by: Rob Herring > --- > MAINTAINERS | 20 +++- ... > @@ -8627,6 +8642,7 @@ L: linux-arm-ker...@lists.infradead.org (moderated > for non-subscribers) > T: git git://github.com/hzhuang1/linux.git > T: git git://github.com/rjarzmik/linux.git > S: Maintained > +F: arch/arm/boot/dts/pxa* > F: arch/arm/mach-pxa/ > F: drivers/dma/pxa* > F: drivers/pcmcia/pxa2xx* Acked-by: Robert Jarzmik Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
> Subject: Re: [PATCH v11] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL
> PCIe Host Controller
>
> [+cc Marc for irq_dispose_mapping() question]
>
> On Thu, Dec 10, 2015 at 02:10:34PM +, Bharat Kumar Gogada wrote:
> I'm trying to figure out what the difference is between these two checks and
> why you have both of them:
>
> > + if (bus->number == pcie->root_busno && devfn > 0)
> > + if (bus->primary == pcie->root_busno && devfn > 0)
>
> If I understand correctly, pcie->root_busno is the bus number of the Root
> Port device (likely 00). I think the "bus->number ==
> pcie->root_busno && devfn > 0" check means that the Root Port, e.g.,
> 00:00.0, is the only device allowed on bus 00. Often a Root Complex contains
> several Root Ports and other integrated devices that typically are on bus 00.
> But in your case, I think you're saying there is only the single Root Port
> and no
> other devices.
>
> I think that first check takes care of everything on bus 00, so I'm trying to
> figure out what the second check is for. Assume your Root Port is device
> 00:00.0 and it is a bridge to [bus 01-ff]. Then we have two pci_bus structs
> with these values:
>
> bus->number = 00
> bus->primary = 00
> bus->busn_res = [bus 00-ff]
>
> bus->number = 01
> bus->primary = 00
> bus->busn_res = [bus 01-ff]
>
> Because of the first check, 00:00.0 is the only possible device on bus 00, and
> because of the second check, 01:00.0 is the only possible device on bus 01.
> Therefore, you don't support a multifunction device connected to the Root
> Port. Right?
>
We support multifunction devices also, so this check should not be there, will
remove this check in next patch.
> > > > + return false;
> > > > +
> > > > + return true;
> > > > +}
> > > > + * nwl_setup_sspl - Set Slot Power limit
> > > > + *
> > > > + * @pcie: PCIe port information
> > > > + */
> > > > +static int nwl_setup_sspl(struct nwl_pcie *pcie)
> > >
> > The Set_Slot_Power_Limit Message includes a one DW data payload. The
> > data payload is copied from the Slot Capabilities register of the
> > Downstream Port and is written into the Device Capabilities register
> > of the Upstream Port on the other side of the Link. Bits 9:8 of the
> > data payload map to the Slot Power Limit Scale field and bits 7:0 map
> > to the Slot Power Limit Value field. Bits 31:10 of the data payload
> > must be set to all 0's by the Transmitter and ignored by the Receiver.
>
> > This Message is sent automatically by the Downstream Port (of a Root
> > Complex or a Switch) when one of the following events occurs:
> > -> On a Configuration Write to the Slot Capabilities register (see
> > Section 7.8.9) when the Data Link Layer reports DL_Up status.
>
> I interpret this as meaning "the *hardware* automatically sends a
> Set_Slot_Power_Limit Message." There's no mention of software doing
> anything other than the configuration write.
>
> If your hardware doesn't do that, I think it's a defect. It's fine to work
> around
> it, but we should have a comment to that effect so people don't copy the
> code to new drivers that don't need it.
Our hardware is not capable of doing it, so we are doing it software. Yes I
will add some comments.
>
> It's a little strange that 7.8.9 talks about writing to this register when
> all of its
> fields are HwInit and supposedly read-only. I had assumed devices would
> use strapping or implementation-specific registers to set the Slot Power
> values, but maybe some devices use direct writes to Slot Capabilities instead.
>
> BTW, I noticed a related lspci bug: it didn't decode the Capture Slot Power
> Limit in Device Capabilities of Endpoints. I posted a fix for that
> separately.
>
> The Slot Power Limit (in Slot Capabilities) indicates how much power the slot
> can supply to a downstream device. That's a function of the platform design,
> so it seems like this is something you want to set via DT or some other
> mechanism that knows about the platform.
> Intercepting all config writes and updating it with whatever the caller
> supplies
> doesn't sound wise. The value might be coming from setpci or some other
> source with no knowledge of the platform.
Agreed, but this is what can be done, it is difficult to determine who does
what.
>
> > > > + status = nwl_bridge_readl(pcie, TX_PCIE_MSG)
> > > > + & MSG_DONE_BIT;
> > > > + if (status) {
> > > > + status = nwl_bridge_readl(pcie,
> > > TX_PCIE_MSG)
> > > > + & MSG_DONE_STATUS_BIT;
>
> > > It's not clear to me whether you need to re-read TX_PCIE_MSG here.
> >
> > MSG_DONE_BIT qualifies MSG_DONE_STATUS_BIT; so value of
> > MSG_DONE_STATUS_BIT is valid only when MSG_DONE_BIT = 1
>
> That doesn't answer the question of whether another read is required.
> In fact, I would argue
Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
On Fri, 11 Dec 2015 09:35:10 +0530 Pratyush Anand wrote: > On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux wrote: > > [...] > > >> > > dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2); > >> > > + /* > >> > > + * ensure that the ATU enable has been happaned before accessing > >> > > + * pci configuration/io spaces through dw_pcie_cfg_[read|write]. > >> > > + */ > >> > > + wmb(); > >> > > } > >> > > > >> > >> > >> My understnading is that since writel() of dw_pcie_writel_rc() in > >> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which > >> will follow) goes through same device (ie PCIe host here). So, it is > >> guaranteed that 1st writel() will be executed before later > >> readl()/writel(). If that is true then we do not need any explicit > >> barrier here. > >> > >> Arnd, Russel: whats your opinion here. > > ^l > > Sorry :( > > > > > writel() has a barrier _before_ the access but not after. > > > > The fact is that there's nothing which guarantees that the write will hit > > the hardware in a timely manner (forget any rules about PCI config space, > > the PCI ordering rules apply to the PCI bus, not to the ARM buses.) > > > > If you need this write to have hit the hardware before continuing, you > > need to read back from the same register. > > OK, so better to replace wmb() with read back of control register. > > > > > I'm just looking at this driver, trying to decipher what it's doing. It > > _looks_ to me like it's reprogramming one of the outbound windows (IO?) > > so that configuration space can be accessed. Doesn't this have the > > effect of disabling access to the IO segment of the PCI bus from the > > host CPU? > > > > What protections are there against other CPUs in the system issuing a > > PCI I/O read/write while this outbound window is programmed as > > configuration space? > > > Yes, that is an issue with this driver. Most of the host controller > has 4 or more viewpoints, and it is very easy to handle for them. But > there are few which has only two viewpoints. Do not know how to solve > it, so that it works for all. > The default outbound iATU number is two, this may be the reason why the driver is written in current style. And two outbound iATUs may be common for pcie dw users because ASIC people just follow the default configuration ;). In our case, Marvell Berlin SoCs have two outbound iATUs. Thanks, Jisheng -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v9 10/60] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource, so set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241 Signed-off-by: Yinghai Lu Cc: Grant Likely Cc: Rob Herring Cc: devicetree@vger.kernel.org Tested-by: Khalid Aziz --- drivers/of/address.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/of/address.c b/drivers/of/address.c index 9582c57..95c39c8 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -128,9 +128,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr) flags |= IORESOURCE_IO; break; case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 {
[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 devicetree" 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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 devicetree" 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 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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[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 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 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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-...@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 devicetree" 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 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 devicetree" 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 devicetree" 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 devicetree" 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 devicetree" 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 devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/4] ARM: bcm2835: rename sdhci pin group
On 12/05/2015 02:43 AM, Stefan Wahren wrote:
>
>> Stephen Warren hat am 2. Dezember 2015 um 04:42
>> geschrieben:
>>
>>
>> On 11/19/2015 09:06 AM, Stefan Wahren wrote:
>>> The node name of the sdhci pin group doesn't explain it's
>>> real function. So rename it.
>>
>> The real function of this node is not to configure SDHCI pins, but to
>> set pins to alt3, as the current name states. Admittedly it's possible
>> that currently the only pins that need to be set to ALT3 are SDHCI
>> related, but that's incidental.
>
> Yes, i understand the original intension to assign every pin to the available
> mux functions ( gpio_in, gpio_out, alt* ).
>
> But 3f37169fb3 ("ARM: bcm2835: dt: Add Raspberry Pi Model B rev2") introduce a
FYI I don't have that yet and git fetch is being very slow right now:-(
> better self-describing pin group naming for I2S. So my idea was to adapt it
> according to sdhci first and go on.
OK. I'd suggest explaining that directly in the commit description then.
The commit description above has a quite different semantic meaning.
> So here is a possible vision for bcm2835-rpi.dtsi
>
> &gpio {
> pinctrl-names = "default";
>
> act_gpio: gpio {
> brcm,pins = <6>;
> brcm,function = ;
> };
>
> i2c0_alt0: i2c {
> brcm,pins = <0 1>;
> brcm,function = ;
> };
>
> i2c1_alt0: i2c {
> brcm,pins = <2 3>;
> brcm,function = ;
> };
...
OK, I guess that can work; I imagine it would make DT overlays easier by
making the pinctrl setup more fine-grained.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/4] ARM: bcm2835: remove sdhci pins from GPIO pinctrl
On 12/05/2015 02:12 AM, Stefan Wahren wrote:
>
>> Stephen Warren hat am 2. Dezember 2015 um 04:40
>> geschrieben:
>>
>>
>> On 11/19/2015 09:06 AM, Stefan Wahren wrote:
>>> Currently the pins alt3 (sdhci) are assigned to GPIO pinctrl.
>>> This is bad because a user could export it to sysfs and break
>>> sdhci. In order to avoid that remove those pins from GPIO pintrl.
>>
>>> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>>> b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
>>
>>> &gpio {
>>> - pinctrl-0 = <&gpioout &alt0 &i2s_alt0 &alt3>;
>>> + pinctrl-0 = <&gpioout &alt0 &i2s_alt0>;
>>
>> This doesn't make sense. The current DT content is configuring those
>> pins as SDHCI, not as GPIO. Admitedly this is redundant since the
>> firmware and/or bootloader already did this in order to boot the system,
>> but irrespective, the current DT causes no issues. Removing the pinctrl
>> setting should not influence whether the pins can be exported via GPIO
>> sysfs either.
>
> You are right.
>
> Is it generally possible to avoid the GPIO sysfs export for SDHCI pins?
> Is it an issue of pinctrl-bcm2835?
I believe this same issue exists on all platforms where GPIO pins can be
mux'd onto the same pins as other functions.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 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 v5 0/5] Add memory mapped read support for ti-qspi
Changes since v4: Use syscon to access system control module register in ti-qspi driver. Changes since v3: Rework to introduce spi_flash_read_message struct. Support different opcode/addr/data formats as per Brian's suggestion here: https://lkml.org/lkml/2015/11/11/454 Changes since v2: Remove mmap_lock_mutex. Optimize enable/disable of mmap mode. Changes since v1: Introduce API in SPI core that MTD flash driver can call for mmap read instead of directly calling spi-master driver callback. This API makes sure that SPI core msg queue is locked during mmap transfers. v1: https://lkml.org/lkml/2015/9/4/103 Cover letter: This patch series adds support for memory mapped read port of ti-qspi. ti-qspi has a special memory mapped port through which SPI flash memories can be accessed directly via SoC specific memory region. First patch adds a method to pass flash specific information like read opcode, dummy bytes etc and to request mmap read. Second patch implements mmap read method in ti-qspi driver. Patch 3 adapts m25p80 to use mmap read method before trying normal SPI transfer. Patch 4 and 5 add memory map region DT entries for DRA7xx and AM43xx SoCs. This patch series is based on the discussions here: http://www.spinics.net/lists/linux-spi/msg04796.html Tested on DRA74 EVM and AM437x-SK. Read performance increases from ~100kB/s to ~2.5MB/s. Vignesh R (5): spi: introduce accelerated read support for spi flash devices spi: spi-ti-qspi: add mmap mode read support mtd: devices: m25p80: add support for mmap read request ARM: dts: DRA7: add entry for qspi mmap region ARM: dts: AM4372: add entry for qspi mmap region Documentation/devicetree/bindings/spi/ti_qspi.txt | 22 +++- arch/arm/boot/dts/am4372.dtsi | 4 +- arch/arm/boot/dts/dra7.dtsi | 6 +- drivers/mtd/devices/m25p80.c | 20 drivers/spi/spi-ti-qspi.c | 139 +- drivers/spi/spi.c | 45 +++ include/linux/spi/spi.h | 41 +++ 7 files changed, 243 insertions(+), 34 deletions(-) -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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/5] spi: introduce accelerated read support for spi flash devices
In addition to providing direct access to SPI bus, some spi controller
hardwares (like ti-qspi) provide special port (like memory mapped port)
that are optimized to improve SPI flash read performance.
This means the controller can automatically send the SPI signals
required to read data from the SPI flash device.
For this, SPI controller needs to know flash specific information like
read command to use, dummy bytes and address width.
Introduce spi_flash_read() interface to support accelerated read
over SPI flash devices. SPI master drivers can implement this callback to
support interfaces such as memory mapped read etc. m25p80 flash driver
and other flash drivers can call this make use of such interfaces. The
interface should only be used with SPI flashes and cannot be used with
other SPI devices.
Signed-off-by: Vignesh R
---
v5: No changes.
drivers/spi/spi.c | 45 +
include/linux/spi/spi.h | 41 +
2 files changed, 86 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index e2415be209d5..cc2b54139352 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1134,6 +1134,7 @@ static void __spi_pump_messages(struct spi_master
*master, bool in_kthread)
}
}
+ mutex_lock(&master->bus_lock_mutex);
trace_spi_message_start(master->cur_msg);
if (master->prepare_message) {
@@ -1143,6 +1144,7 @@ static void __spi_pump_messages(struct spi_master
*master, bool in_kthread)
"failed to prepare message: %d\n", ret);
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+ mutex_unlock(&master->bus_lock_mutex);
return;
}
master->cur_msg_prepared = true;
@@ -1152,6 +1154,7 @@ static void __spi_pump_messages(struct spi_master
*master, bool in_kthread)
if (ret) {
master->cur_msg->status = ret;
spi_finalize_current_message(master);
+ mutex_unlock(&master->bus_lock_mutex);
return;
}
@@ -1159,8 +1162,10 @@ static void __spi_pump_messages(struct spi_master
*master, bool in_kthread)
if (ret) {
dev_err(&master->dev,
"failed to transfer one message from queue\n");
+ mutex_unlock(&master->bus_lock_mutex);
return;
}
+ mutex_unlock(&master->bus_lock_mutex);
}
/**
@@ -2327,6 +2332,46 @@ int spi_async_locked(struct spi_device *spi, struct
spi_message *message)
EXPORT_SYMBOL_GPL(spi_async_locked);
+int spi_flash_read(struct spi_device *spi,
+ struct spi_flash_read_message *msg)
+
+{
+ struct spi_master *master = spi->master;
+ int ret;
+
+ if ((msg->opcode_nbits == SPI_NBITS_DUAL ||
+msg->addr_nbits == SPI_NBITS_DUAL) &&
+ !(spi->mode & (SPI_TX_DUAL | SPI_TX_QUAD)))
+ return -EINVAL;
+ if ((msg->opcode_nbits == SPI_NBITS_QUAD ||
+msg->addr_nbits == SPI_NBITS_QUAD) &&
+ !(spi->mode & SPI_TX_QUAD))
+ return -EINVAL;
+ if (msg->data_nbits == SPI_NBITS_DUAL &&
+ !(spi->mode & (SPI_RX_DUAL | SPI_RX_QUAD)))
+ return -EINVAL;
+ if (msg->data_nbits == SPI_NBITS_QUAD &&
+ !(spi->mode & SPI_RX_QUAD))
+ return -EINVAL;
+
+ if (master->auto_runtime_pm) {
+ ret = pm_runtime_get_sync(master->dev.parent);
+ if (ret < 0) {
+ dev_err(&master->dev, "Failed to power device: %d\n",
+ ret);
+ return ret;
+ }
+ }
+ mutex_lock(&master->bus_lock_mutex);
+ ret = master->spi_flash_read(spi, msg);
+ mutex_unlock(&master->bus_lock_mutex);
+ if (master->auto_runtime_pm)
+ pm_runtime_put(master->dev.parent);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(spi_flash_read);
+
/*-*/
/* Utility methods for SPI master protocol drivers, layered on
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index cce80e6dc7d1..246d7d519f3f 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -25,6 +25,7 @@
struct dma_chan;
struct spi_master;
struct spi_transfer;
+struct spi_flash_read_message;
/*
* INTERFACES between SPI master-side drivers and SPI infrastructure.
@@ -361,6 +362,8 @@ static inline void spi_unregister_driver(struct spi_driver
*sdrv)
* @handle_err: the subsystem calls the driver to handle an error that occurs
* in the generic implementation of transfer_one_message().
* @unprepare_message: undo any work done by prepare_message().
+ * @spi_flash_read: to support spi-controller hardwares that provide
+ *
[PATCH v5 3/5] mtd: devices: m25p80: add support for mmap read request
Certain spi controllers may provide accelerated interface to read from
m25p80 type flash devices. This interface provides better read
performance than regular SPI interface.
Call spi_flash_read(), if supported, to make use of such interface.
Signed-off-by: Vignesh R
---
v5: No changes
drivers/mtd/devices/m25p80.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index fe9ceb7b5405..00094a668c62 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t from,
size_t len,
/* convert the dummy cycles to the number of bytes */
dummy /= 8;
+ if (spi_flash_read_supported(spi)) {
+ struct spi_flash_read_message msg;
+ int ret;
+
+ msg.buf = buf;
+ msg.from = from;
+ msg.len = len;
+ msg.read_opcode = nor->read_opcode;
+ msg.addr_width = nor->addr_width;
+ msg.dummy_bytes = dummy;
+ /* TODO: Support other combinations */
+ msg.opcode_nbits = SPI_NBITS_SINGLE;
+ msg.addr_nbits = SPI_NBITS_SINGLE;
+ msg.data_nbits = m25p80_rx_nbits(nor);
+
+ ret = spi_flash_read(spi, &msg);
+ *retlen = msg.retlen;
+ return ret;
+ }
+
spi_message_init(&m);
memset(t, 0, (sizeof t));
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/5] ARM: dts: AM4372: add entry for qspi mmap region
Add qspi memory mapped region entries for AM43xx based SoCs. Also,
update the binding documents for the controller to document this change.
Acked-by: Rob Herring
Signed-off-by: Vignesh R
---
v5: No changes.
Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
arch/arm/boot/dts/am4372.dtsi | 4 +++-
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 809c3f334316..cc8304aa64ac 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -21,9 +21,10 @@ Optional properties:
Example:
+For am4372:
qspi: qspi@4b30 {
- compatible = "ti,dra7xxx-qspi";
- reg = <0x4790 0x100>, <0x3000 0x3ff>;
+ compatible = "ti,am4372-qspi";
+ reg = <0x4790 0x100>, <0x3000 0x400>;
reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c9701e..e32d164102d1 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -963,7 +963,9 @@
qspi: qspi@4790 {
compatible = "ti,am4372-qspi";
- reg = <0x4790 0x100>;
+ reg = <0x4790 0x100>,
+ <0x3000 0x400>;
+ reg-names = "qspi_base", "qspi_mmap";
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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/5] ARM: dts: DRA7: add entry for qspi mmap region
Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
update the binding documents for the controller to document this change.
Signed-off-by: Vignesh R
---
v5: use syscon to access scm register.
Documentation/devicetree/bindings/spi/ti_qspi.txt | 17 +
arch/arm/boot/dts/dra7.dtsi | 6 --
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 601a360531a5..809c3f334316 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -15,6 +15,10 @@ Recommended properties:
- spi-max-frequency: Definition as per
Documentation/devicetree/bindings/spi/spi-bus.txt
+Optional properties:
+- syscon-chipselects: Handle to system control region contains QSPI
+ chipselect register and offset of that register.
+
Example:
qspi: qspi@4b30 {
@@ -26,3 +30,16 @@ qspi: qspi@4b30 {
spi-max-frequency = <2500>;
ti,hwmods = "qspi";
};
+
+For dra7xx:
+qspi: qspi@4b30 {
+ compatible = "ti,dra7xxx-qspi";
+ reg = <0x4b30 0x100>,
+ <0x5c00 0x400>,
+ reg-names = "qspi_base", "qspi_mmap";
+ syscon-chipselects = <&scm_conf 0x558>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ spi-max-frequency = <4800>;
+ ti,hwmods = "qspi";
+};
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index fe99231cbde5..be91c7781c07 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1153,8 +1153,10 @@
qspi: qspi@4b30 {
compatible = "ti,dra7xxx-qspi";
- reg = <0x4b30 0x100>;
- reg-names = "qspi_base";
+ reg = <0x4b30 0x100>,
+ <0x5c00 0x400>;
+ reg-names = "qspi_base", "qspi_mmap";
+ syscon-chipselects = <&scm_conf 0x558>;
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "qspi";
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/5] spi: spi-ti-qspi: add mmap mode read support
ti-qspi controller provides mmap port to read data from SPI flashes.
mmap port is enabled in QSPI_SPI_SWITCH_REG. ctrl module register may
also need to be accessed for some SoCs. The QSPI_SPI_SETUP_REGx needs to
be populated with flash specific information like read opcode, read
mode(quad, dual, normal), address width and dummy bytes. Once,
controller is in mmap mode, the whole flash memory is available as a
memory region at SoC specific address. This region can be accessed using
normal memcpy() (or mem-to-mem dma copy). The ti-qspi controller hardware
will internally communicate with SPI flash over SPI bus and get the
requested data.
Implement spi_flash_read() callback to support mmap read over SPI
flash devices. With this, the read throughput increases from ~100kB/s to
~2.5 MB/s.
Signed-off-by: Vignesh R
---
v5:
* use syscon to access ctrl_mod register.
drivers/spi/spi-ti-qspi.c | 139 --
1 file changed, 110 insertions(+), 29 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 64318fcfacf2..eac3c960b2de 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -31,6 +31,8 @@
#include
#include
#include
+#include
+#include
#include
@@ -44,8 +46,9 @@ struct ti_qspi {
struct spi_master *master;
void __iomem*base;
- void __iomem*ctrl_base;
void __iomem*mmap_base;
+ struct regmap *ctrl_base;
+ unsigned intctrl_reg;
struct clk *fclk;
struct device *dev;
@@ -55,7 +58,7 @@ struct ti_qspi {
u32 cmd;
u32 dc;
- bool ctrl_mod;
+ bool mmap_enabled;
};
#define QSPI_PID (0x0)
@@ -65,11 +68,8 @@ struct ti_qspi {
#define QSPI_SPI_CMD_REG (0x48)
#define QSPI_SPI_STATUS_REG(0x4c)
#define QSPI_SPI_DATA_REG (0x50)
-#define QSPI_SPI_SETUP0_REG(0x54)
+#define QSPI_SPI_SETUP_REG(n) ((0x54 + 4 * n))
#define QSPI_SPI_SWITCH_REG(0x64)
-#define QSPI_SPI_SETUP1_REG(0x58)
-#define QSPI_SPI_SETUP2_REG(0x5c)
-#define QSPI_SPI_SETUP3_REG(0x60)
#define QSPI_SPI_DATA_REG_1(0x68)
#define QSPI_SPI_DATA_REG_2(0x6c)
#define QSPI_SPI_DATA_REG_3(0x70)
@@ -109,6 +109,17 @@ struct ti_qspi {
#define QSPI_AUTOSUSPEND_TIMEOUT 2000
+#define MEM_CS_EN(n) ((n + 1) << 8)
+#define MEM_CS_MASK(7 << 8)
+
+#define MM_SWITCH 0x1
+
+#define QSPI_SETUP_RD_NORMAL (0x0 << 12)
+#define QSPI_SETUP_RD_DUAL (0x1 << 12)
+#define QSPI_SETUP_RD_QUAD (0x3 << 12)
+#define QSPI_SETUP_ADDR_SHIFT 8
+#define QSPI_SETUP_DUMMY_SHIFT 10
+
static inline unsigned long ti_qspi_read(struct ti_qspi *qspi,
unsigned long reg)
{
@@ -366,6 +377,72 @@ static int qspi_transfer_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
return 0;
}
+static void ti_qspi_enable_memory_map(struct spi_device *spi)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+
+ ti_qspi_write(qspi, MM_SWITCH, QSPI_SPI_SWITCH_REG);
+ if (qspi->ctrl_base) {
+ regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+ MEM_CS_EN(spi->chip_select),
+ MEM_CS_MASK);
+ }
+ qspi->mmap_enabled = true;
+}
+
+static void ti_qspi_disable_memory_map(struct spi_device *spi)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+
+ ti_qspi_write(qspi, 0, QSPI_SPI_SWITCH_REG);
+ if (qspi->ctrl_base)
+ regmap_update_bits(qspi->ctrl_base, qspi->ctrl_reg,
+ 0, MEM_CS_MASK);
+ qspi->mmap_enabled = false;
+}
+
+static void ti_qspi_setup_mmap_read(struct spi_device *spi,
+ struct spi_flash_read_message *msg)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+ u32 memval = msg->read_opcode;
+
+ switch (msg->data_nbits) {
+ case SPI_NBITS_QUAD:
+ memval |= QSPI_SETUP_RD_QUAD;
+ break;
+ case SPI_NBITS_DUAL:
+ memval |= QSPI_SETUP_RD_DUAL;
+ break;
+ default:
+ memval |= QSPI_SETUP_RD_NORMAL;
+ break;
+ }
+ memval |= ((msg->addr_width - 1) << QSPI_SETUP_ADDR_SHIFT |
+ msg->dummy_bytes << QSPI_SETUP_DUMMY_SHIFT);
+ ti_qspi_write(qspi, memval,
+ QSPI_SPI_SETUP_REG(spi->chip_select));
+}
+
+static int ti_qspi_spi_flash_read(struct spi_device *spi,
+ struct spi_flash_read_message *msg)
+{
+ struct ti_qspi *qspi = spi_master_get_devdata(spi->master);
+ int ret = 0;
+
+
Re: [PATCH resend 2/6] clk: sunxi: Add VE (Video Engine) module clock driver for sun[457]i
On Tue, Dec 8, 2015 at 6:02 PM, Maxime Ripard
wrote:
> Hi,
>
> On Sat, Dec 05, 2015 at 09:16:43PM +0800, Chen-Yu Tsai wrote:
>> The video engine has its own special module clock, consisting of a clock
>> gate, configurable dividers, and a reset control.
>>
>> On later (sun[68]i) families, the reset control is moved out of this
>> piece of hardware and grouped with reset controls of other peripherals.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> Documentation/devicetree/bindings/clock/sunxi.txt | 4 +
>> drivers/clk/sunxi/Makefile| 1 +
>> drivers/clk/sunxi/clk-a10-ve.c| 171
>> ++
>> 3 files changed, 176 insertions(+)
>> create mode 100644 drivers/clk/sunxi/clk-a10-ve.c
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
>> b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index ef0b452806b1..14496056319f 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -74,6 +74,7 @@ Required properties:
>> "allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
>> "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>> "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>> + "allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
>>
>> Required properties for all clocks:
>> - reg : shall be the control register address for the clock.
>> @@ -93,6 +94,9 @@ Required properties for all clocks:
>> And "allwinner,*-usb-clk" clocks also require:
>> - reset-cells : shall be set to 1
>>
>> +The "allwinner,sun4i-a10-ve-clk" clock also requires:
>> +- reset-cells : shall be set to 0
>> +
>> The "allwinner,sun9i-a80-mmc-config-clk" clock also requires:
>> - #reset-cells : shall be set to 1
>> - resets : shall be the reset control phandle for the mmc block.
>> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
>> index 103efab05ca8..78db91ad5af6 100644
>> --- a/drivers/clk/sunxi/Makefile
>> +++ b/drivers/clk/sunxi/Makefile
>> @@ -7,6 +7,7 @@ obj-y += clk-a10-codec.o
>> obj-y += clk-a10-hosc.o
>> obj-y += clk-a10-mod1.o
>> obj-y += clk-a10-pll2.o
>> +obj-y += clk-a10-ve.o
>> obj-y += clk-a20-gmac.o
>> obj-y += clk-mod0.o
>> obj-y += clk-simple-gates.o
>> diff --git a/drivers/clk/sunxi/clk-a10-ve.c b/drivers/clk/sunxi/clk-a10-ve.c
>> new file mode 100644
>> index ..de0fdb656150
>> --- /dev/null
>> +++ b/drivers/clk/sunxi/clk-a10-ve.c
>> @@ -0,0 +1,171 @@
>> +/*
>> + * Copyright 2015 Chen-Yu Tsai
>> + *
>> + * Chen-Yu Tsai
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static DEFINE_SPINLOCK(ve_lock);
>> +
>> +#define SUN4I_VE_ENABLE 31
>> +#define SUN4I_VE_DIVIDER_SHIFT 16
>> +#define SUN4I_VE_DIVIDER_WIDTH 3
>> +#define SUN4I_VE_RESET 0
>> +
>> +/**
>> + * sunxi_ve_reset... - reset bit in ve clk registers handling
>> + */
>> +
>> +struct ve_reset_data {
>> + void __iomem*reg;
>> + spinlock_t *lock;
>> + struct reset_controller_dev rcdev;
>> +};
>> +
>> +static int sunxi_ve_reset_assert(struct reset_controller_dev *rcdev,
>> + unsigned long id)
>> +{
>> + struct ve_reset_data *data = container_of(rcdev,
>> + struct ve_reset_data,
>> + rcdev);
>> + unsigned long flags;
>> + u32 reg;
>> +
>> + spin_lock_irqsave(data->lock, flags);
>> +
>> + reg = readl(data->reg);
>> + writel(reg & ~BIT(SUN4I_VE_RESET), data->reg);
>> +
>> + spin_unlock_irqrestore(data->lock, flags);
>> +
>> + return 0;
>> +}
>> +
>> +static int sunxi_ve_reset_deassert(struct reset_controller_dev *rcdev,
>> +unsigned long id)
>> +{
>> + struct ve_reset_data *data = container_of(rcdev,
>> + struct ve_reset_data,
>> + rcdev);
>> + unsigned long flags;
>> + u32 reg;
>> +
>> + spin_lock_irqsave(data->lock, flags);
>> +
>> + reg = readl(data->reg);
>> + writel(reg | BIT(SUN4I_VE_RESET), data->reg);
>> +
>> + spin_unlock_irqrestore(data->lock, flags);
>> +
>> + return 0;
>> +}
>
> Is it me, or do we have this code
Re: [PATCH 2/3] ARM: dts: sun7i: Olimex A20-SOM-EVB: Enable mmc3 (baseboard SD socket)
On Fri, Dec 11, 2015 at 4:32 AM, Karsten Merker wrote: > The Olimex A20-SOM-EVB is an evaluation board for the Olimex > A20-SOM system-on-module. The baseboard provides a full-size SD > socket (connected to mmc3) in addition to the micro-SD socket on > the SOM itself (which is connected to mmc0). > > Enable the mmc3 controller in the dts. > > Signed-off-by: Karsten Merker Acked-by: Chen-Yu Tsai -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: sun7i: Olimex A20-SOM-EVB: Add LRADC keys
On Fri, Dec 11, 2015 at 4:31 AM, Karsten Merker wrote: > The Olimex A20-SOM-EVB is an evaluation board for the Olimex > A20-SOM system-on-module. It provides a set of android-style > buttons (labeled "VOL+", "VOL-", "MENU", "SEARCH", "HOME", "ESC" > and "ENTER") which are connected to a low-resolution ADC via a > resistor network. > > This patch adds appropriate button definitions to the board > dts. The voltages assigned to the keys are specified in the > board schematics published by the manufacturer. > > Signed-off-by: Karsten Merker Acked-by: Chen-Yu Tsai -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon-usb-gpio: add enable pin support
Hi Sergei,
On 2015년 12월 11일 08:07, Sergei Shtylyov wrote:
> Sometimes there's a real OTG chip behind the USB ID signal mapped to a GPIO
> pin: in my case it's Maxim Integrated MAX3355E which integrates Vbus charge
> pump and comparators and passes thru the ID signal from an OTG connector.
s/thru/through ?
> This chip also has the SHDN# pin which should be driven high for the normal
> operation and low to save power; it is connected to a GPIO pin as well on,
> hence we'll have to teach the driver to parse the new optional device tree
> property, "enable-gpio"...
This patch description includes the double space between words. Also, I think
you need to write the patch description again for formal style.
This patch adds the specific 'enable-gpio' pin to express the SHDN#pin for
MAX3355E.
I think it is not regular and standard case because maybe USB specification
don't include the SHDN#pin information. I think it not appropriate way.
Instead, you better to make the MAX3355 extcon driver to support this case.
Thanks,
Chanwoo
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>
> Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt |3 +++
> drivers/extcon/extcon-usb-gpio.c |5 +
> 2 files changed, 8 insertions(+)
>
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> ===
> --- extcon.orig/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -7,6 +7,9 @@ Required properties:
> - compatible: Should be "linux,extcon-usb-gpio"
> - id-gpio: gpio for USB ID pin. See gpio binding.
>
> +Optional properties:
> +- enable-gpio: gpio for the enable pin. See gpio binding.
> +
> Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
> extcon_usb1 {
> compatible = "linux,extcon-usb-gpio";
> Index: extcon/drivers/extcon/extcon-usb-gpio.c
> ===
> --- extcon.orig/drivers/extcon/extcon-usb-gpio.c
> +++ extcon/drivers/extcon/extcon-usb-gpio.c
> @@ -33,6 +33,7 @@ struct usb_extcon_info {
> struct device *dev;
> struct extcon_dev *edev;
>
> + struct gpio_desc *enable_gpiod;
> struct gpio_desc *id_gpiod;
> int id_irq;
>
> @@ -99,6 +100,8 @@ static int usb_extcon_probe(struct platf
> return -ENOMEM;
>
> info->dev = dev;
> + info->enable_gpiod = devm_gpiod_get_optional(&pdev->dev, "enable",
> + GPIOD_OUT_HIGH);
> info->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
> if (IS_ERR(info->id_gpiod)) {
> dev_err(dev, "failed to get ID GPIO\n");
> @@ -155,6 +158,8 @@ static int usb_extcon_remove(struct plat
>
> cancel_delayed_work_sync(&info->wq_detcable);
>
> + gpiod_set_value_cansleep(info->enable_gpiod, 0);
> +
> return 0;
> }
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region
On Wed, Dec 9, 2015 at 3:53 PM, Russell King - ARM Linux wrote: [...] >> > > dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2); >> > > + /* >> > > + * ensure that the ATU enable has been happaned before accessing >> > > + * pci configuration/io spaces through dw_pcie_cfg_[read|write]. >> > > + */ >> > > + wmb(); >> > > } >> > > >> >> >> My understnading is that since writel() of dw_pcie_writel_rc() in >> above code and readl(), writel() of dw_pcie_cfg_[read|write]() (which >> will follow) goes through same device (ie PCIe host here). So, it is >> guaranteed that 1st writel() will be executed before later >> readl()/writel(). If that is true then we do not need any explicit >> barrier here. >> >> Arnd, Russel: whats your opinion here. > ^l Sorry :( > > writel() has a barrier _before_ the access but not after. > > The fact is that there's nothing which guarantees that the write will hit > the hardware in a timely manner (forget any rules about PCI config space, > the PCI ordering rules apply to the PCI bus, not to the ARM buses.) > > If you need this write to have hit the hardware before continuing, you > need to read back from the same register. OK, so better to replace wmb() with read back of control register. > > I'm just looking at this driver, trying to decipher what it's doing. It > _looks_ to me like it's reprogramming one of the outbound windows (IO?) > so that configuration space can be accessed. Doesn't this have the > effect of disabling access to the IO segment of the PCI bus from the > host CPU? > > What protections are there against other CPUs in the system issuing a > PCI I/O read/write while this outbound window is programmed as > configuration space? Yes, that is an issue with this driver. Most of the host controller has 4 or more viewpoints, and it is very easy to handle for them. But there are few which has only two viewpoints. Do not know how to solve it, so that it works for all. ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3,1/6] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support
On Thu, Nov 19, 2015 at 05:19:28PM -0600, Matthew McClintock wrote: > From: Varadarajan Narayanan > > Add pinctrl driver support for IPQ4019 platform > > Signed-off-by: Sricharan R > Signed-off-by: Mathieu Olivari > Signed-off-by: Varadarajan Narayanan > Signed-off-by: Matthew McClintock > Acked-by: Rob Herring Looks good. Much better than before. Reviewed-by: Andy Gross -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/3] usb: renesas_usbhs: add fallback compatibility strings
On Thu, Dec 10, 2015 at 09:56:24PM -0600, Rob Herring wrote:
> On Fri, Dec 11, 2015 at 11:12:26AM +0900, Simon Horman wrote:
> > Add fallback compatibility strings for R-Car Gen2 and Gen3.
> > This is in keeping with the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> >
> > Signed-off-by: Simon Horman
>
> Binding looks okay, but one possible typo.
>
> Acked-by: Rob Herring
>
> > --- a/drivers/usb/renesas_usbhs/common.c
> > +++ b/drivers/usb/renesas_usbhs/common.c
> > @@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
> > .compatible = "renesas,usbhs-r8a7795",
> > .data = (void *)USBHS_TYPE_RCAR_GEN2,
> > },
> > + {
> > + .compatible = "renesas,rcar-gen2-usbhs",
> > + .data = (void *)USBHS_TYPE_RCAR_GEN2,
> > + },
> > + {
> > + /* Gen3 is compatible with Gen2 */
> > + .compatible = "renesas,rcar-gen3-usbhs",
> > + .data = (void *)USBHS_TYPE_RCAR_GEN2,
>
> This supposed to be GEN3?
Confusingly the symbol is called GEN2 as it was there for Gen 2
before Gen 3 came along and (so far) Gen 3 is compatible with Gen 2.
I'd be happy to change the name but I think that would be best
as an incremental change on top of this one.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: sunxi: allwinner,sun4i-a10-lradc-keys binding: typo fix
On Fri, Dec 11, 2015 at 11:54 AM, Chen-Yu Tsai wrote:
> On Fri, Dec 11, 2015 at 11:45 AM, Rob Herring wrote:
>> On Thu, Dec 10, 2015 at 09:32:01PM +0100, Karsten Merker wrote:
>>> Trivial typo fix ("mut" -> "must") in the sunxi LRADC-keys binding
>>> documentation.
>>>
>>> Signed-off-by: Karsten Merker
>>
>> Acked-by: Rob Herring
>
> Acked-by: Chen-Yu Tsai
You should send this patch to the input subsystem maintainer and input
mailing list (with all the acks gathered in this thread).
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 2/3] usb: renesas_usbhs: add fallback compatibility strings
On Fri, Dec 11, 2015 at 11:12:26AM +0900, Simon Horman wrote:
> Add fallback compatibility strings for R-Car Gen2 and Gen3.
> This is in keeping with the fallback scheme being adopted wherever
> appropriate for drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman
Binding looks okay, but one possible typo.
Acked-by: Rob Herring
> --- a/drivers/usb/renesas_usbhs/common.c
> +++ b/drivers/usb/renesas_usbhs/common.c
> @@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
> .compatible = "renesas,usbhs-r8a7795",
> .data = (void *)USBHS_TYPE_RCAR_GEN2,
> },
> + {
> + .compatible = "renesas,rcar-gen2-usbhs",
> + .data = (void *)USBHS_TYPE_RCAR_GEN2,
> + },
> + {
> + /* Gen3 is compatible with Gen2 */
> + .compatible = "renesas,rcar-gen3-usbhs",
> + .data = (void *)USBHS_TYPE_RCAR_GEN2,
This supposed to be GEN3?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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 1/3] usb: renesas_usbhs: add SoC names to compatibility string documentation
On Fri, Dec 11, 2015 at 11:12:25AM +0900, Simon Horman wrote: > This extends the documentation of compatibility strings a little to > include the SoC names. > > Signed-off-by: Simon Horman Acked-by: Rob Herring > --- > v3 > * Split into separate patch > --- > Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > index 7d48f63db44e..a14c0bb561d5 100644 > --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt > @@ -2,10 +2,10 @@ Renesas Electronics USBHS driver > > Required properties: >- compatible: Must contain one of the following: > - - "renesas,usbhs-r8a7790" > - - "renesas,usbhs-r8a7791" > - - "renesas,usbhs-r8a7794" > - - "renesas,usbhs-r8a7795" > + - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device > + - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device > + - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device > + - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device >- reg: Base address and length of the register for the USBHS >- interrupts: Interrupt specifier for the USBHS >- clocks: A list of phandle + clock specifier pairs > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: sunxi: allwinner,sun4i-a10-lradc-keys binding: typo fix
On Fri, Dec 11, 2015 at 11:45 AM, Rob Herring wrote:
> On Thu, Dec 10, 2015 at 09:32:01PM +0100, Karsten Merker wrote:
>> Trivial typo fix ("mut" -> "must") in the sunxi LRADC-keys binding
>> documentation.
>>
>> Signed-off-by: Karsten Merker
>
> Acked-by: Rob Herring
Acked-by: Chen-Yu Tsai
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] extcon-usb-gpio: add enable pin support
On Fri, Dec 11, 2015 at 02:07:05AM +0300, Sergei Shtylyov wrote:
> Sometimes there's a real OTG chip behind the USB ID signal mapped to a GPIO
> pin: in my case it's Maxim Integrated MAX3355E which integrates Vbus charge
> pump and comparators and passes thru the ID signal from an OTG connector.
> This chip also has the SHDN# pin which should be driven high for the normal
> operation and low to save power; it is connected to a GPIO pin as well on,
> hence we'll have to teach the driver to parse the new optional device tree
> property, "enable-gpio"...
Some wierd spacing going on here.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> The patch is against the 'extcon-next' branch of the 'extcon.git' repo.
>
> Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt |3 +++
> drivers/extcon/extcon-usb-gpio.c |5 +
> 2 files changed, 8 insertions(+)
>
> Index: extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> ===
> --- extcon.orig/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> +++ extcon/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -7,6 +7,9 @@ Required properties:
> - compatible: Should be "linux,extcon-usb-gpio"
> - id-gpio: gpio for USB ID pin. See gpio binding.
>
> +Optional properties:
> +- enable-gpio: gpio for the enable pin. See gpio binding.
Use -gpios as -gpio is deprecated.
> +
> Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
> extcon_usb1 {
> compatible = "linux,extcon-usb-gpio";
> Index: extcon/drivers/extcon/extcon-usb-gpio.c
> ===
> --- extcon.orig/drivers/extcon/extcon-usb-gpio.c
> +++ extcon/drivers/extcon/extcon-usb-gpio.c
> @@ -33,6 +33,7 @@ struct usb_extcon_info {
> struct device *dev;
> struct extcon_dev *edev;
>
> + struct gpio_desc *enable_gpiod;
> struct gpio_desc *id_gpiod;
> int id_irq;
>
> @@ -99,6 +100,8 @@ static int usb_extcon_probe(struct platf
> return -ENOMEM;
>
> info->dev = dev;
> + info->enable_gpiod = devm_gpiod_get_optional(&pdev->dev, "enable",
> + GPIOD_OUT_HIGH);
> info->id_gpiod = devm_gpiod_get(&pdev->dev, "id", GPIOD_IN);
> if (IS_ERR(info->id_gpiod)) {
> dev_err(dev, "failed to get ID GPIO\n");
> @@ -155,6 +158,8 @@ static int usb_extcon_remove(struct plat
>
> cancel_delayed_work_sync(&info->wq_detcable);
>
> + gpiod_set_value_cansleep(info->enable_gpiod, 0);
Shouldn't you support either polarity?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next (v2) 1/2] clk: Add brcm,bcm6345-gate-clk device tree binding
On Thu, Dec 10, 2015 at 09:49:21PM +, Simon Arlott wrote:
> Add device tree binding for the BCM6345's gated clocks.
>
> The BCM6345 contains clocks gated with a register. Clocks are indexed
> by bits in the register and are active high. Most MIPS-based BCM63xx
> SoCs have a clock gating set of registers, but some have clock gate bits
> interleaved with other status bits and configurable clocks in the same
> register.
>
> Signed-off-by: Simon Arlott
Acked-by: Rob Herring
> ---
> v2: Added clock-indices, clock-output-names (from clock-bindings.txt),
> these are required properties.
>
> v1: Renamed from BCM63xx to BCM6345.
>
> .../bindings/clock/brcm,bcm6345-gate-clk.txt | 62
> ++
> 1 file changed, 62 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/brcm,bcm6345-gate-clk.txt
>
> diff --git
> a/Documentation/devicetree/bindings/clock/brcm,bcm6345-gate-clk.txt
> b/Documentation/devicetree/bindings/clock/brcm,bcm6345-gate-clk.txt
> new file mode 100644
> index 000..a6e264c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,bcm6345-gate-clk.txt
> @@ -0,0 +1,62 @@
> +Broadcom BCM6345 clocks
> +
> +This binding uses the common clock binding:
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +The BCM6345 contains clocks gated with a register. Clocks are indexed
> +by bits in the register and are active high. Most MIPS-based BCM63xx
> +SoCs have a clock gating set of registers, but some have clock gate bits
> +interleaved with other status bits and configurable clocks in the same
> +register.
> +
> +Required properties:
> +- compatible: Should be "brcm,bcm-gate-clk",
> "brcm,bcm6345-gate-clk"
> +- #clock-cells: Should be <1>.
> +- regmap: The register map phandle
> +- offset: Offset in the register map for the clock register (in
> bytes)
> +- clocks: The external oscillator clock phandle
> +- clock-indices: The bits in the register used for gated clocks.
> +- clock-output-names: Should be a list of strings of clock output signal
> + names indexed by the clock indices.
> +
> +Example:
> +
> +periph_clk: periph_clk {
> + compatible = "brcm,bcm63168-gate-clk", "brcm,bcm6345-gate-clk";
> + regmap = <&periph_cntl>;
> + offset = <0x4>;
> +
> + #clock-cells = <1>;
> + clock-indices =
> + <1>, <2>,<3>, <4>, <5>,
> + <6>, <7>,<8>, <9>, <10>,
> + <11>, <12>, <13>, <14>,<15>,
> + <16>, <17>, <18>, <19>,<20>,
> + <27>, <31>;
> + clock-output-names =
> + "vdsl_qproc", "vdsl_afe", "vdsl","mips", "wlan_ocp",
> + "dect", "fap0", "fap1","sar", "robosw",
> + "pcm","usbd", "usbh","ipsec", "spi",
> + "hsspi", "pcie", "phymips", "gmac", "nand",
> + "tbus", "robosw250";
> +};
> +
> +timer_clk: timer_clk {
> + compatible = "brcm,bcm63168-gate-clk", "brcm,bcm6345-gate-clk";
> + regmap = <&timer_cntl>;
> + offset = <0x4>;
> +
> + #clock-cells = <1>;
> + clock-indices = <17>, <18>;
> + clock-output-names = "uto_extin", "usb_ref";
> +};
> +
> +ehci0: usb@10002500 {
> + compatible = "brcm,bcm63168-ehci", "brcm,bcm6345-ehci", "generic-ehci";
> + reg = <0x10002500 0x100>;
> + big-endian;
> + interrupt-parent = <&periph_intc>;
> + interrupts = <10>;
> + clocks = <&periph_clk 13>, <&timer_clk 18>;
> + phys = <&usbh>;
> +};
> --
> 2.1.4
>
> --
> Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next (v3) 1/2] reset: Add brcm,bcm6345-reset device tree binding
On Thu, Dec 10, 2015 at 09:28:38PM +, Simon Arlott wrote:
> Add device tree binding for the BCM6345 soft reset controller.
>
> The BCM6345 contains a soft-reset controller activated by setting
> a bit (that must previously have been cleared).
>
> Signed-off-by: Simon Arlott
> ---
> v3: Resend. Example has changed because usbh now has two compatible
> strings and uses a power domain instead of a regulator.
Not really all that important to this binding definition, so you can
keep my ack.
>
> v2: Renamed to bcm6345, removed "mask" property.
> Acked-by: Rob Herring
>
> .../bindings/reset/brcm,bcm6345-reset.txt | 33
> ++
> 1 file changed, 33 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
>
> diff --git a/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
> b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
> new file mode 100644
> index 000..0313040
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reset/brcm,bcm6345-reset.txt
> @@ -0,0 +1,33 @@
> +Broadcom BCM6345 reset controller
> +
> +The BCM6345 contains a basic soft reset controller in the perf register
> +set which resets components using a bit in a register.
> +
> +Please also refer to reset.txt in this directory for common reset
> +controller binding usage.
> +
> +Required properties:
> +- compatible:Should be "brcm,bcm-reset", "brcm,bcm6345-reset"
> +- regmap:The register map phandle
> +- offset:Offset in the register map for the reset register (in bytes)
> +- #reset-cells: Must be set to 1
> +
> +Example:
> +
> +periph_soft_rst: reset-controller {
> + compatible = "brcm,bcm63168-reset", "brcm,bcm6345-reset";
> + regmap = <&periph_cntl>;
> + offset = <0x10>;
> +
> + #reset-cells = <1>;
> +};
> +
> +usbh: usbphy@10002700 {
> + compatible = "brcm,bcm63168-usbh", "brcm,bcm6328-usbh";
> + reg = <0x10002700 0x38>;
> + clocks = <&periph_clk 13>, <&timer_clk 18>;
> + resets = <&periph_soft_rst 6>;
> + power-domains = <&misc_iddq_ctrl 4>;
> + #phy-cells = <0>;
> +};
> +
> --
> 2.1.4
>
> --
> Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: sunxi: allwinner,sun4i-a10-lradc-keys binding: typo fix
On Thu, Dec 10, 2015 at 09:32:01PM +0100, Karsten Merker wrote:
> Trivial typo fix ("mut" -> "must") in the sunxi LRADC-keys binding
> documentation.
>
> Signed-off-by: Karsten Merker
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
> b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
> index b9c32f6..4357e49 100644
> --- a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
> +++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
> @@ -12,7 +12,7 @@ Each key is represented as a sub-node of
> "allwinner,sun4i-a10-lradc-keys":
> Required subnode-properties:
> - label: Descriptive name of the key.
> - linux,code: Keycode to emit.
> - - channel: Channel this key is attached to, mut be 0 or 1.
> + - channel: Channel this key is attached to, must be 0 or 1.
> - voltage: Voltage in µV at lradc input when this key is pressed.
>
> Example:
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] extcon: arizona: Update device tree binding for mic detect configurations
On Thu, Dec 10, 2015 at 05:08:19PM +, Charles Keepax wrote: > Update the device tree binding documentation to include documentation for > the wlf,micd-configs property that is used to specify the configurations > for headset polarity detection (CTIA / OTMP). > > Signed-off-by: Charles Keepax Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/extcon/extcon-arizona.txt | 8 > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt > b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt > index 238e10e..fd9b898 100644 > --- a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt > +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt > @@ -37,5 +37,13 @@ Optional properties: > milliseconds. >- wlf,micd-force-micbias : Force MICBIAS continuously on during microphone > detection. > + - wlf,micd-configs : Headset polarity configurations (generally used for > +detection of CTIA / OMTP headsets), the field can be of variable length > +but should always be a multiple of 3 cells long, each three cell group > +represents one polarity configuration. > +The first cell defines the accessory detection pin, zero will use MICDET1 > +and all other values will use MICDET2. > +The second cell represents the MICBIAS to be used. > +The third cell represents the value of the micd-pol-gpio pin. > >- wlf,gpsw : Settings for the general purpose switch > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Input: add touchscreen bindings for TS-4800
On Thu, Dec 10, 2015 at 11:11:11AM -0500, Damien Riegel wrote: > Add bindings for the TS-4800 touchscreen. > > Signed-off-by: Damien Riegel Generally, there are other properties needed from the common touchscreen binding. You don't need any of those here? Otherwise, Acked-by: Rob Herring > --- > .../devicetree/bindings/input/touchscreen/ts4800-ts.txt | 12 > > 1 file changed, 12 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt > > diff --git > a/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt > b/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt > new file mode 100644 > index 000..63282fa > --- /dev/null > +++ b/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt > @@ -0,0 +1,12 @@ > +* TS-4800 Touchscreen bindings > + > +Required properties: > +- compatible: must be "technologic,ts4800-ts" > +- reg: physical base address of the controller and length of memory mapped > + region. > +- syscon: phandle / integers array that points to the syscon node which > + describes the FPGA's syscon registers. > + - phandle to FPGA's syscon > + - offset to the touchscreen register > + - offset to the touchscreen enable bit > + > -- > 2.5.0 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PICKME 0/2] cpufreq: New ST driver
On 10-12-15, 22:38, Rafael J. Wysocki wrote: > Do they depend on anything special? My opp-binding-parsing patches which you applied to bleeding-edge. Yes, Lee should have mentioned that explicitly. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 1/2] power: Add brcm,bcm6358-power-controller device tree binding
On Wed, Dec 09, 2015 at 10:29:35PM +, Simon Arlott wrote: > The BCM6358 contains power domains controlled with a register. Power > domains are indexed by bits in the register. Power domain bits can be > interleaved with other status bits and clocks in the same register. > > Newer SoCs with dedicated power domain registers are active low. > > Signed-off-by: Simon Arlott > --- > .../power/brcm,bcm6358-power-controller.txt| 53 > ++ > 1 file changed, 53 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt > > diff --git > a/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt > b/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt > new file mode 100644 > index 000..556c323 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/power/brcm,bcm6358-power-controller.txt > @@ -0,0 +1,53 @@ > +Broadcom BCM6358 Power domain controller > + > +This binding uses the power domain bindings: > +Documentation/devicetree/bindings/power/power_domain.txt > + > +The BCM6358 contains power domains controlled with a register. Power > +domains are indexed by bits in the register. Power domain bits can be > +interleaved with other status bits and clocks in the same register. > + > +Newer SoCs with dedicated power domain registers are active low. > + > +Required properties: > +- compatible: Should be "brcm,bcm-power-controller", > "brcm,bcm6358-power-controller" > +- #power-domain-cells: Should be <1>. > +- regmap: The register map phandle > +- offset: Offset in the register map for the power domain > register (in bytes) > +- power-domain-indices: The bits in the register used for power domains. You should drop this and make the cell values be the register offsets. > +- power-domain-names: Should be a list of strings of power domain names > +indexed by the power domain indices. This isn't really needed anyway. > + > +Optional properties: > +- active-low: Specify that the bits are active low. This should be implied by the compatible property. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" 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 0/3] usb: renesas_usbhs: More compat strings
Hi > this short series adds generic, and soc-specific r8a7792 and r8a7793 compat > strings to the Renesas USBHS driver. The intention is to provide a complete > set of compat strings for known R-Car SoCs. > > Changes since v2: > * Split documentation of SoC names into separate patch > * Use correct fallback compatibility string in example > > Changes since v1: > * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than > a single compatibility string for all of R-Car. > > Simon Horman (3): > usb: renesas_usbhs: add SoC names to compatibility string > documentation > usb: renesas_usbhs: add fallback compatibility strings > usb: renesas_usbhs: add device tree support for r8a779[23] > > .../devicetree/bindings/usb/renesas_usbhs.txt| 20 > +++- > drivers/usb/renesas_usbhs/common.c | 9 + > 2 files changed, 24 insertions(+), 5 deletions(-) For all patches Acked-by: Kuninori Morimoto -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] arm: pxa27x: support for ICP DAS LP-8x4x w/ DT
On Thu, Dec 10, 2015 at 01:28:08AM +0300, Sergei Ianovich wrote:
> ICP DAS calls LP-8x4x 'programmable automation controller'. It is
> an industrial computer based on PXA270 SoC. They ship it with a 2.6.19
> kernel and proprietary kernel module and userspace library to access
> its industrial IO.
2 comments, otherwise:
Acked-by: Rob Herring
> diff --git a/arch/arm/boot/dts/pxa27x-lp8x4x.dts
> b/arch/arm/boot/dts/pxa27x-lp8x4x.dts
> new file mode 100644
> index 000..bbb5b75
> --- /dev/null
> +++ b/arch/arm/boot/dts/pxa27x-lp8x4x.dts
> @@ -0,0 +1,260 @@
> +/* Device tree for ICP DAS LP-8x4x */
> +/dts-v1/;
> +
> +#include
Pretty sure this does not have a GIC.
> +#include "pxa27x.dtsi"
> +
> +/ {
> + model = "ICP DAS LP-8x4x programmable automation controller";
> + compatible = "marvell,pxa270";
You should have a compatible string for this board.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH linux-next 1/2] irqchip: Add brcm,bcm6345-l1-intc device tree binding
On Wed, Dec 09, 2015 at 08:27:09PM +, Simon Arlott wrote:
> Add device tree binding for the BCM6345 interrupt controller.
>
> This controller is similar to the SMP-capable BCM7038 and
> the BCM3380 but with packed interrupt registers.
>
> Signed-off-by: Simon Arlott
Acked-by: Rob Herring
> ---
> Corrected example device name to be "interrupt-controller".
>
> .../interrupt-controller/brcm,bcm6345-l1-intc.txt | 57
> ++
> 1 file changed, 57 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
>
> b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
> new file mode 100644
> index 000..4040905
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm6345-l1-intc.txt
> @@ -0,0 +1,57 @@
> +Broadcom BCM6345-style Level 1 interrupt controller
> +
> +This block is a first level interrupt controller that is typically connected
> +directly to one of the HW INT lines on each CPU.
> +
> +Key elements of the hardware design include:
> +
> +- 32, 64 or 128 incoming level IRQ lines
> +
> +- Most onchip peripherals are wired directly to an L1 input
> +
> +- A separate instance of the register set for each CPU, allowing individual
> + peripheral IRQs to be routed to any CPU
> +
> +- Contains one or more enable/status word pairs per CPU
> +
> +- No atomic set/clear operations
> +
> +- No polarity/level/edge settings
> +
> +- No FIFO or priority encoder logic; software is expected to read all
> + 2-4 status words to determine which IRQs are pending
> +
> +Required properties:
> +
> +- compatible: should be "brcm,bcm-l1-intc", "brcm,bcm6345-l1-intc"
> +- reg: specifies the base physical address and size of the registers;
> + the number of supported IRQs is inferred from the size argument
> +- interrupt-controller: identifies the node as an interrupt controller
> +- #interrupt-cells: specifies the number of cells needed to encode an
> interrupt
> + source, should be 1.
> +- interrupt-parent: specifies the phandle to the parent interrupt
> controller(s)
> + this one is cascaded from
> +- interrupts: specifies the interrupt line(s) in the interrupt-parent
> controller
> + node; valid values depend on the type of parent interrupt controller
> +
> +If multiple reg ranges and interrupt-parent entries are present on an SMP
> +system, the driver will allow IRQ SMP affinity to be set up through the
> +/proc/irq/ interface. In the simplest possible configuration, only one
> +reg range and one interrupt-parent is needed.
> +
> +The driver operates in native CPU endian by default, there is no support for
> +specifying an alternative endianness.
> +
> +Example:
> +
> +periph_intc: interrupt-controller@1000 {
> +compatible = "brcm,bcm63168-l1-intc", "brcm,bcm6345-l1-intc";
> +reg = <0x1020 0x20>,
> + <0x1040 0x20>;
> +
> +interrupt-controller;
> +#interrupt-cells = <1>;
> +
> +interrupt-parent = <&cpu_intc>;
> +interrupts = <2>, <3>;
> +};
> --
> 2.1.4
>
> --
> Simon Arlott
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic DT binding for IPIs
On Thu, Dec 10, 2015 at 10:20:49AM +, Qais Yousef wrote:
> On 12/09/2015 04:50 PM, Rob Herring wrote:
> >On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote:
> >
> >>What I have in mind is:
> >>
> >> coproc {
> >> ipi-parent = <&gic>;
> >>
> >> ipis = ;
> >> ipi-names = "in";
> >> };
> >>
> >>This will allocate an IPI to go to cpu @CPU_VALUE passing @IPI_SPEC as
> >>parameters to the controller. Which means we need a new ipi-cells to
> >>define how many cells are in ipis property. Note the new ipi-parent too.
> >These are still interrupts, so I'd prefer to use or extend the
> >interrupt binding if possible.
>
> The IPIs have two properties that are different from a regular interrupts:
>
> 1. An IPI is not only received, it could also be sent.
Any interrupt is sent by the device, received by an interrupt
controller, so this isn't really anything fundamentally different.
> 2. The IPI is dynamic. There's an actual allocation from a pool of
> available
> IPIs happening when we ask for one to be reserved.
It's not really clear to me what that means, and why it requires any
particular different information in the device tree.
> The difference might be borderline..
>
> Do you have any rough idea on what a possible extension could look like?
> Reusing means writing less code, which is always better of course :)
>
> By the way, on MIPS GIC, we can use interrupts property to describe an IPI
> the host system will receive. But to send one to the coprocessor, we need to
> define an outgoing IPI.
Ah, ok, so is what you're trying to describe here (from the host OS
and CPU point of view) a purely outgoing signal to the coproc?
> In this case, the firmware will be hardcoded to send an interrupt to a
> specific hwirq, so one can then describe it in DT as a regular interrupt to
> the host system. Hardcoding is not ideal and less portable though.
Or is the signal that goes to the coproc then somehow being translated
into a host interrupt? If that's so you should be able to represent
the coproc as an interrupt controller or interrupt nexus.
> >>ipis property also is similar to interrupts, so using it would be easier
> >>(I think).
> >>
> >>If we have 2 coprocessors that want to communicate using IPIs that are
> >>managed by the host we use ipi-refs property to refer to IPIs defined in
> >>another node.
> >>
> >> coproc1 {
> >> ipis = , , ;
> >Don't you need to specify a certain IPI number in addition to which
> >cpu is the target?
>
> No. The way IPI reserving works is we just need to specify the target
> CPU(s).
>
> >
> >I'm thinking the cpu target could be part of the interrupts property
> >flags field or something.
>
> I'll look more at this option.
>
> >
> >> ipi-names = "in", "coproc2data", "coproc2ctrl";
> >-names should be optional in general. So define something that works
> >without them.
>
> If it's not specified, then the driver can get the definition by index and
> it would have to define the order it expects the IPIs in the binding?
>
> >> };
> >>
> >> coproc2 {
> >> ipi-refs = <&coproc1 "in">, <&coproc1 "coproc2data">,
> >> <&coproc1
> >>"corpoc2ctrl">;
> >This isn't actually parseable. You need a known length of cells after a
> >phandle.
> >
>
> To clarify, what you're saying we can't pass strings, right?
So, I'm not entirely sure what point Rob was making. The above
certainly isn't valid dts syntax - strings can't appear within
the < > construct. But if you make the obvious fix to:
ipi-refs = <&coproc1>, "in", <&coproc1>, "coproc2data";
then it's certainly a parseable property format. It's kind of clunky
mixing integers and strings that way, but it's possible and there are
existing bindings using properties in a similar format.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
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 devicetree" 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 0/4] PCI: rcar, rcar-gen2: More Gen2 compatibility strings
On Wed, Dec 09, 2015 at 12:37:43PM -0600, Bjorn Helgaas wrote: > On Thu, Dec 03, 2015 at 07:51:36AM +0900, Simon Horman wrote: > > Hi, > > > > this short series adds generic gen2 and SoC-specific r8a7793 compatibility > > strings to the rcar PCI and rcar-gen2 PCIE drivers. The intention is to > > provide a complete set of compatibility strings for known Gen2 SoCs. > > > > Key Changes in v2: > > * Include "rcar-" in generic bindings > > > > Simon Horman (4): > > PCI: rcar-gen2: add gen2 fallback compatibility string > > PCI: rcar-gen2: add device tree support for r8a7793 > > PCI: rcar: add gen2 fallback compatibility string > > PCI: rcar: add device tree support for r8a7793 > > > > Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 12 ++-- > > Documentation/devicetree/bindings/pci/rcar-pci.txt | 14 +++--- > > drivers/pci/host/pci-rcar-gen2.c| 1 + > > drivers/pci/host/pcie-rcar.c| 1 + > > 4 files changed, 23 insertions(+), 5 deletions(-) > > I applied these: > > > PCI: rcar-gen2: add gen2 fallback compatibility string > > PCI: rcar: add gen2 fallback compatibility string > > to pci/host-rcar for v4.5, thanks! > > I haven't applied the R8A7793 binding documentation updates yet, but > I'll be happy to do so given a short description of why they're > useful (since they don't update a DT or the driver). Or they could be > merged via a DT tree. To clarify: you would like a description in the changelog? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] usb: renesas_usbhs: add fallback compatibility strings
Add fallback compatibility strings for R-Car Gen2 and Gen3.
This is in keeping with the fallback scheme being adopted wherever
appropriate for drivers for Renesas SoCs.
Signed-off-by: Simon Horman
---
v3
* Moved documentation of SoC names to a separate patch
* Use correct fallback compatibility string in example
v2
* Add R-Car Gen2 and Gen3 fallback compatibility strings rather than
a single compatibility string for all of R-Car.
---
Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 10 +-
drivers/usb/renesas_usbhs/common.c | 9 +
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
index a14c0bb561d5..c55cf77006d0 100644
--- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
+++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt
@@ -2,10 +2,18 @@ Renesas Electronics USBHS driver
Required properties:
- compatible: Must contain one of the following:
+
- "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
- "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
- "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
- "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
+ - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device
+ - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatible device
+
+ When compatible with the generic version, nodes must list the
+ SoC-specific version corresponding to the platform first followed
+ by the generic version.
+
- reg: Base address and length of the register for the USBHS
- interrupts: Interrupt specifier for the USBHS
- clocks: A list of phandle + clock specifier pairs
@@ -22,7 +30,7 @@ Optional properties:
Example:
usbhs: usb@e659 {
- compatible = "renesas,usbhs-r8a7790";
+ compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
reg = <0 0xe659 0 0x100>;
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
diff --git a/drivers/usb/renesas_usbhs/common.c
b/drivers/usb/renesas_usbhs/common.c
index d82fa36c3465..db9a17bd8997 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -481,6 +481,15 @@ static const struct of_device_id usbhs_of_match[] = {
.compatible = "renesas,usbhs-r8a7795",
.data = (void *)USBHS_TYPE_RCAR_GEN2,
},
+ {
+ .compatible = "renesas,rcar-gen2-usbhs",
+ .data = (void *)USBHS_TYPE_RCAR_GEN2,
+ },
+ {
+ /* Gen3 is compatible with Gen2 */
+ .compatible = "renesas,rcar-gen3-usbhs",
+ .data = (void *)USBHS_TYPE_RCAR_GEN2,
+ },
{ },
};
MODULE_DEVICE_TABLE(of, usbhs_of_match);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/3] usb: renesas_usbhs: add device tree support for r8a779[23]
Simply document new compatibility string. As a previous patch adds a generic R-Car Gen2 compatibility string there appears to be no need for a driver updates. Signed-off-by: Simon Horman Acked-by: Rob Herring --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index c55cf77006d0..471a0649e63e 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -5,6 +5,8 @@ Required properties: - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device + - "renesas,usbhs-r8a7792" for r8a7792 (R-Car V2H) compatible device + - "renesas,usbhs-r8a7793" for r8a7793 (R-Car M2-N) compatible device - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatible device -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] usb: renesas_usbhs: add SoC names to compatibility string documentation
This extends the documentation of compatibility strings a little to include the SoC names. Signed-off-by: Simon Horman --- v3 * Split into separate patch --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index 7d48f63db44e..a14c0bb561d5 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -2,10 +2,10 @@ Renesas Electronics USBHS driver Required properties: - compatible: Must contain one of the following: - - "renesas,usbhs-r8a7790" - - "renesas,usbhs-r8a7791" - - "renesas,usbhs-r8a7794" - - "renesas,usbhs-r8a7795" + - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device + - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device + - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device + - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device - reg: Base address and length of the register for the USBHS - interrupts: Interrupt specifier for the USBHS - clocks: A list of phandle + clock specifier pairs -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] usb: renesas_usbhs: More compat strings
Hi, this short series adds generic, and soc-specific r8a7792 and r8a7793 compat strings to the Renesas USBHS driver. The intention is to provide a complete set of compat strings for known R-Car SoCs. Changes since v2: * Split documentation of SoC names into separate patch * Use correct fallback compatibility string in example Changes since v1: * Add R-Car Gen2 and Gen3 fallback compatibility strings rather than a single compatibility string for all of R-Car. Simon Horman (3): usb: renesas_usbhs: add SoC names to compatibility string documentation usb: renesas_usbhs: add fallback compatibility strings usb: renesas_usbhs: add device tree support for r8a779[23] .../devicetree/bindings/usb/renesas_usbhs.txt| 20 +++- drivers/usb/renesas_usbhs/common.c | 9 + 2 files changed, 24 insertions(+), 5 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files
Le 10/12/2015 15:38, Rob Herring a écrit : > Platform dts files need to be reviewed primarily by the platform > maintainers as dts files typically go in thru their trees. Add the missing > paths where there are existing maintainers listed. > > Signed-off-by: Rob Herring > --- [snip] > @@ -2300,6 +2314,7 @@ F: arch/arm/mach-bcm/ > F: arch/arm/boot/dts/bcm113* > F: arch/arm/boot/dts/bcm216* > F: arch/arm/boot/dts/bcm281* > +F: arch/arm64/boot/dts/broadcom/ > F: arch/arm/configs/bcm_defconfig > F: drivers/mmc/host/sdhci-bcm-kona.c > F: drivers/clocksource/bcm_kona_timer.c Acked-by: Florian Fainelli -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 7/8] ARM: dts: rockchip: add core rk3228 dtsi
Hi Heiko,
On 2015-12-10 8:32, Heiko Stuebner wrote:
Hi Jeffy,
Am Mittwoch, 9. Dezember 2015, 17:04:12 schrieb Jeffy Chen:
Initial release for rk3228 shared dtsi.
Signed-off-by: Jeffy Chen
---
arch/arm/boot/dts/rk3228.dtsi | 478 ++
1 file changed, 478 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3228.dtsi
diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
new file mode 100644
index 000..d6b3e40
--- /dev/null
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -0,0 +1,478 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "rockchip,rk3228";
+
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x6000 0x4000>;
+ };
The amount of memory is a property of the board
done.
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
no enable-method?
As the rk3228 also does not have a pmu, does the newly created
"rockchip,rk3036-smp" work for you?
unlucky, that doesn't work...and our 3.10 kernel is using psci for
rk3228's smp ops, maybe i should check that too, but i know nothing
about psci for now :(
+
+ cpu0: cpu@f00 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf00>;
+ resets = <&cru SRST_CORE0>;
+ operating-points = <
+ /* KHzuV */
+816000 100
+ >;
+ clock-latency = <4>;
+ clocks = <&cru ARMCLK>;
+ };
+
+ cpu1: cpu@f01 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf01>;
+ resets = <&cru SRST_CORE1>;
+ };
+
+ cpu2: cpu@f02 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf02>;
+ resets = <&cru SRST_CORE2>;
+ };
+
+ cpu3: cpu@f03 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf03>;
+ resets = <&cru SRST_CORE3>;
+ };
+ };
+
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma: pdma@110f {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x110f 0x4000>;
+ interrupts = ,
+
Re: [PATCH v5 1/4] stmmac: create of compatible mdio bus for stmacc driver
G'day Giuseppe,
On 11/12/2015 1:16 AM, Giuseppe CAVALLARO wrote:
Hi
also pls fix this typo
stmmac: create of compatible mdio bus for stmacc driver
stmmac
Will do.
On 12/9/2015 9:39 AM, Phil Reid wrote:
The DSA driver needs to be passed a reference to an mdio bus. Typically
the mac is configured to use a fixed link but the mdio bus still needs
to be registered so that it con configure the switch.
This patch follows the same process as the altera tse ethernet driver for
creation of the mdio bus.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 31 +++---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index f34fc3c..fd5ddf8 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -47,6 +47,7 @@ Optional properties:
- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
- tx-fifo-depth: See ethernet.txt file in the same directory
- rx-fifo-depth: See ethernet.txt file in the same directory
+- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
@@ -65,4 +66,11 @@ Examples:
tx-fifo-depth = <16384>;
clocks = <&clock>;
clock-names = "stmmaceth";
+mdio0 {
+#address-cells = <1>;
+#size-cells = <0>;
+compatible = "snps,dwmac-mdio";
+phy1: ethernet-phy@0 {
+};
+};
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index bba670c..bb6f75c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
#include
#include "stmmac.h"
@@ -200,10 +200,29 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
+struct device_node *mdio_node = NULL;
+struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
+if (IS_ENABLED(CONFIG_OF)) {
+for_each_child_of_node(priv->device->of_node, child_node) {
+if (of_device_is_compatible(child_node,
+"snps,dwmac-mdio")) {
+mdio_node = child_node;
+break;
+}
+}
+
+if (mdio_node) {
+netdev_dbg(ndev, "FOUND MDIO subnode\n");
+} else {
+netdev_err(ndev, "NO MDIO subnode\n");
+return 0;
+}
+}
+
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
@@ -231,7 +250,8 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->irq = irqlist;
new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
-err = mdiobus_register(new_bus);
+
+err = of_mdiobus_register(new_bus, mdio_node);
if (err != 0) {
pr_err("%s: Cannot register as MDIO bus\n", new_bus->name);
goto bus_register_fail;
@@ -284,13 +304,6 @@ int stmmac_mdio_register(struct net_device *ndev)
}
}
-if (!found) {
-pr_warn("%s: No PHY found\n", ndev->name);
-mdiobus_unregister(new_bus);
-mdiobus_free(new_bus);
-return -ENODEV;
-}
hmm, this could be necessary on some platforms that wants to
get the phy addr at runtime and in case of failure then
removes the registered bus.
Could make this conditional on (!found && !mdio_node).
Therefore if dt node exists it will be created regardless, otherwise unregister
if nothing found.
Thoughts?
-
priv->mii = new_bus;
return 0;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index d02691b..6863420 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -146,7 +146,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
ec
-if (plat->phy_node || plat->phy_bus_name)
I think that would be dependent on the device tree.
However this may also work:
if ((plat->phy_node && !of_phy_is_fixed_link(np)) || plat->phy_bus_name)
can this breaks some conf case?
+if (plat->phy_bus_name)
plat->mdio_bus_data = NULL;
e
Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files
On 10-12-15, 17:38, Rob Herring wrote: > Platform dts files need to be reviewed primarily by the platform > maintainers as dts files typically go in thru their trees. Add the missing > paths where there are existing maintainers listed. > > Signed-off-by: Rob Herring > --- > MAINTAINERS | 20 +++- > 1 file changed, 19 insertions(+), 1 deletion(-) > @@ -10068,6 +10085,7 @@ L:spear-de...@list.st.com > L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) > W: http://www.st.com/spear > S: Maintained > +F: arch/arm/boot/dts/spear* > F: arch/arm/mach-spear/ > > SPEAR CLOCK FRAMEWORK SUPPORT Reviewed-by: Viresh Kumar -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] pinctrl: rockchip: add support for the rk3228
The pinctrl of rk3228 is much the same as rk3288's, but
without pmu.
Signed-off-by: Jeffy Chen
Reviewed-by: Heiko Stuebner
Acked-by: Rob Herring
---
Changes in v2: None
.../bindings/pinctrl/rockchip,pinctrl.txt | 3 +-
drivers/pinctrl/pinctrl-rockchip.c | 53 ++
2 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index 391ef4b..0cd701b 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -21,7 +21,8 @@ defined as gpio sub-nodes of the pinmux controller.
Required properties for iomux controller:
- compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
"rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
- "rockchip,rk3288-pinctrl", "rockchip,rk3368-pinctrl"
+ "rockchip,rk3228-pinctrl", "rockchip,rk3288-pinctrl"
+ "rockchip,rk3368-pinctrl"
- rockchip,grf: phandle referencing a syscon providing the
"general register files"
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index a065112..faab36e 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -614,6 +614,40 @@ static void rk3288_calc_drv_reg_and_bit(struct
rockchip_pin_bank *bank,
}
}
+#define RK3228_PULL_OFFSET 0x100
+
+static void rk3228_calc_pull_reg_and_bit(struct rockchip_pin_bank *bank,
+ int pin_num, struct regmap **regmap,
+ int *reg, u8 *bit)
+{
+ struct rockchip_pinctrl *info = bank->drvdata;
+
+ *regmap = info->regmap_base;
+ *reg = RK3228_PULL_OFFSET;
+ *reg += bank->bank_num * RK3188_PULL_BANK_STRIDE;
+ *reg += ((pin_num / RK3188_PULL_PINS_PER_REG) * 4);
+
+ *bit = (pin_num % RK3188_PULL_PINS_PER_REG);
+ *bit *= RK3188_PULL_BITS_PER_PIN;
+}
+
+#define RK3228_DRV_GRF_OFFSET 0x200
+
+static void rk3228_calc_drv_reg_and_bit(struct rockchip_pin_bank *bank,
+ int pin_num, struct regmap **regmap,
+ int *reg, u8 *bit)
+{
+ struct rockchip_pinctrl *info = bank->drvdata;
+
+ *regmap = info->regmap_base;
+ *reg = RK3228_DRV_GRF_OFFSET;
+ *reg += bank->bank_num * RK3288_DRV_BANK_STRIDE;
+ *reg += ((pin_num / RK3288_DRV_PINS_PER_REG) * 4);
+
+ *bit = (pin_num % RK3288_DRV_PINS_PER_REG);
+ *bit *= RK3288_DRV_BITS_PER_PIN;
+}
+
#define RK3368_PULL_GRF_OFFSET 0x100
#define RK3368_PULL_PMU_OFFSET 0x10
@@ -2143,6 +2177,23 @@ static struct rockchip_pin_ctrl rk3188_pin_ctrl = {
.pull_calc_reg = rk3188_calc_pull_reg_and_bit,
};
+static struct rockchip_pin_bank rk3228_pin_banks[] = {
+ PIN_BANK(0, 32, "gpio0"),
+ PIN_BANK(1, 32, "gpio1"),
+ PIN_BANK(2, 32, "gpio2"),
+ PIN_BANK(3, 32, "gpio3"),
+};
+
+static struct rockchip_pin_ctrl rk3228_pin_ctrl = {
+ .pin_banks = rk3228_pin_banks,
+ .nr_banks = ARRAY_SIZE(rk3228_pin_banks),
+ .label = "RK3228-GPIO",
+ .type = RK3288,
+ .grf_mux_offset = 0x0,
+ .pull_calc_reg = rk3228_calc_pull_reg_and_bit,
+ .drv_calc_reg = rk3228_calc_drv_reg_and_bit,
+};
+
static struct rockchip_pin_bank rk3288_pin_banks[] = {
PIN_BANK_IOMUX_FLAGS(0, 24, "gpio0", IOMUX_SOURCE_PMU,
IOMUX_SOURCE_PMU,
@@ -2220,6 +2271,8 @@ static const struct of_device_id
rockchip_pinctrl_dt_match[] = {
.data = (void *)&rk3066b_pin_ctrl },
{ .compatible = "rockchip,rk3188-pinctrl",
.data = (void *)&rk3188_pin_ctrl },
+ { .compatible = "rockchip,rk3228-pinctrl",
+ .data = (void *)&rk3228_pin_ctrl },
{ .compatible = "rockchip,rk3288-pinctrl",
.data = (void *)&rk3288_pin_ctrl },
{ .compatible = "rockchip,rk3368-pinctrl",
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Add support for rk3228 Soc platform
This serial of patches add dts/pinctrl/clock-tree/doc for rk3228 platform, with these patches, my evb board could boot into initramfs. Changes in v2: Fix some clock tree errors. Fix some coding styles. Separate board and core properties. Remove phy clocks. Order nodes by register address. Add vgic registers and interrupt. Move board properties into board dts. Jeffy Chen (4): pinctrl: rockchip: add support for the rk3228 rockchip: add clock controller for rk3228 ARM: dts: rockchip: add core rk3228 dtsi ARM: dts: rockchip: add rk3228-evb board .../bindings/pinctrl/rockchip,pinctrl.txt | 3 +- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/rk3228-evb.dts | 66 ++ arch/arm/boot/dts/rk3228.dtsi | 442 + drivers/clk/rockchip/Makefile | 1 + drivers/clk/rockchip/clk-rk3228.c | 681 + drivers/clk/rockchip/clk.h | 11 +- drivers/pinctrl/pinctrl-rockchip.c | 53 ++ 8 files changed, 1256 insertions(+), 2 deletions(-) create mode 100644 arch/arm/boot/dts/rk3228-evb.dts create mode 100644 arch/arm/boot/dts/rk3228.dtsi create mode 100644 drivers/clk/rockchip/clk-rk3228.c -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: dts: rockchip: add rk3228-evb board
Initial release for rk3228 sdk board.
Signed-off-by: Jeffy Chen
---
Changes in v2:
Move board properties here.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3228-evb.dts | 66
2 files changed, 67 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3228-evb.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 2d8b9e0..0223846 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -521,6 +521,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
rk3188-radxarock.dtb \
+ rk3228-evb.dtb \
rk3288-evb-act8846.dtb \
rk3288-evb-rk808.dtb \
rk3288-firefly-beta.dtb \
diff --git a/arch/arm/boot/dts/rk3228-evb.dts b/arch/arm/boot/dts/rk3228-evb.dts
new file mode 100644
index 000..e3898b8
--- /dev/null
+++ b/arch/arm/boot/dts/rk3228-evb.dts
@@ -0,0 +1,66 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3228.dtsi"
+
+/ {
+ model = "Rockchip RK3228 Evaluation board";
+ compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+
+ memory {
+ device_type = "memory";
+ reg = <0x6000 0x4000>;
+ };
+};
+
+&emmc {
+ broken-cd;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ disable-wp;
+ non-removable;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: dts: rockchip: add core rk3228 dtsi
Initial release for rk3228 shared dtsi.
Signed-off-by: Jeffy Chen
---
Changes in v2:
Separate board and core properties.
Remove phy clocks.
Order nodes by register address.
Add vgic registers and interrupt.
arch/arm/boot/dts/rk3228.dtsi | 442 ++
1 file changed, 442 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3228.dtsi
diff --git a/arch/arm/boot/dts/rk3228.dtsi b/arch/arm/boot/dts/rk3228.dtsi
new file mode 100644
index 000..e0dc01e
--- /dev/null
+++ b/arch/arm/boot/dts/rk3228.dtsi
@@ -0,0 +1,442 @@
+/*
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "rockchip,rk3228";
+
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@f00 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf00>;
+ resets = <&cru SRST_CORE0>;
+ operating-points = <
+ /* KHzuV */
+816000 100
+ >;
+ clock-latency = <4>;
+ clocks = <&cru ARMCLK>;
+ };
+
+ cpu1: cpu@f01 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf01>;
+ resets = <&cru SRST_CORE1>;
+ };
+
+ cpu2: cpu@f02 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf02>;
+ resets = <&cru SRST_CORE2>;
+ };
+
+ cpu3: cpu@f03 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf03>;
+ resets = <&cru SRST_CORE3>;
+ };
+ };
+
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma: pdma@110f {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x110f 0x4000>;
+ interrupts = ,
+;
+ #dma-cells = <1>;
+ clocks = <&cru ACLK_DMAC>;
+ clock-names = "apb_pclk";
+ };
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = ,
+,
+,
+;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>
[PATCH v2] ARM: dts: imx7d: cl-som-imx7: add basic module support
From: Ilya Ledvich
CL-SOM-iMX7 is a miniature System-on-Module (SoM) based on
Freescale i.MX7 System-on-Chip family.
http://www.compulab.co.il/products/computer-on-modules/cl-som-imx7-freescale-i-mx-7-system-on-module/
Add basic DT support for standalone module (without a carrier board):
* Memory configuration
* I2C2 bus
* PMIC
* UART1
Signed-off-by: Ilya Ledvich
Signed-off-by: Igor Grinberg
Acked-by: Rob Herring
---
v2: use generic node name for pmic (Thanks Rob).
Documentation/devicetree/bindings/arm/fsl.txt | 4 +
arch/arm/boot/dts/Makefile| 1 +
arch/arm/boot/dts/imx7d-cl-som-imx7.dts | 150 ++
3 files changed, 155 insertions(+)
create mode 100644 arch/arm/boot/dts/imx7d-cl-som-imx7.dts
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt
b/Documentation/devicetree/bindings/arm/fsl.txt
index 34c88b0..30b0ba1 100644
--- a/Documentation/devicetree/bindings/arm/fsl.txt
+++ b/Documentation/devicetree/bindings/arm/fsl.txt
@@ -53,6 +53,10 @@ i.MX6 Quad SABRE Automotive Board
Required root node properties:
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
+i.MX7D CL-SOM-iMX7 Board
+Required root node properties:
+- compatible = "compulab,cl-som-imx7", "fsl,imx7d";
+
Generic i.MX boards
---
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..83ed521 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -350,6 +350,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb
dtb-$(CONFIG_SOC_IMX7D) += \
+ imx7d-cl-som-imx7.dtb \
imx7d-sdb.dtb
dtb-$(CONFIG_SOC_LS1021A) += \
ls1021a-qds.dtb \
diff --git a/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
new file mode 100644
index 000..ba05198
--- /dev/null
+++ b/arch/arm/boot/dts/imx7d-cl-som-imx7.dts
@@ -0,0 +1,150 @@
+/*
+ * Support for CompuLab CL-SOM-iMX7 System-on-Module
+ *
+ * Copyright (C) 2015 CompuLab Ltd. - http://www.compulab.co.il/
+ * Author: Ilya Ledvich
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include
+#include "imx7d.dtsi"
+
+/ {
+ model = "CompuLab CL-SOM-iMX7";
+ compatible = "compulab,cl-som-imx7", "fsl,imx7d";
+
+ memory {
+ reg = <0x8000 0x1000>; /* 256 MB - minimal
configuration */
+ };
+};
+
+&cpu0 {
+ arm-supply = <&sw1a_reg>;
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ pmic: pmic@8 {
+ compatible = "fsl,pfuze3000";
+ reg = <0x08>;
+
+ regulators {
+ sw1a_reg: sw1a {
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <1475000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ /* use sw1c_reg to align with pfuze100/pfuze200 */
+ sw1c_reg: sw1b {
+ regulator-min-microvolt = <70>;
+ regulator-max-microvolt = <1475000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <6250>;
+ };
+
+ sw2_reg: sw2 {
+ regulator-min-microvolt = <150>;
+ regulator-max-microvolt = <185>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sw3a_reg: sw3 {
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <165>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <515>;
+ };
+
+ snvs_reg: vsnvs {
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <300>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vref_reg: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+
Re: [PATCH v2 1/2] usb: renesas_usbhs: add fallback compatibility strings
On Thu, Dec 10, 2015 at 07:28:06AM +, Kuninori Morimoto wrote:
>
> Hi Simon
>
> Thank you for your patch
>
> > Add fallback compatibility strings for R-Car Gen2 and Gen3.
> > This is in keeping with the fallback scheme being adopted wherever
> > appropriate for drivers for Renesas SoCs.
> >
> > Also add SoC names.
> >
> > Signed-off-by: Simon Horman
> > ---
> (snip)
> > Required properties:
> >- compatible: Must contain one of the following:
> > - - "renesas,usbhs-r8a7790"
> > - - "renesas,usbhs-r8a7791"
> > - - "renesas,usbhs-r8a7794"
> > - - "renesas,usbhs-r8a7795"
> > +
> > + - "renesas,usbhs-r8a7790" for r8a7790 (R-Car H2) compatible device
> > + - "renesas,usbhs-r8a7791" for r8a7791 (R-Car M2-W) compatible device
> > + - "renesas,usbhs-r8a7794" for r8a7794 (R-Car E2) compatible device
> > + - "renesas,usbhs-r8a7795" for r8a7795 (R-Car H3) compatible device
> > + - "renesas,rcar-gen2-usbhs" for R-Car Gen2 compatibile device
> > + - "renesas,rcar-gen3-usbhs" for R-Car Gen3 compatibile device
> > +
> > + When compatible with the generic version, nodes must list the
> > + SoC-specific version corresponding to the platform first followed
> > + by the generic version.
>
> I think these can be separated ?
>
> 1. document update for "renesas,usbhs-r8a77xx"
> 2. add new "rcar-genX" (this patch)
Sure, will do.
> > Example:
> > usbhs: usb@e659 {
> > - compatible = "renesas,usbhs-r8a7790";
> > + compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
>
> I think you want
>
> -compatible = "renesas,usbhs-r8a7790", "renesas,rcar-usbhs";
> +compatible = "renesas,usbhs-r8a7790", "renesas,rcar-gen2-usbhs";
Thanks, I will fix that.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: Add missing platform maintainers for dts files
On 12/10/2015 3:38 PM, Rob Herring wrote: diff --git a/MAINTAINERS b/MAINTAINERS index 69c8a9c..415b731 100644 --- a/MAINTAINERS +++ b/MAINTAINERS [..] @@ -1202,6 +1209,7 @@ M:Santosh Shilimkar L:linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S:Maintained F:arch/arm/mach-keystone/ +F: arch/arm/boot/dts/k2* T:git git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
