[PATCH] ARM: at91/dt: sama5d4: change watchdog compatible
Change the watchdog compatible to "atmel,sama5d4-wdt" to support
SAMA5D4 watchdog driver.
Signed-off-by: Wenyou Yang
---
arch/arm/boot/dts/sama5d4.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 15bbaf6..2193637 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -1300,7 +1300,7 @@
};
watchdog@fc068640 {
- compatible = "atmel,at91sam9260-wdt";
+ compatible = "atmel,sama5d4-wdt";
reg = <0xfc068640 0x10>;
clocks = <&clk32k>;
status = "disabled";
--
1.7.9.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] ARM: at91/dt: sama5d2: add watchdog node
Add watchdog node to support SAMA5D4 watchdog.
Signed-off-by: Wenyou Yang
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts |4
arch/arm/boot/dts/sama5d2.dtsi |7 +++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index e07c2b2..de3ef02 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -181,6 +181,10 @@
};
};
+ watchdog@f8048040 {
+ status = "okay";
+ };
+
uart3: serial@fc008000 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3_default>;
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index c1f0cba..c29ff70 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -929,6 +929,13 @@
clocks = <&h32ck>;
};
+ watchdog@f8048040 {
+ compatible = "atmel,sama5d4-wdt";
+ reg = <0xf8048040 0x10>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH 7>;
+ status = "disabled";
+ };
+
sckc@f8048050 {
compatible = "atmel,at91sam9x5-sckc";
reg = <0xf8048050 0x4>;
--
1.7.9.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 v7 6/6] ARM: dts: enable smp for rk3036
Enable smp for rk3036, and add the smp sram name for adapting.
---
Changes in v7:
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
arch/arm/boot/dts/rk3036.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
index 380fe10..61b40dd 100644
--- a/arch/arm/boot/dts/rk3036.dtsi
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -75,6 +75,7 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "rockchip,rk3036-smp";
cpu0: cpu@f00 {
device_type = "cpu";
@@ -157,6 +158,10 @@
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1008 0x2000>;
+ smp-sram@0 {
+ compatible = "rockchip,rk3066-smp-sram";
+ reg = <0x00 0x10>;
+ };
};
cru: clock-controller@2000 {
--
1.7.9.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 v7 5/6] ARM: dts: rockchip: add core rk3036 dts
Initial release for rk3036, node definitions rk3036 sdk board.
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
---
Changes in v7: None
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/rk3036-evb.dts | 64 +
arch/arm/boot/dts/rk3036.dtsi| 547 ++
3 files changed, 612 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3036-evb.dts
create mode 100644 arch/arm/boot/dts/rk3036.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..87c8752 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -512,6 +512,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
dtb-$(CONFIG_ARCH_REALVIEW) += \
arm-realview-pb1176.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += \
+ rk3036-evb.dtb \
rk3066a-bqcurie2.dtb \
rk3066a-marsboard.dtb \
rk3066a-rayeager.dtb \
diff --git a/arch/arm/boot/dts/rk3036-evb.dts b/arch/arm/boot/dts/rk3036-evb.dts
new file mode 100644
index 000..28a0336
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036-evb.dts
@@ -0,0 +1,64 @@
+/*
+ * 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 "rk3036.dtsi"
+
+/ {
+ model = "Rockchip RK3036 Evaluation board";
+ compatible = "rockchip,rk3036-evb", "rockchip,rk3036";
+};
+
+&i2c1 {
+ status = "okay";
+
+ hym8563: hym8563@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ clock-output-names = "xin32k";
+ };
+};
+
+&uart2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/rk3036.dtsi b/arch/arm/boot/dts/rk3036.dtsi
new file mode 100644
index 000..380fe10
--- /dev/null
+++ b/arch/arm/boot/dts/rk3036.dtsi
@@ -0,0 +1,547 @@
+/*
+ * 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 fol
[PATCH v7 2/6] clk: rockchip: add dt-binding header for rk3036
Add the dt-bindings header for the rk3036, that gets shared between the clock controller and the clock references in the dts. Signed-off-by: Xing Zheng Reviewed-by: Heiko Stuebner --- Changes in v7: None include/dt-bindings/clock/rk3036-cru.h | 193 1 file changed, 193 insertions(+) create mode 100644 include/dt-bindings/clock/rk3036-cru.h diff --git a/include/dt-bindings/clock/rk3036-cru.h b/include/dt-bindings/clock/rk3036-cru.h new file mode 100644 index 000..a2763a6 --- /dev/null +++ b/include/dt-bindings/clock/rk3036-cru.h @@ -0,0 +1,193 @@ +/* + * Copyright (c) 2015 Rockchip Electronics Co. Ltd. + * Author: Xing Zheng + * + * 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. + */ + +#ifndef _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H +#define _DT_BINDINGS_CLK_ROCKCHIP_RK3036_H + +/* core clocks */ +#define PLL_APLL 1 +#define PLL_DPLL 2 +#define PLL_GPLL 3 +#define ARMCLK 4 + +/* sclk gates (special clocks) */ +#define SCLK_GPU 64 +#define SCLK_SPI 65 +#define SCLK_SDMMC 68 +#define SCLK_SDIO 69 +#define SCLK_EMMC 71 +#define SCLK_NANDC 76 +#define SCLK_UART0 77 +#define SCLK_UART1 78 +#define SCLK_UART2 79 +#define SCLK_I2S 82 +#define SCLK_SPDIF 83 +#define SCLK_TIMER085 +#define SCLK_TIMER186 +#define SCLK_TIMER287 +#define SCLK_TIMER388 +#define SCLK_OTGPHY0 93 +#define SCLK_LCDC 100 +#define SCLK_HDMI 109 +#define SCLK_HEVC 111 +#define SCLK_I2S_OUT 113 +#define SCLK_SDMMC_DRV 114 +#define SCLK_SDIO_DRV 115 +#define SCLK_EMMC_DRV 117 +#define SCLK_SDMMC_SAMPLE 118 +#define SCLK_SDIO_SAMPLE 119 +#define SCLK_EMMC_SAMPLE 121 +#define SCLK_PVTM_CORE 123 +#define SCLK_PVTM_GPU 124 +#define SCLK_PVTM_VIDEO 125 +#define SCLK_MAC 151 +#define SCLK_MACREF152 +#define SCLK_SFC 160 + +/* aclk gates */ +#define ACLK_DMAC2 194 +#define ACLK_LCDC 197 +#define ACLK_VIO 203 +#define ACLK_VCODEC208 +#define ACLK_CPU 209 +#define ACLK_PERI 210 + +/* pclk gates */ +#define PCLK_GPIO0 320 +#define PCLK_GPIO1 321 +#define PCLK_GPIO2 322 +#define PCLK_GRF 329 +#define PCLK_I2C0 332 +#define PCLK_I2C1 333 +#define PCLK_I2C2 334 +#define PCLK_SPI 338 +#define PCLK_UART0 341 +#define PCLK_UART1 342 +#define PCLK_UART2 343 +#define PCLK_PWM 350 +#define PCLK_TIMER 353 +#define PCLK_HDMI 360 +#define PCLK_CPU 362 +#define PCLK_PERI 363 +#define PCLK_DDRUPCTL 364 +#define PCLK_WDT 368 +#define PCLK_ACODEC369 + +/* hclk gates */ +#define HCLK_OTG0 449 +#define HCLK_OTG1 450 +#define HCLK_NANDC 453 +#define HCLK_SDMMC 456 +#define HCLK_SDIO 457 +#define HCLK_EMMC 459 +#define HCLK_I2S 462 +#define HCLK_LCDC 465 +#define HCLK_ROM 467 +#define HCLK_VIO_BUS 472 +#define HCLK_VCODEC476 +#define HCLK_CPU 477 +#define HCLK_PERI 478 + +#define CLK_NR_CLKS(HCLK_PERI + 1) + +/* soft-reset indices */ +#define SRST_CORE0 0 +#define SRST_CORE1 1 +#define SRST_CORE0_DBG 4 +#define SRST_CORE1_DBG 5 +#define SRST_CORE0_POR 8 +#define SRST_CORE1_POR 9 +#define SRST_L2C 12 +#define SRST_TOPDBG13 +#define SRST_STRC_SYS_A14 +#define SRST_PD_CORE_NIU 15 + +#define SRST_TIMER216 +#define SRST_CPUSYS_H 17 +#define SRST_AHB2APB_H 19 +#define SRST_TIMER320 +#define SRST_INTMEM21 +#define SRST_ROM 22 +#define SRST_PERI_NIU 23 +#define SRST_I2S 24 +#define SRST_DDR_PLL 25 +#define SRST_GPU_DLL 26 +#define SRST_TIMER027 +#define SRST_TIMER128 +#define SRST_CORE_DLL 29 +#define SRST_EFUSE_P 30 +#define SRST_ACODEC_P
[PATCH v7 1/6] dt-bindings: add documentation of rk3036 clock controller
Add the devicetree binding for the cru on the rk3036 which quite similar
structured as previous clock controllers.
Signed-off-by: Xing Zheng
Reviewed-by: Heiko Stuebner
Acked-by: Rob Herring
---
Changes in v7: None
.../bindings/clock/rockchip,rk3036-cru.txt | 56
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
new file mode 100644
index 000..ace0599
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
@@ -0,0 +1,56 @@
+* Rockchip RK3036 Clock and Reset Unit
+
+The RK3036 clock controller generates and supplies clock to various
+controllers within the SoC and also implements a reset controller for SoC
+peripherals.
+
+Required Properties:
+
+- compatible: should be "rockchip,rk3036-cru"
+- reg: physical base address of the controller and length of memory mapped
+ region.
+- #clock-cells: should be 1.
+- #reset-cells: should be 1.
+
+Optional Properties:
+
+- rockchip,grf: phandle to the syscon managing the "general register files"
+ If missing pll rates are not changeable, due to the missing pll lock status.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. All available clocks are defined as
+preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
+used in device tree sources. Similar macros exist for the reset sources in
+these files.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xin24m" - crystal input - required,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_gmac" - external GMAC clock - optional
+
+Example: Clock controller node:
+
+ cru: cru@2000 {
+ compatible = "rockchip,rk3036-cru";
+ reg = <0x2000 0x1000>;
+ rockchip,grf = <&grf>;
+
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+Example: UART controller node that consumes the clock generated by the clock
+ controller:
+
+ uart0: serial@2006 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x2006 0x100>;
+ interrupts = ;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ clocks = <&cru SCLK_UART0>;
+ };
--
1.7.9.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 v7 0/6] Build and support rk3036 SoC platform
Hi, We need to support rk3036 soc platform via upstream, there are some primary parts for the initial release of minimum system: dts, clk-pll, smp, and clock tree for rk3036, and additional, we can use these startup and run to init processs. Thanks. Changed in v7: - removed the patch "make sure timer5 is enabled on rk3036 platforms" (applied) - removed the patch "add support smp for rk3036" (applied) Changed in v6: - add hardware timer in dtsi and some the aliases of basic modules Changed in v5: - don't use clk_ APIs in the pll init-callback Changed in v4: - add some basic IP modules on rk3036.dtsi - optimized supporting smp codes Changed in v3: - optimized some codes based on v2 - removed the patch "initial set time for rtc-hym8563" (useless) - removed the patch "pinctrl" (approved) Changed in v2: - based on v1, add clock controller documentation - enable timer5 startup - add smp for cpu1 - initial set time for rtc-hym8563 Changes in v1: - add dts, pinctrl and clock tree for rk3036 soc platform The patchset (6): 6) ARM: dts: enable smp for rk3036 5) ARM: dts: rockchip: add core rk3036 dts 4) clk: rockchip: add clock controller for rk3036 3) clk: rockchip: add new pll-type for rk3036 and similar socs 2) clk: rockchip: add dt-binding header for rk3036 1) dt-bindings: add documentation of rk3036 clock controller Changes in v7: Signed-off-by: Xing Zheng Reviewed-by: Heiko Stuebner Xing Zheng (6): dt-bindings: add documentation of rk3036 clock controller clk: rockchip: add dt-binding header for rk3036 clk: rockchip: add new pll-type for rk3036 and similar socs clk: rockchip: add clock controller for rk3036 ARM: dts: rockchip: add core rk3036 dts ARM: dts: enable smp for rk3036 .../bindings/clock/rockchip,rk3036-cru.txt | 56 ++ arch/arm/boot/dts/Makefile |1 + arch/arm/boot/dts/rk3036-evb.dts | 64 +++ arch/arm/boot/dts/rk3036.dtsi | 552 drivers/clk/rockchip/Makefile |1 + drivers/clk/rockchip/clk-pll.c | 249 - drivers/clk/rockchip/clk-rk3036.c | 478 + drivers/clk/rockchip/clk.h | 32 +- include/dt-bindings/clock/rk3036-cru.h | 193 +++ 9 files changed, 1624 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt create mode 100644 arch/arm/boot/dts/rk3036-evb.dts create mode 100644 arch/arm/boot/dts/rk3036.dtsi create mode 100644 drivers/clk/rockchip/clk-rk3036.c create mode 100644 include/dt-bindings/clock/rk3036-cru.h -- 1.7.9.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
Re: [RFCv2 2/2] rpi: add support to enable usb power domain
Hi Alexander,
i think this subject should better start with "ARM:".
Am 03.11.2015 um 23:45 schrieb Alexander Aring:
This patch adds support for RPi several Power Domains and enable support
to enable the USB Power Domain when it's not enabled before.
This patch based on Eric Anholt's patch to support Power Domains. He had
an issue about -EPROBE_DEFER inside the power domain subsystem, this
issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
if we fail to init or turn-on domain").
[...]
diff --git
a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
new file mode 100644
index 000..c3abc24
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-power.txt
@@ -0,0 +1,25 @@
+Raspberry Pi power domain driver
+
+Required properties:
+
+- compatible: Should be "raspberrypi,bcm2835-power".
+- firmware:Reference to the RPi firmware device node.
+- #power-domain-cells: Should be <1>, we providing multiple power domains.
+
+The valid defines for power domain are:
+
+ RPI_POWER_DOMAIN_USB
+
+Example:
+
+power: power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <&firmware>;
+ #power-domain-cells = <1>;
+};
+
+Example for using power domain:
+
+&usb {
+ power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
Refering to Documentation/devicetree/bindings/submitting-patches.txt
binding doc should be a separate patch.
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index ab5474e..d9b16d1 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,3 +1,4 @@
+#include
#include "bcm2835.dtsi"
/ {
@@ -20,6 +21,12 @@
compatible = "raspberrypi,bcm2835-firmware";
mboxes = <&mailbox>;
};
+
+ power: power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <&firmware>;
+ #power-domain-cells = <1>;
+ };
};
};
@@ -56,3 +63,7 @@
status = "okay";
bus-width = <4>;
};
+
+&usb {
+ power-domains = <&power RPI_POWER_DOMAIN_USB>;
+};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..3c899b3 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -149,7 +149,7 @@
status = "disabled";
};
- usb@7e98 {
+ usb: usb@7e98 {
compatible = "brcm,bcm2835-usb";
reg = <0x7e98 0x1>;
interrupts = <1 9>;
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 1319c3c..244475e5 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -120,6 +120,16 @@ config ARCH_BCM2835
This enables support for the Broadcom BCM2835 SoC. This SoC is
used in the Raspberry Pi and Roku 2 devices.
+config RASPBERRY_POWER
RASPBERRYPI_POWER?
+ bool "Raspberry Pi power domain driver"
+ depends on ARCH_BCM2835
+ depends on RASPBERRYPI_FIRMWARE
+ select PM_GENERIC_DOMAINS if PM
Since PM_GENERIC_DOMAINS_OF depends on PM_GENERIC_DOMAINS this line
should be redundant.
+ select PM_GENERIC_DOMAINS_OF if PM
+ help
+ This enables support for the RPi power domains which can be enabled
+ or disabled via the RPi firmware.
+
config ARCH_BCM_63XX
bool "Broadcom BCM63xx DSL SoC" if ARCH_MULTI_V7
depends on MMU
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 1780a3f..283295e 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -33,6 +33,7 @@ endif
# BCM2835
obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
+obj-$(CONFIG_RASPBERRY_POWER) += raspberrypi-power.o
# BCM5301X
obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o
diff --git a/arch/arm/mach-bcm/raspberrypi-power.c
b/arch/arm/mach-bcm/raspberrypi-power.c
new file mode 100644
index 000..531300f
--- /dev/null
+++ b/arch/arm/mach-bcm/raspberrypi-power.c
@@ -0,0 +1,180 @@
+/*
+ * 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.
+ *
+ * Authors:
+ * (C) 2015 Pengutronix, Alexander Aring
+ * Eric Anholt
+ */
+
+#include
+#include
+#include
+#include
Please sort alphabetical.
+#include
+#include
+
+#define RPI_POWER_DOMAIN(_domain, _name) \
+ [_domain] = { \
+ .domain = _domain, \
+ .enabled = true,\
+ .base = {
Re: [PATCH v4 4/6] reset: sunxi: Add Allwinner H3 bus resets
On Wed, 4 Nov 2015 08:30:14 -0800
Maxime Ripard wrote:
> Hi Arnd,
>
> On Fri, Oct 30, 2015 at 09:27:03AM +0100, Arnd Bergmann wrote:
> > On Tuesday 27 October 2015 17:50:24 Jens Kuske wrote:
> > >
> > > +static int sun8i_h3_bus_reset_xlate(struct reset_controller_dev *rcdev,
> > > + const struct of_phandle_args
> > > *reset_spec)
> > > +{
> > > + unsigned int index = reset_spec->args[0];
> > > +
> > > + if (index < 96)
> > > + return index;
> > > + else if (index < 128)
> > > + return index + 32;
> > > + else if (index < 160)
> > > + return index + 64;
> > > + else
> > > + return -EINVAL;
> > > +}
> > > +
> > >
> >
> > This looks like you are doing something wrong and should either
> > put the actual number into DT,
>
> This is the actual number, except that there's some useless registers
> in between. Allwinner documents it like that:
>
> 0x0 Reset 0
> 0x4 Reset 1
> 0xc Reset 2
>
> So we have to adjust the offset to account with the blank register in
> between (0x8).
>
> > or use a two-cell representation, with the first cell indicating the
> > block (0, 1 or 2), and the second cell the index.
>
> And the missing register is not a block either.
>
> That would also imply either changing the bindings of that driver (and
> all the current DTS that are using it), or introducing a whole new
> driver just to deal with some extraordinary offset calculation.
In the H3, the holes are not used, but what would occur if these holes
would be used for some other purpose in future SoCs? Double mapping?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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 2/5] spi: spi-ti-qspi: add mmap mode read support
On 11/04/2015 08:11 PM, Mark Brown wrote: > On Tue, Nov 03, 2015 at 03:36:11PM +0530, Vignesh R wrote: > >> +ti_qspi_enable_memory_map(spi); >> +ti_qspi_setup_mmap_read(spi, read_opcode, addr_width, >> +dummy_bytes); >> +memcpy_fromio(buf, qspi->mmap_base + from, len); >> +*retlen = len; >> +ti_qspi_disable_memory_map(spi); > > We'll be constantly enabling and disabling memory mapping with this. > I'm not sure that's a meaningful cost given that it doesn't actually > remap anything but rather just switches hardware modes, we can always > optimise it later if it is. > Hmm, I will move the ti_qspi_disable_memory_map() call to ti_qspi_start_transfer_one(), so that mmap mode is disabled only when normal SPI bus transfer is requested. Further, "mmap_enabled" status flag can be used to determine whether mode switch is required or not. This should help to overcome enabling and disabling memory mapping between successive mmap read requests. -- Regards Vignesh -- 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] mfd: arizona: Add DT binding for irq-gpios property
On 03/11/2015 17:52, Charles Keepax wrote: On Tue, Nov 03, 2015 at 03:04:50PM +, Mark Brown wrote: On Tue, Nov 03, 2015 at 03:10:06PM +0100, Sebastien Jan wrote: + - irq-gpios : GPIO specifier for the GPIO connected to /IRQ The platform data this is providing is essentially a workaround for the lack of an irq_to_gpio() function and the use of it is a workaround for the lack of level triggered IRQ emulation in genirq... do we really want this in the ABI (especially as a generic thing)? Personally I would rather not add this to the DT unless we really had to. Also are you sure this is necessary on your system? Specifically you only need this entry if the CODEC is connected to an IRQ line that only supports edge triggered IRQs. Mark, Charles, thanks for pointing me to this information. I don't have this specific constraint on my system and could finally also have it working using the regular interrupts / interrup-parent properties. So this new binding is not required for my case. I suppose we can forget about it. -- 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 RESEND 2/4] ARM: dts: add SMP support for Broadcom NSP
Add device tree changes required for providing SMP support
for Broadcom Northstar Plus SoC.
Signed-off-by: Kapil Hali
---
arch/arm/boot/dts/bcm-nsp.dtsi | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..d1875d9 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -40,24 +40,33 @@
model = "Broadcom Northstar Plus SoC";
interrupt-parent = <&gic>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "brcm,bcm-nsp-smp";
+ secondary-boot-reg = <0x042c>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ next-level-cache = <&L2>;
+ reg = <0x0>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ next-level-cache = <&L2>;
+ reg = <0x1>;
+ };
+ };
+
mpcore {
compatible = "simple-bus";
ranges = <0x 0x1902 0x3000>;
#address-cells = <1>;
#size-cells = <1>;
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- device_type = "cpu";
- compatible = "arm,cortex-a9";
- next-level-cache = <&L2>;
- reg = <0x0>;
- };
- };
-
L2: l2-cache {
compatible = "arm,pl310-cache";
reg = <0x2000 0x1000>;
--
2.1.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
[PATCH RESEND 4/4] ARM: BCM: Add SMP support for Broadcom 4708
From: Jon Mason
Add SMP support for Broadcom's 4708 SoCs.
Signed-off-by: Jon Mason
Acked-by: Hauke Mehrtens
Tested-by: Hauke Mehrtens
Signed-off-by: Kapil Hali
---
arch/arm/boot/dts/bcm4708.dtsi | 2 ++
arch/arm/mach-bcm/Kconfig | 1 +
arch/arm/mach-bcm/Makefile | 3 +++
3 files changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm4708.dtsi b/arch/arm/boot/dts/bcm4708.dtsi
index 31141e8..22a41df 100644
--- a/arch/arm/boot/dts/bcm4708.dtsi
+++ b/arch/arm/boot/dts/bcm4708.dtsi
@@ -15,6 +15,8 @@
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ enable-method = "brcm,bcm-nsp-smp";
+ secondary-boot-reg = <0x0400>;
cpu@0 {
device_type = "cpu";
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 2e9dbb5..4fc8fa3 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -54,6 +54,7 @@ config ARCH_BCM_NSP
config ARCH_BCM_5301X
bool "Broadcom BCM470X / BCM5301X ARM SoC" if ARCH_MULTI_V7
select ARCH_BCM_IPROC
+ select HAVE_SMP
help
Support for Broadcom BCM470X and BCM5301X SoCs with ARM CPU cores.
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 36a4ca30..3ca1cf1 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -43,6 +43,9 @@ obj-$(CONFIG_ARCH_BCM2835)+= board_bcm2835.o
# BCM5301X
obj-$(CONFIG_ARCH_BCM_5301X) += bcm_5301x.o
+ifeq ($(CONFIG_ARCH_BCM_5301X),y)
+obj-$(CONFIG_SMP) += headsmp.o platsmp.o
+endif
# BCM63XXx
ifeq ($(CONFIG_ARCH_BCM_63XX),y)
--
2.1.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
[PATCH RESEND 1/4] dt-bindings: add SMP enable-method for Broadcom NSP
Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
Northstar Plus CPU to the 32-bit ARM CPU device tree binding
documentation file and create a new binding documentation for
Northstar Plus CPU pen-release mechanism.
Signed-off-by: Kapil Hali
---
.../bindings/arm/bcm/brcm,nsp-cpu-method.txt | 36 ++
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
2 files changed, 37 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
new file mode 100644
index 000..8506da7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
@@ -0,0 +1,36 @@
+Broadcom Northstar Plus SoC CPU Enable Method
+-
+This binding defines the enable method used for starting secondary
+CPUs in the following Broadcom SoCs:
+ BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
+
+The enable method is specified by defining the following required
+properties in the "cpus" device tree node:
+ - enable-method = "brcm,bcm-nsp-smp";
+ - secondary-boot-reg = <...>;
+
+The secondary-boot-reg property is a u32 value that specifies the
+physical address of the register used to request the ROM holding pen
+code release a secondary CPU.
+
+Example:
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "brcm,bcm-nsp-smp";
+ secondary-boot-reg = <0x042c>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ next-level-cache = <&L2>;
+ reg = <0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a9";
+ next-level-cache = <&L2>;
+ reg = <1>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
b/Documentation/devicetree/bindings/arm/cpus.txt
index 91e6e5c..6abe3f3 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -191,6 +191,7 @@ nodes to be present and contain the properties described
below.
"allwinner,sun8i-a23"
"arm,psci"
"brcm,brahma-b15"
+ "brcm,bcm-nsp-smp"
"marvell,armada-375-smp"
"marvell,armada-380-smp"
"marvell,armada-390-smp"
--
2.1.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
[PATCH RESEND 3/4] ARM: BCM: Add SMP support for Broadcom NSP
Add SMP support for Broadcom's Northstar Plus SoC,
cpu enable method and pen_release procedures. This
changes also consolidates iProc family's - BCM NSP
and BCM Kona, SMP handling in a common file.
Northstar Plus SoC is based on ARM Cortex-A9
revision r3p0 which requires configuration for ARM
Errata 764369 for SMP. This change adds the needed
configuration option.
Signed-off-by: Kapil Hali
---
arch/arm/mach-bcm/Kconfig | 2 +
arch/arm/mach-bcm/Makefile | 8 +-
arch/arm/mach-bcm/bcm_nsp.h | 19
arch/arm/mach-bcm/headsmp.S | 37
arch/arm/mach-bcm/{kona_smp.c => platsmp.c} | 142 ++--
5 files changed, 197 insertions(+), 11 deletions(-)
create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
create mode 100644 arch/arm/mach-bcm/headsmp.S
rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 1679fa4..2e9dbb5 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -40,6 +40,8 @@ config ARCH_BCM_NSP
select ARCH_BCM_IPROC
select ARM_ERRATA_754322
select ARM_ERRATA_775420
+ select ARM_ERRATA_764369 if SMP
+ select HAVE_SMP
help
Support for Broadcom Northstar Plus SoC.
Broadcom Northstar Plus family of SoCs are used for switching control
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index 892261f..36a4ca30 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -14,7 +14,11 @@
obj-$(CONFIG_ARCH_BCM_CYGNUS) += bcm_cygnus.o
# Northstar Plus
-obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
+obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
+
+ifeq ($(CONFIG_ARCH_BCM_NSP),y)
+obj-$(CONFIG_SMP) += headsmp.o platsmp.o
+endif
# BCM281XX
obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
@@ -23,7 +27,7 @@ obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
obj-$(CONFIG_ARCH_BCM_21664) += board_bcm21664.o
# BCM281XX and BCM21664 SMP support
-obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += kona_smp.o
+obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += platsmp.o
# BCM281XX and BCM21664 L2 cache control
obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
diff --git a/arch/arm/mach-bcm/bcm_nsp.h b/arch/arm/mach-bcm/bcm_nsp.h
new file mode 100644
index 000..58e1e80
--- /dev/null
+++ b/arch/arm/mach-bcm/bcm_nsp.h
@@ -0,0 +1,19 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __BCM_NSP_H
+#define __BCM_NSP_H
+
+extern void nsp_secondary_startup(void);
+
+#endif /* __BCM_NSP_H */
diff --git a/arch/arm/mach-bcm/headsmp.S b/arch/arm/mach-bcm/headsmp.S
new file mode 100644
index 000..0da13b2
--- /dev/null
+++ b/arch/arm/mach-bcm/headsmp.S
@@ -0,0 +1,37 @@
+/*
+ * Copyright (C) 2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+
+/*
+ * iProc specific entry point for secondary CPUs. This provides
+ * a "holding pen" into which all secondary cores are held until
+ * we are ready for them to initialise.
+ */
+ENTRY(nsp_secondary_startup)
+ mrc p15, 0, r0, c0, c0, 5
+ and r0, r0, #15
+ adr r4, 1f
+ ldmia r4, {r5, r6}
+ sub r4, r4, r5
+ add r6, r6, r4
+pen: ldr r7, [r6]
+ cmp r7, r0
+ bne pen
+
+ bsecondary_startup
+
+1: .long .
+ .long pen_release
+
+ENDPROC(nsp_secondary_startup)
diff --git a/arch/arm/mach-bcm/kona_smp.c b/arch/arm/mach-bcm/platsmp.c
similarity index 63%
rename from arch/arm/mach-bcm/kona_smp.c
rename to arch/arm/mach-bcm/platsmp.c
index 66a0465..619030e 100644
--- a/arch/arm/mach-bcm/kona_smp.c
+++ b/arch/arm/mach-bcm/platsmp.c
@@ -1,5 +1,5 @@
/*
- * Copyright (C) 2014 Broadcom Corporation
+ * Copyright (C) 2014-2015 Broadcom Corporation
* Copyright 2014 Linaro Limited
*
* This program is free software; you can redistribute it and/or
@@ -12,16 +12,23 @@
* GNU General Public License for more details.
*/
-#include
+#include
+#include
#include
+#include
#include
+#include
#inclu
[PATCH RESEND 0/4] SMP support for Broadcom NSP
Hi,
This series adds SMP support for Broadcom's Northstar Plus SoC.
There are similar SMP enablement methods for many ARMv7 bsed SoCs.
BCM NSP SoC, has a typical such mechanism - after power-on, the
secondary core is held in a standby state, primary core provides a
startup address for the secondary core and wakes it up. Booting of
the secondary core is serialized using pen_release global variable.
The startup address is programmed at a special register location
which is defined in the device tree using a "secondary-boot-reg"
property in a node whose "enable-method" property matches.
The first patch adds cpu-enable-method in the device tree bindings
documentation. It also updates ARM CPU device tree documentation
with Broadcom Northstar Plus CPU details.
The second patch adds SMP support to the BCM NSP device tree file.
The third patch, enables SMP on BCM NSP. It also consolidates
common SMP handling between BCM NSP and BCM Kona.
The final patch, enables SMP on BCM 4708 and this patch is pulled
in from Jon Mason's patch from the mailing list.
This patch series is constructed based on Linux v4.3-rc2.
The source code is available at GITHUB:
https://github.com/Broadcom/cygnus-linux/tree/nsp-smp-v1
Jon Mason (1):
ARM: BCM: Add SMP support for Broadcom 4708
Kapil Hali (3):
dt-bindings: add SMP enable-method for Broadcom NSP
ARM: dts: add SMP support for Broadcom NSP
ARM: BCM: Add SMP support for Broadcom NSP
.../bindings/arm/bcm/brcm,nsp-cpu-method.txt | 36 ++
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
arch/arm/boot/dts/bcm-nsp.dtsi | 33 +++--
arch/arm/boot/dts/bcm4708.dtsi | 2 +
arch/arm/mach-bcm/Kconfig | 3 +
arch/arm/mach-bcm/Makefile | 11 +-
arch/arm/mach-bcm/bcm_nsp.h| 19 +++
arch/arm/mach-bcm/headsmp.S| 37 ++
arch/arm/mach-bcm/{kona_smp.c => platsmp.c}| 142 +++--
9 files changed, 261 insertions(+), 23 deletions(-)
create mode 100644
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
create mode 100644 arch/arm/mach-bcm/headsmp.S
rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)
--
2.1.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 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node
On 05.11.2015 14:37, Alim Akhtar wrote:
> Hi Krzysztof
>
> On 11/02/2015 07:22 PM, Krzysztof Kozlowski wrote:
>> 2015-11-02 22:01 GMT+09:00 Alim Akhtar :
>
>arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 349
> +++
>1 file changed, 349 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 838a3626dac1..8ce04a0ec928 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -53,6 +53,355 @@
> status = "okay";
>};
>
> +&hsi2c_4 {
> + samsung,i2c-sda-delay = <100>;
> + samsung,i2c-max-bus-freq = <20>;
> + status = "okay";
> +
> + s2mps15_pmic@66 {
> + compatible = "samsung,s2mps15-pmic";
> + reg = <0x66>;
> + interrupts = <2 0>;
> + interrupt-parent = <&gpa0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_irq>;
> + wakeup-source;
> +
> + s2mps15_osc: clocks {
> + compatible = "samsung,s2mps13-clk";
> + #clock-cells = <1>;
> + clock-output-names = "s2mps13_ap",
> "s2mps13_cp",
> + "s2mps13_bt";
> + };
Don't you want to use one of these clocks for s3c-rtc (&rtc node)?
>>> yes, you are right, rtc on this board is currently broken, mainly
>>> because of
>>> the introduction of rtc_src clock in the s3c-rtc driver.
>>> That is on my do list next. will take a look.
>>>
>>> Are you suggesting to remove this -clk node now and add along with rtc
>>> changes? I feel this should go in along with this patch.
>>
>> Just add it in consecutive patch in this series. You added here some
>> providers (clock and regulators) without consumers. This of course
>> looks good as a way of providing full description of the board but:
>> 1. For regulators always on: may be meaningless for kernel. Kernel
>> does not use it. Existence of regulator subnode will fulfill driver's
>> needs for probe.
>> 2. For clocks: actually will disable these clocks because of lack of
>> consumers... which is fine but probably not what you wanted.
>>
>> The standard approach is to add such providers when they are needed -
>> there are some consumers using them.
>>
> OK. for now will keep the pmic clock added as clock will be in disabled
> state, so it wont harm.
> - will keep system related regulator like supply to arm,mif,int etc ..
> will remove supplies to other peripherals IPs. Hope thats fine.
You don't have to remove other regulators (these without consumers).
Describe in DT all of regulators but:
1. Add to some of them consumers;
2. Disable these which are not needed (by not marking always-enabled).
Just like for all other boards.
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 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node
Hi Krzysztof
On 11/02/2015 07:22 PM, Krzysztof Kozlowski wrote:
2015-11-02 22:01 GMT+09:00 Alim Akhtar :
arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 349
+++
1 file changed, 349 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
index 838a3626dac1..8ce04a0ec928 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
+++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
@@ -53,6 +53,355 @@
status = "okay";
};
+&hsi2c_4 {
+ samsung,i2c-sda-delay = <100>;
+ samsung,i2c-max-bus-freq = <20>;
+ status = "okay";
+
+ s2mps15_pmic@66 {
+ compatible = "samsung,s2mps15-pmic";
+ reg = <0x66>;
+ interrupts = <2 0>;
+ interrupt-parent = <&gpa0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq>;
+ wakeup-source;
+
+ s2mps15_osc: clocks {
+ compatible = "samsung,s2mps13-clk";
+ #clock-cells = <1>;
+ clock-output-names = "s2mps13_ap", "s2mps13_cp",
+ "s2mps13_bt";
+ };
Don't you want to use one of these clocks for s3c-rtc (&rtc node)?
yes, you are right, rtc on this board is currently broken, mainly because of
the introduction of rtc_src clock in the s3c-rtc driver.
That is on my do list next. will take a look.
Are you suggesting to remove this -clk node now and add along with rtc
changes? I feel this should go in along with this patch.
Just add it in consecutive patch in this series. You added here some
providers (clock and regulators) without consumers. This of course
looks good as a way of providing full description of the board but:
1. For regulators always on: may be meaningless for kernel. Kernel
does not use it. Existence of regulator subnode will fulfill driver's
needs for probe.
2. For clocks: actually will disable these clocks because of lack of
consumers... which is fine but probably not what you wanted.
The standard approach is to add such providers when they are needed -
there are some consumers using them.
OK. for now will keep the pmic clock added as clock will be in disabled
state, so it wont harm.
- will keep system related regulator like supply to arm,mif,int etc ..
will remove supplies to other peripherals IPs. Hope thats fine.
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "vdd_ldo1";
+ regulator-min-microvolt = <50>;
+ regulator-max-microvolt = <90>;
+ regulator-always-on;
+ regulator-enable-ramp-delay = <125>;
+ };
(...)
+
+ buck10_reg: BUCK10 {
+ regulator-name = "vdd_buck10";
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <300>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <25000>;
+ regulator-enable-ramp-delay = <250>;
+ };
All of these ldo3 and bucks in vendor tree for Espresso board have
ramp delay of 12000. Also they don't have enable-ramp-delay set and
voltages sometimes differ. I don't have S2MPS15 datasheet so I don't
know what is the true value... I'll leave it up to you but it looks
suspicious.
These values generally comes from our board design team, so I cann't really
comment on that, it may vary from board revision etc.
I will check if we have any updated version of recommended value and update
accordingly.
Okay, just pointing the difference. I cannot verify them.
+ };
+ };
+};
What will be the benefit of defining all of these regulators if they
are always on and without consumers? No one will disable them, no one
will change the voltage. Please provide some consumers.
As many drivers are not yet enabled in arm64 defconfig, that is one of the
reason why we are not seeing many consumer for these nodes.
That is not a problem. Please send a patch changing the defconfig.
Usually defconfig (for armv7 this would be exynos and multi_v7) should
provide bootable and working environment for all of our supported
boards.
This is the ground work being done for enabling those. If you insist will
try to reduce what is being used now. Moreover this was used to verify
functionality of pmic driver as well.
Actually as a verification I think even adding simple node
"regulators" is sufficient - driver will add all regulators anyway.
However seeing all regulators described for particular board is
good... but lack of consumers is disturbing because this ma
Re: IIO device indexing issue
On 5/11/2015 9:25 AM, Phil Reid wrote:
On 5/11/2015 2:53 AM, Vesa Jääskeläinen wrote:
On 04/11/15 11:38, Lars-Peter Clausen wrote:
On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
Hi,
When we were using kernel 3.2 and with that board files we just got
IIO
devices with static order so that we knew exactly what iio:device0 is.
Now with device tree that order is not so static anymore especially
when
using device overlays (have not yet tried that thou). If there
would be
deferred probe for the device then if we have multiple iio:device's
then
those could in theory be in any order.
In example libiio uses iio device index to open the IIO device. So the
problem is to know what iio:device is what.
If we look files under /sys/bus/iio/iio:deviceX. They do not reveal
what
device this is (especially if there are multiple device of same
type). There
does not seem to be a way to give custom name for the iio device
from device
tree that could have been used as a cue.
Device tree aliases kinda sounded a good idea to try. Eg. define
adc0 alias
and then link it to actual device node in tree.
Aliases could be found under /proc/device-tree/aliases. Looking at
it shows
what device tree node it is. However there does not seem to be
actual link
from any /proc/device-tree entries to kernel drivers exposed under
sysfs.
And even the path components in device tree are not in same format
as in
sysfs. So there is no 1:1 mapping possible here.
IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
devices under /sys/devices and from there is physical path to the
device and
under that the IIO device with the same name as is under /sys/bus/iio.
So in theory we could make a mapping configuration file that specifies
logical name for iio device and then physical parent path for the
device and
then find under it iio:device* files to determine what is the iio
device
index for this physical device. Then open IIO device with that
index in
example with libiio. Sounds a bit complex?
So did we miss something on how this should be defined/accessed or
is there
a slight issue here on how to identify iio devices?
Don't know how device tree overlays affect this if we first load
device tree
overlay with some configuration and then unload it and load another
one with
different configuration.
Hi,
Yes, excellent analysis. This is a real issue. As you said there is no
guarantee that the IIO device numbers are stable, they are assigned
in the
order the devices are registered. If the device are registered in a
different order for whatever reason the numbers will change. You can
use
readlink on the IIO device in /sys/bus/iio/devices to get its
position in
the global device topology and be able to tell what the parent
device is,
but this path might not be completely stable either though. E.g. if
your
device is on a I2C bus and the number of the I2C bus is dynamically
assigned
it might change when the probe order changes.
Alias seem to be one way to solve this issue. The big question
remains is
how to communicate the alias to userspace. For other device classes the
alias index is used as the device index e.g. a device with alias
i2c0 ends
up being the i2c adapter with index 0. But with IIO where we support
a wide
range of different devices that does not really work. E.g. what to
do if you
have adc0 and dac0 as aliases for different devices. So you'd need a
different way to expose the alias.
Some bindings also use the "label" property to assign a unique name
to node.
But again the same issue how to expose that information to
applications.
To continue from this "label" property idea I was wondering if we
would add it as new optional(?) file node for IIO devices.
One could then specify it like:
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
...
am335x_adc: adc {
compatible = "ti,am3359-adc";
...
label = "Port A";
};
};
And this would generate file /sys/bus/iio/iio:deviceX/label with
contents of "Port A".
Then during the application startup it would just need to scan all
devices under /sys/bus/iio and determine what labelled device it
wants to use.
It would be up to device's developer to determine what labels to use
in their designs. This would not break ABI and would be just an
extension for it.
One could also auto-assign label "am335x_adc" in this case too. But
if you include existing arch device tree then changing label in top
level is kinda a bit annoying as you would then need to duplicate all
properties with another label and disable arch device tree's
settings. Could cause also conflict if there are references elsewhere
to existing arch nodes.
Having following in device's device tree file would allow one to
override label or just only specify that.
#include "am33xx.dtsi"
&tscadc {
status = "okay";
adc {
ti,adc-channels = <4 5 6 7>;
label = "Port A";
};
};
I think this "label" model w
[PATCH 1/2 V2] ls2080a/dts: Add little endian property for GPIO IP block
The GPIO block for ls2080a platform has little endian registers, the GPIO driver needs this property to read/write registers by right interface. Signed-off-by: Liu Gang --- V2 changes: No Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 3 +++ arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 4 2 files changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt index f2455c5..c836dab 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt @@ -10,6 +10,9 @@ Required properties: the second cell is used to specify the gpio polarity: 0 = active high 1 = active low +- little-endian : Should be set if the GPIO has little endian + registers. No the property means the GPIO + registers are big endian mode. Example: diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi index e81cd48..0099205 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi @@ -277,6 +277,7 @@ reg = <0x0 0x230 0x0 0x1>; interrupts = <0 36 0x4>; /* Level high type */ gpio-controller; + little-endian; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; @@ -287,6 +288,7 @@ reg = <0x0 0x231 0x0 0x1>; interrupts = <0 36 0x4>; /* Level high type */ gpio-controller; + little-endian; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; @@ -297,6 +299,7 @@ reg = <0x0 0x232 0x0 0x1>; interrupts = <0 37 0x4>; /* Level high type */ gpio-controller; + little-endian; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; @@ -307,6 +310,7 @@ reg = <0x0 0x233 0x0 0x1>; interrupts = <0 37 0x4>; /* Level high type */ gpio-controller; + little-endian; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; -- 2.1.0.27.g96db324 -- 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/9] dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible
This patchset attempts to new compatible for thermal founding on RK3368 SoCs. Signed-off-by: Caesar Wang --- Changes in v2: None Changes in v1: - %s/thermal/rockchip-thermal in subject. Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index b38200d..0dfa60d 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -1,7 +1,9 @@ * Temperature Sensor ADC (TSADC) on rockchip SoCs Required properties: -- compatible : "rockchip,rk3288-tsadc" +- compatible : should be "rockchip,-tsadc" + "rockchip,rk3288-tsadc": found on RK3288 SoCs + "rockchip,rk3368-tsadc": found on RK3368 SoCs - reg : physical base address of the controller and length of memory mapped region. - interrupts : The interrupt number to the cpu. The interrupt specifier format -- 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 v2 9/9] arm64: dts: Enable the Thermal on R88 board
This patch enable the TS-ADC.
When a thermal temperature is invoked use the CRU to reset the chip
on R88 board. TSHUT is low active on this board.
Signed-off-by: Caesar Wang
---
Changes in v2: None
Changes in v1: None
arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index 401a812..7684426a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
@@ -336,6 +336,12 @@
status = "okay";
};
+&tsadc {
+ rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */
+ status = "okay";
+}
+
&uart2 {
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 v2 7/9] arm64: dts: Add the thermal data found on RK3368
This patchset add the thermal for RK3368 dts,
Since the two CPU clusters, with four CPU core for each cluster,
One cluster is optimized for high-performance(big cluster) and the othe
is optimized for low power(little cluster).
This patch adds the second order for thermal throttle, and the critical
temperature for thermal over-tempeature protection on Software.
Signed-off-by: Caesar Wang
---
Changes in v2: None
Changes in v1: None
arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi | 112 +++
1 file changed, 112 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi
b/arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi
new file mode 100644
index 000..a10010f
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3368-thermal.dtsi
@@ -0,0 +1,112 @@
+/*
+ * Device Tree Source for RK3368 SoC thermal
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ * Caesar Wang
+ *
+ * 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
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = <100>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
+
+ thermal-sensors = <&tsadc 0>;
+
+ trips {
+ cpu_alert0: cpu_alert0 {
+ temperature = <75000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ cpu_alert1: cpu_alert1 {
+ temperature = <8>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ cpu_crit: cpu_crit {
+ temperature = <95000>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&cpu_b0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ map1 {
+ trip = <&cpu_alert1>;
+ cooling-device =
+ <&cpu_l0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+gpu_thermal: gpu_thermal {
+ polling-delay-passive = <100>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
+
+ thermal-sensors = <&tsadc 1>;
+
+ trips {
+ gpu_alert0: gpu_alert0 {
+ temperature = <8>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ gpu_crit: gpu_crit {
+ temperature = <115>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
[PATCH v2 8/9] arm64: dts: Add main Thermal info to rk3368.dtsi
This patch add the thermal needed info on RK3368.
Meanwhile, support the trips to throttle for thermal.
Signed-off-by: Caesar Wang
---
Changes in v2:
- fix a copy wrong name.
Series-changes: 1
- support the opt gpio pinctrl state
Changes in v1: None
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
index cc093a4..83a2bd2 100644
--- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
/ {
compatible = "rockchip,rk3368";
@@ -123,6 +124,8 @@
reg = <0x0 0x0>;
cpu-idle-states = <&cpu_sleep>;
enable-method = "psci";
+
+ #cooling-cells = <2>; /* min followed by max */
};
cpu_l1: cpu@1 {
@@ -155,6 +158,8 @@
reg = <0x0 0x100>;
cpu-idle-states = <&cpu_sleep>;
enable-method = "psci";
+
+ #cooling-cells = <2>; /* min followed by max */
};
cpu_b1: cpu@101 {
@@ -404,6 +409,27 @@
status = "disabled";
};
+ thermal-zones {
+ #include "rk3368-thermal.dtsi"
+ };
+
+ tsadc: tsadc@ff28 {
+ compatible = "rockchip,rk3368-tsadc";
+ reg = <0x0 0xff28 0x0 0x100>;
+ interrupts = ;
+ clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ resets = <&cru SRST_TSADC>;
+ reset-names = "tsadc-apb";
+ pinctrl-names = "init", "default", "sleep";
+ pinctrl-0 = <&otp_gpio>;
+ pinctrl-1 = <&otp_out>;
+ pinctrl-2 = <&otp_gpio>;
+ #thermal-sensor-cells = <1>;
+ rockchip,hw-tshut-temp = <95000>;
+ status = "disabled";
+ };
+
gmac: ethernet@ff29 {
compatible = "rockchip,rk3368-gmac";
reg = <0x0 0xff29 0x0 0x1>;
@@ -829,6 +855,16 @@
};
};
+ tsadc {
+ otp_gpio: otp-gpio {
+ rockchip,pins = <0 10 RK_FUNC_GPIO
&pcfg_pull_none>;
+ };
+
+ otp_out: otp-out {
+ rockchip,pins = <0 10 RK_FUNC_1
&pcfg_pull_none>;
+ };
+ };
+
uart0 {
uart0_xfer: uart0-xfer {
rockchip,pins = <2 24 RK_FUNC_1 &pcfg_pull_up>,
--
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 v2 0/9] Better compatible for the rockchip thermal and support RK3368 SoCs
This series patchs are working for RK3368 on Rockchip platform. @Heiko, The PATCH [5/6] is working based on big/littel cluster cpufreq added. Anyway, the PATCH [5/6] also work for next kernel. @Eduardo, This patchset are based on linus master branch. Note: Need add the following thermal patchs for thermal driver before apply this series patchs. 1) thermal: rockchip: fix handling of invalid readings (https://patchwork.kernel.org/patch/6973101/) 2) thermal: rockhip: fix setting thermal shutdown polarity (https://patchwork.kernel.org/patch/6973131/) 3) dt-bindings: rockchip-thermal: Add the pinctrl states in this document (https://patchwork.kernel.org/patch/7472021/) 4) thermal: rockchip: support the sleep pinctrl state to avoid glitches in s2r (https://patchwork.kernel.org/patch/7472051/) I'm glad these patchs have merged in thermal-soc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git the git log oneline my local branch as follows: 3e2c90b arm64: dts: Enable the Thermal on R88 board a33ee26 arm64: dts: Add main Thermal info to rk3368.dtsi fc051c9 arm64: dts: Add the thermal data found on RK3368 d6e7126 thermal: rockchip: Support the RK3368 SoCs in thermal drivers d16eb7f thermal: rockchip: Add the flag for adc value increment or decrement acc3ead thermal: rockchip: improve the conversion function f295e0b thermal: rockchip: trivial: fix typo in commit 2291fc3 thermal: rockchip: better to compatible the driver for different SoCs e18e646 dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible 29eb0c7 thermal: rockchip: support the sleep pinctrl state to avoid glitches in s2r cf2100b dt-bindings: rockchip-thermal: Add the pinctrl states in this document 38e287b0 thermal: rockhip: fix setting thermal shutdown polarity ddee4a2 thermal: rockchip: fix handling of invalid readings 8a28d67 Merge tag 'powerpc-4.3-6' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux 977bf06 powerpc/dma: dma_set_coherent_mask() should not be GPL only a22c4d7 block: re-add discard_granularity and alignment checks 23d8827 Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm 3d0aa36 Merge branch 'for-linus' of git://git.kernel.dk/linux-block dc5bc3f Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 9e17f90 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux 174fd8d blkcg: fix incorrect read/write sync/async stat accounting 858e904 Merge tag 'iommu-fixes-v4.3-rc7' of .. This series are tested on RK3368 board. while true;do ls >/dev/null; done& while true; do grep "" /sys/class/thermal/thermal_zone[0-1]/temp; sleep .5; done & You can get the temperature form sensors. /sys/class/thermal/thermal_zone0/temp:27500 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:3 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:27500 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:3 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:25000 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:32500 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:3 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:22500 /sys/class/thermal/thermal_zone1/temp:32500 /sys/class/thermal/thermal_zone0/temp:25000 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:25000 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:22500 /sys/class/thermal/thermal_zone1/temp:3 /sys/class/thermal/thermal_zone0/temp:3 /sys/class/thermal/thermal_zone1/temp:32500 /sys/class/thermal/thermal_zone1/temp:32500 /sys/class/thermal/thermal_zone0/temp:32500 Changes in v2: - As Eduardo comments on patch v1, split in smaller changes. - make the conversion table in as a parameter both code_to_temp and temp_to_code function. Series-changes: 1 - As Dmitry comment, make the conversion table in as a parameter. - remove some unused, completed on other patchs. - fix a copy wrong name. Series-changes: 1 - support the opt gpio pinctrl state Changes in v1: - %s/thermal/rockchip-thermal in subject. - add a new patch for thermal driver to support more SoCs. Caesar Wang (9): dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible thermal: rockchip: better to compatible the driver for different SoCs thermal: rockchip: trivial: fix typo in commit thermal: rockchip: improve the conversion function thermal: rockchip: Add the flag for adc value increment or decrement thermal: rockchip: Support the RK3368 SoCs in thermal drivers arm64: dts: Add the thermal data found on RK3368 arm64: dts: Add main Thermal info to rk3368.dtsi arm64: dts: Enable the Thermal on R88 board .../bindings/thermal/rockch
Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
On 11/04/2015 05:59 PM, Timur Tabi wrote:
On Tue, Oct 27, 2015 at 11:06 AM, wrote:
+static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
+{
+ struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
+ struct watchdog_device *wdd = &gwdt->wdd;
+
+ /* We don't use pretimeout, trigger WS1 now */
+ if (!wdd->pretimeout)
+ sbsa_gwdt_set_wcv(wdd, 0);
So I'm still concerned about the fact this driver depends on an
interrupt handler in order to properly program the hardware. Unlike
some other devices, the SBSA watchdog does not need assistance to
reset on a timeout -- it is a "fire and forget" device. What happens
if there is a hard lockup, and interrupts no longer work?
Keep in mind that 99% of watchdog daemons will not enable the
pre-timeout feature because it's new.
Same here, really.
I would feel much more comfortable if the driver would just use the standard
watchdog timeout and live with (worst case) 20 seconds timeout for now.
This limitation will be gone once the infrastructure is in place to handle
such short timeouts in the watchdog core. Until then, I would argue that the
system designers asked for it if they really select the highest possible
clock rate.
Guenter
--
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/2] powerpc/fsl: Add PCI node in device tree of bsc9132qds
From: Harninder Rai
Signed-off-by: Harninder Rai
Signed-off-by: Minghuan Lian
Reviewed-by: Zang Tiefei-R61911
Reviewed-by: Kushwaha Prabhakar-B32579
Reviewed-by: Fleming Andrew-AFLEMING
Tested-by: Fleming Andrew-AFLEMING
Signed-off-by: Hou Zhiqiang
---
V3:
- Remove gerrit stuff.
V2:
- Remove property clock-frequency.
arch/powerpc/boot/dts/bsc9132qds.dts | 15 ++
arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi | 28 +++
arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi | 1 +
3 files changed, 44 insertions(+)
diff --git a/arch/powerpc/boot/dts/bsc9132qds.dts
b/arch/powerpc/boot/dts/bsc9132qds.dts
index 6cab106..940d719 100644
--- a/arch/powerpc/boot/dts/bsc9132qds.dts
+++ b/arch/powerpc/boot/dts/bsc9132qds.dts
@@ -29,6 +29,21 @@
soc: soc@ff70 {
ranges = <0x0 0x0 0xff70 0x10>;
};
+
+ pci0: pcie@ff70a000 {
+ reg = <0 0xff70a000 0 0x1000>;
+ ranges = <0x200 0x0 0x9000 0 0x9000 0x0 0x2000
+ 0x100 0x0 0x 0 0xc001 0x0 0x1>;
+ pcie@0 {
+ ranges = <0x200 0x0 0x9000
+ 0x200 0x0 0x9000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+ };
+ };
};
/include/ "bsc9132qds.dtsi"
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
index c723071..b5f0715 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
@@ -40,6 +40,34 @@
interrupts = <16 2 0 0 20 2 0 0>;
};
+/* controller at 0xa000 */
+&pci0 {
+ compatible = "fsl,bsc9132-pcie", "fsl,qoriq-pcie-v2.2";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0 255>;
+ interrupts = <16 2 0 0>;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0x0 0x0 0x1 &mpic 0x0 0x2 0x0 0x0
+ 0x0 0x0 0x2 &mpic 0x1 0x2 0x0 0x0
+ 0x0 0x0 0x3 &mpic 0x2 0x2 0x0 0x0
+ 0x0 0x0 0x4 &mpic 0x3 0x2 0x0 0x0
+ >;
+ };
+};
+
&soc {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
index 301a9db..90f7949 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
@@ -45,6 +45,7 @@
serial0 = &serial0;
ethernet0 = &enet0;
ethernet1 = &enet1;
+ pci0 = &pci0;
};
cpus {
--
2.1.0.27.g96db324
--
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] powerpc/85xx: Add PCIe controller support for bsc9132qds
From: Harninder Rai
1. Use machine_arch_initcall to hook mpc85xx_common_publish_devices
This can ensure before pcibios_init() is called, pci controllers have
been probed and added to the hose_list.
2. Add a workaround for errata A-005434
For the BSC9132, PEX_PEXIWARn[TRGT] for all windows defaults to 0xF,
which is mapped to CCSRBAR. However, for other products, 0xF is
mapped to the local memory. Therefore, for the BSC9132, any default
PCI Express access to the local memory (DDR) will now access the
CCSRBAR. This patch changes the mapping of targets of inbound windows
PEX_PEXIWARn[TRGT] to the Local address space – 0x0 (from 0xF).
Signed-off-by: Harninder Rai
Signed-off-by: Minghuan Lian
Signed-off-by: Hou Zhiqiang
---
V4: V3:
- Remove gerrit stuff.
arch/powerpc/platforms/85xx/bsc913x_qds.c | 8 +++-
arch/powerpc/sysdev/fsl_pci.c | 13 +
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/85xx/bsc913x_qds.c
b/arch/powerpc/platforms/85xx/bsc913x_qds.c
index f0927e5..dcfafd6 100644
--- a/arch/powerpc/platforms/85xx/bsc913x_qds.c
+++ b/arch/powerpc/platforms/85xx/bsc913x_qds.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "mpc85xx.h"
@@ -46,10 +47,12 @@ static void __init bsc913x_qds_setup_arch(void)
mpc85xx_smp_init();
#endif
+ fsl_pci_assign_primary();
+
pr_info("bsc913x board from Freescale Semiconductor\n");
}
-machine_device_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
+machine_arch_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -67,6 +70,9 @@ define_machine(bsc9132_qds) {
.probe = bsc9132_qds_probe,
.setup_arch = bsc913x_qds_setup_arch,
.init_IRQ = bsc913x_qds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index ebc1f412..b8607f6 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -193,6 +193,19 @@ static void setup_pci_atmu(struct pci_controller *hose)
const u64 *reg;
int len;
+ if (of_device_is_compatible(hose->dn, "fsl,bsc9132-pcie")) {
+ /*
+* BSC9132 Rev1.0 has an issue where all the PEX inbound
+* windows have implemented the default target value as 0xf
+* for CCSR space.In all Freescale legacy devices the target
+* of 0xf is reserved for local memory space. 9132 Rev1.0
+* now has local mempry space mapped to target 0x0 instead of
+* 0xf. Hence adding a workaround to remove the target 0xf
+* defined for memory space from Inbound window attributes.
+*/
+ piwar &= ~PIWAR_TGI_LOCAL;
+ }
+
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
if (in_be32(&pci->block_rev1) >= PCIE_IP_REV_2_2) {
win_idx = 2;
--
2.1.0.27.g96db324
--
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: [RFC v5 12/12] dt-bindings: hdmi-connector: add DDC I2C bus phandle documentation
On Wed, Nov 04, 2015 at 12:45:09PM +0100, Philipp Zabel wrote: > Add an optional ddc-i2c-bus phandle property that points to > an I2C master controller that handles the connector DDC pins. > > Signed-off-by: Philipp Zabel > --- > Documentation/devicetree/bindings/video/hdmi-connector.txt | 1 + This one will have to move to bindings/display/connector/ as well. Otherwise: Acked-by: Rob Herring > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt > b/Documentation/devicetree/bindings/video/hdmi-connector.txt > index acd5668..508aee4 100644 > --- a/Documentation/devicetree/bindings/video/hdmi-connector.txt > +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt > @@ -8,6 +8,7 @@ Required properties: > Optional properties: > - label: a symbolic name for the connector > - hpd-gpios: HPD GPIO number > +- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing > > Required nodes: > - Video port for HDMI input > -- > 2.6.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: [RFC v5 05/12] dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding
On Wed, Nov 04, 2015 at 12:45:02PM +0100, Philipp Zabel wrote:
> Add the device tree binding documentation for Mediatek HDMI,
> HDMI PHY and HDMI DDC devices.
>
> Signed-off-by: Philipp Zabel
Acked-by: Rob Herring
> ---
> Changes since v4:
> - Remove mediatek,cec and ddc-i2c-bus from hdmi node
> - Make output port required
> - Add mediatek, prefix to phy node current bias
>properties
> ---
> .../bindings/display/mediatek/mediatek,hdmi.txt| 142
> +
> 1 file changed, 142 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> new file mode 100644
> index 000..e3dde29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt
> @@ -0,0 +1,142 @@
> +Mediatek HDMI Encoder
> +=
> +
> +The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
> +its parallel input.
> +
> +Required properties:
> +- compatible: Should be "mediatek,-hdmi".
> +- reg: Physical base address and length of the controller's registers
> +- interrupts: The interrupt signal from the function block.
> +- clocks: device clocks
> + See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
> +- phys: phandle link to the HDMI PHY node.
> + See Documentation/devicetree/bindings/phy/phy-bindings.txt for details.
> +- phy-names: must contain "hdmi"
> +- mediatek,syscon-hdmi: phandle link and register offset to the system
> + configuration registers. For mt8173 this must be offset 0x900 into the
> + MMSYS_CONFIG region: <&mmsys 0x900>.
> +- ports: A node containing input and output port nodes with endpoint
> + definitions as documented in Documentation/devicetree/bindings/graph.txt.
> +- port@0: The input port in the ports node should be connected to a DPI
> output
> + port.
> +- port@1: The output port in the ports node should be connected to the input
> + port of a connector node that contains a ddc-i2c-bus property, or to the
> + input port of an attached bridge chip, such as a SlimPort transmitter.
> +
> +HDMI CEC
> +
> +
> +The HDMI CEC controller handles hotplug detection and CEC communication.
> +
> +Required properties:
> +- compatible: Should be "mediatek,-cec"
> +- reg: Physical base address and length of the controller's registers
> +- interrupts: The interrupt signal from the function block.
> +- clocks: device clock
> +
> +HDMI DDC
> +
> +
> +The HDMI DDC i2c controller is used to interface with the HDMI DDC pins.
> +The Mediatek's I2C controller is used to interface with I2C devices.
> +
> +Required properties:
> +- compatible: Should be "mediatek,-hdmi-ddc"
> +- reg: Physical base address and length of the controller's registers
> +- clocks: device clock
> +- clock-names: Should be "ddc-i2c".
> +
> +HDMI PHY
> +
> +
> +The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
> +output and drives the HDMI pads.
> +
> +Required properties:
> +- compatible: "mediatek,-hdmi-phy"
> +- reg: Physical base address and length of the module's registers
> +- clocks: PLL reference clock
> +- clock-names: must contain "pll_ref"
> +- #phy-cells: must be <0>.
> +
> +Optional properties:
> +- mediatek,ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
> +- mediatek,ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
> +
> +Example:
> +
> +cec: cec@10013000 {
> + compatible = "mediatek,mt8173-cec";
> + reg = <0 0x10013000 0 0xbc>;
> + interrupts = ;
> + clocks = <&infracfg CLK_INFRA_CEC>;
> +};
> +
> +hdmi_phy: hdmi-phy@10209100 {
> + compatible = "mediatek,mt8173-hdmi-phy";
> + reg = <0 0x10209100 0 0x24>;
> + clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>;
> + clock-names = "pll_ref";
> + mediatek,ibias = <0xa>;
> + mediatek,ibias_up = <0x1c>;
> + #phy-cells = <0>;
> +};
> +
> +hdmi_ddc0: i2c@11012000 {
> + compatible = "mediatek,mt8173-hdmi-ddc";
> + reg = <0 0x11012000 0 0x1c>;
> + interrupts = ;
> + clocks = <&pericfg CLK_PERI_I2C5>;
> + clock-names = "ddc-i2c";
> +};
> +
> +hdmi0: hdmi@14025000 {
> + compatible = "mediatek,mt8173-hdmi";
> + reg = <0 0x14025000 0 0x400>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_HDMI_PIXEL>,
> + <&mmsys CLK_MM_HDMI_PLLCK>,
> + <&mmsys CLK_MM_HDMI_AUDIO>,
> + <&mmsys CLK_MM_HDMI_SPDIF>;
> + clock-names = "pixel", "pll", "bclk", "spdif";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hdmi_pin>;
> + phys = <&hdmi_phy>;
> + phy-names = "hdmi";
> + mediatek,syscon-hdmi = <&mmsys 0x900>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port
RE: [PATCH 1/2 V2] ls2080a/dts: Add little endian property for GPIO IP block
Hi Gang, > From: Liu Gang [mailto:gang@freescale.com] > Sent: Thursday, November 05, 2015 8:12 AM > > The GPIO block for ls2080a platform has little endian registers, the GPIO > driver needs this property to read/write registers by right interface. > > Signed-off-by: Liu Gang > --- > V2 changes: No > > Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 3 +++ > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 4 > 2 files changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > index f2455c5..c836dab 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > @@ -10,6 +10,9 @@ Required properties: >the second cell is used to specify the gpio polarity: >0 = active high >1 = active low > +- little-endian : Should be set if the GPIO has little endian > + registers. No the property means the GPIO > + registers are big endian mode. Nitpick: I would suggest rewording this to the following, for better readability: +- little-endian : Should be set if the GPIO has little endian +registers. If this property is not set, then the GPIO +registers are configured in big endian mode. Regards, Bhupesh > > Example: > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > index e81cd48..0099205 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > @@ -277,6 +277,7 @@ > reg = <0x0 0x230 0x0 0x1>; > interrupts = <0 36 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > @@ -287,6 +288,7 @@ > reg = <0x0 0x231 0x0 0x1>; > interrupts = <0 36 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > @@ -297,6 +299,7 @@ > reg = <0x0 0x232 0x0 0x1>; > interrupts = <0 37 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > @@ -307,6 +310,7 @@ > reg = <0x0 0x233 0x0 0x1>; > interrupts = <0 37 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > -- > 2.1.0.27.g96db324 -- 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: [RFC v5 01/12] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
On Wed, Nov 04, 2015 at 12:44:58PM +0100, Philipp Zabel wrote:
> From: CK Hu
>
> Add device tree binding documentation for the display subsystem in
> Mediatek MT8173 SoCs.
>
> Signed-off-by: CK Hu
> Signed-off-by: Philipp Zabel
If this wasn't an RFC, I'd ack it. :) One thing you missed below though.
> ---
> Changes since v4:
> - Move device tree binding documentation to
>Documentation/devicetree/bindings/display/mediatek
> - Clarified display function block nodes are siblings to mmsys
> ---
> .../bindings/display/mediatek/mediatek,disp.txt| 183
> +
> .../bindings/display/mediatek/mediatek,dpi.txt | 35
> .../bindings/display/mediatek/mediatek,dsi.txt | 53 ++
> 3 files changed, 271 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
> create mode 100644
> Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> new file mode 100644
> index 000..cc3d884
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -0,0 +1,183 @@
> +Mediatek display subsystem
> +==
> +
> +The Mediatek display subsystem consists of various DISP function blocks in
> the
> +MMSYS register space. The connections between them can be configured by
> output
> +and input selectors in the MMSYS_CONFIG register space and register updates
> can
> +be synchronized to video frame boundaries with help of a DISP_MUTEX function
> +block.
> +
> +All DISP device tree nodes must be siblings to the central MMSYS_CONFIG node.
> +For a description of the MMSYS_CONFIG binding, see
> +Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt.
> +
> +DISP function blocks
> +
> +
> +A display stream starts at a source function block that reads pixel data from
> +memory and ends with a sink function block that drives pixels on a display
> +interface, or writes pixels back to memory. All DISP function blocks have
> +their own register space, interrupt, and clock gate. The blocks that can
> +access memory additionally have to list the IOMMU and local arbiter they are
> +connected to.
> +
> +For a description of the display interface sink function blocks, see
> +Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt and
> +Documentation/devicetree/bindings/drm/mediatek/mediatek,dpi.txt.
Need to update these paths.
> +
> +Required properties (all function blocks):
> +- compatible: "mediatek,-disp-", one of
> + "mediatek,-disp-ovl" - overlay (4 layers, blending, csc)
> + "mediatek,-disp-rdma" - read DMA / line buffer
> + "mediatek,-disp-wdma" - write DMA
> + "mediatek,-disp-color" - color processor
> + "mediatek,-disp-aal" - adaptive ambient light controller
> + "mediatek,-disp-gamma" - gamma correction
> + "mediatek,-disp-ufoe" - data compression engine
> + "mediatek,-dsi"- DSI controller, see mediatek,dsi.txt
> + "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
> + "mediatek,-disp-mutex" - display mutex
> + "mediatek,-disp-od"- overdrive
> +- reg: Physical base address and length of the function block register space
> +- interrupts: The interrupt signal from the function block.
> +- clocks: device clocks
> + See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- compatible: "mediatek,-ddp"
> +
> +Required properties (DMA function blocks):
> +- compatible: Should be one of
> + "mediatek,-disp-ovl"
> + "mediatek,-disp-rdma"
> + "mediatek,-disp-wdma"
> +- larb: Should contain a phandle pointing to the local arbiter device as
> defined
> + in Documentation/devicetree/bindings/soc/mediatek/mediatek,smi-larb.txt
> +- iommus: required a iommu node
> +
> +Examples:
> +
> +mmsys: clock-controller@1400 {
> + compatible = "mediatek,mt8173-mmsys", "syscon";
> + reg = <0 0x1400 0 0x1000>;
> + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
> + #clock-cells = <1>;
> +};
> +
> +ovl0: ovl@1400c000 {
> + compatible = "mediatek,mt8173-disp-ovl";
> + reg = <0 0x1400c000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_OVL0>;
> + iommus = <&iommu M4U_LARB0_ID M4U_PORT_DISP_OVL0>;
> + mediatek,larb = <&larb0>;
> +};
> +
> +ovl1: ovl@1400d000 {
> + compatible = "mediatek,mt8173-disp-ovl";
> + reg = <0 0x1400d000 0 0x1000>;
> + interrupts = ;
> + clocks = <&mmsys CLK_MM_DISP_OVL1>;
> + iommus = <&iommu M4U_LARB4_ID M4U_PORT_DISP_OVL1>;
> + mediatek,larb = <&larb4>;
> +};
> +
> +rdma0: rdma@1400e000 {
> + compatible = "mediatek,mt8173-disp-rdma";
> + reg = <0 0x1400e000 0 0x1000>;
> +
[PATCH V4 1/2] powerpc/fsl: Add PCI node in device tree of bsc9132qds
From: Harninder Rai
Signed-off-by: Harninder Rai
Signed-off-by: Minghuan Lian
Signed-off-by: Hou Zhiqiang
---
V4: V3:
- Remove gerrit stuff.
V2:
- Remove property clock-frequency.
arch/powerpc/boot/dts/bsc9132qds.dts | 15 ++
arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi | 28 +++
arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi | 1 +
3 files changed, 44 insertions(+)
diff --git a/arch/powerpc/boot/dts/bsc9132qds.dts
b/arch/powerpc/boot/dts/bsc9132qds.dts
index 6cab106..940d719 100644
--- a/arch/powerpc/boot/dts/bsc9132qds.dts
+++ b/arch/powerpc/boot/dts/bsc9132qds.dts
@@ -29,6 +29,21 @@
soc: soc@ff70 {
ranges = <0x0 0x0 0xff70 0x10>;
};
+
+ pci0: pcie@ff70a000 {
+ reg = <0 0xff70a000 0 0x1000>;
+ ranges = <0x200 0x0 0x9000 0 0x9000 0x0 0x2000
+ 0x100 0x0 0x 0 0xc001 0x0 0x1>;
+ pcie@0 {
+ ranges = <0x200 0x0 0x9000
+ 0x200 0x0 0x9000
+ 0x0 0x2000
+
+ 0x100 0x0 0x0
+ 0x100 0x0 0x0
+ 0x0 0x10>;
+ };
+ };
};
/include/ "bsc9132qds.dtsi"
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
index c723071..b5f0715 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-post.dtsi
@@ -40,6 +40,34 @@
interrupts = <16 2 0 0 20 2 0 0>;
};
+/* controller at 0xa000 */
+&pci0 {
+ compatible = "fsl,bsc9132-pcie", "fsl,qoriq-pcie-v2.2";
+ device_type = "pci";
+ #size-cells = <2>;
+ #address-cells = <3>;
+ bus-range = <0 255>;
+ interrupts = <16 2 0 0>;
+
+ pcie@0 {
+ reg = <0 0 0 0 0>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ #address-cells = <3>;
+ device_type = "pci";
+ interrupts = <16 2 0 0>;
+ interrupt-map-mask = <0xf800 0 0 7>;
+
+ interrupt-map = <
+ /* IDSEL 0x0 */
+ 0x0 0x0 0x1 &mpic 0x0 0x2 0x0 0x0
+ 0x0 0x0 0x2 &mpic 0x1 0x2 0x0 0x0
+ 0x0 0x0 0x3 &mpic 0x2 0x2 0x0 0x0
+ 0x0 0x0 0x4 &mpic 0x3 0x2 0x0 0x0
+ >;
+ };
+};
+
&soc {
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
index 301a9db..90f7949 100644
--- a/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/bsc9132si-pre.dtsi
@@ -45,6 +45,7 @@
serial0 = &serial0;
ethernet0 = &enet0;
ethernet1 = &enet1;
+ pci0 = &pci0;
};
cpus {
--
2.1.0.27.g96db324
--
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 1/8] dt-bindings: add documentation of rk3036 clock controller
On Wed, Nov 04, 2015 at 08:18:16PM +0800, Xing Zheng wrote:
> Add the devicetree binding for the cru on the rk3036 which quite similar
> structured as previous clock controllers.
>
> Signed-off-by: Xing Zheng
> Reviewed-by: Heiko Stuebner
Acked-by: Rob Herring
> ---
>
> Changes in v6: None
>
> .../bindings/clock/rockchip,rk3036-cru.txt | 56
>
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> new file mode 100644
> index 000..ace0599
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> @@ -0,0 +1,56 @@
> +* Rockchip RK3036 Clock and Reset Unit
> +
> +The RK3036 clock controller generates and supplies clock to various
> +controllers within the SoC and also implements a reset controller for SoC
> +peripherals.
> +
> +Required Properties:
> +
> +- compatible: should be "rockchip,rk3036-cru"
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- #clock-cells: should be 1.
> +- #reset-cells: should be 1.
> +
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> + If missing pll rates are not changeable, due to the missing pll lock
> status.
> +
> +Each clock is assigned an identifier and client nodes can use this identifier
> +to specify the clock which they consume. All available clocks are defined as
> +preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
> +used in device tree sources. Similar macros exist for the reset sources in
> +these files.
> +
> +External clocks:
> +
> +There are several clocks that are generated outside the SoC. It is expected
> +that they are defined using standard clock bindings with following
> +clock-output-names:
> + - "xin24m" - crystal input - required,
> + - "ext_i2s" - external I2S clock - optional,
> + - "ext_gmac" - external GMAC clock - optional
> +
> +Example: Clock controller node:
> +
> + cru: cru@2000 {
> + compatible = "rockchip,rk3036-cru";
> + reg = <0x2000 0x1000>;
> + rockchip,grf = <&grf>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> +Example: UART controller node that consumes the clock generated by the clock
> + controller:
> +
> + uart0: serial@2006 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x2006 0x100>;
> + interrupts = ;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&cru SCLK_UART0>;
> + };
> --
> 1.7.9.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
Re: [PATCH v6 6/8] ARM: rockchip: add support smp for rk3036
On Wed, Nov 04, 2015 at 08:25:16PM +0800, Xing Zheng wrote:
> From: Heiko Stuebner
>
> The dual-core Cortex A7 rk3036 is a bit special in that it does not allow
> to control the actual powerdomain of the cpu cores, while the rest of the
> smp-bringup like reset control and entry address handling stays the same.
> Its bigger sibling, the quad-core rk3128 again allows powerdomain control.
>
> So allow that case by introducing a separate smp-enable-method, that simply
> disables powerdomain handling in the common code.
>
> Signed-off-by: Heiko Stuebner
> Tested-by: Xing Zheng
> Signed-off-by: Xing Zheng
> ---
>
> Changes in v6: None
>
> Documentation/devicetree/bindings/arm/cpus.txt |1 +
Acked-by: Rob Herring
> arch/arm/mach-rockchip/platsmp.c | 45
> +---
> 2 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3a07a87..8fb0749 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -200,6 +200,7 @@ nodes to be present and contain the properties described
> below.
> "qcom,gcc-msm8660"
> "qcom,kpss-acc-v1"
> "qcom,kpss-acc-v2"
> + "rockchip,rk3036-smp"
> "rockchip,rk3066-smp"
> "ste,dbx500-smp"
>
> diff --git a/arch/arm/mach-rockchip/platsmp.c
> b/arch/arm/mach-rockchip/platsmp.c
> index 3e7a4b7..5c138f9 100644
> --- a/arch/arm/mach-rockchip/platsmp.c
> +++ b/arch/arm/mach-rockchip/platsmp.c
> @@ -42,6 +42,7 @@ static int ncores;
> #define PMU_PWRDN_SCU4
>
> static struct regmap *pmu;
> +static int has_pmu = true;
>
> static int pmu_power_domain_is_on(int pd)
> {
> @@ -89,20 +90,23 @@ static int pmu_set_power_domain(int pd, bool on)
> if (!IS_ERR(rstc) && !on)
> reset_control_assert(rstc);
>
> - ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
> - if (ret < 0) {
> - pr_err("%s: could not update power domain\n", __func__);
> - return ret;
> - }
> -
> - ret = -1;
> - while (ret != on) {
> - ret = pmu_power_domain_is_on(pd);
> + if (has_pmu) {
> + ret = regmap_update_bits(pmu, PMU_PWRDN_CON, BIT(pd), val);
> if (ret < 0) {
> - pr_err("%s: could not read power domain state\n",
> + pr_err("%s: could not update power domain\n",
> __func__);
> return ret;
> }
> +
> + ret = -1;
> + while (ret != on) {
> + ret = pmu_power_domain_is_on(pd);
> + if (ret < 0) {
> + pr_err("%s: could not read power domain
> state\n",
> +__func__);
> + return ret;
> + }
> + }
> }
>
> if (!IS_ERR(rstc)) {
> @@ -122,7 +126,7 @@ static int rockchip_boot_secondary(unsigned int cpu,
> struct task_struct *idle)
> {
> int ret;
>
> - if (!sram_base_addr || !pmu) {
> + if (!sram_base_addr || (has_pmu && !pmu)) {
> pr_err("%s: sram or pmu missing for cpu boot\n", __func__);
> return -ENXIO;
> }
> @@ -275,7 +279,7 @@ static void __init rockchip_smp_prepare_cpus(unsigned int
> max_cpus)
> return;
> }
>
> - if (rockchip_smp_prepare_pmu())
> + if (has_pmu && rockchip_smp_prepare_pmu())
> return;
>
> if (read_cpuid_part() == ARM_CPU_PART_CORTEX_A9) {
> @@ -318,6 +322,13 @@ static void __init rockchip_smp_prepare_cpus(unsigned
> int max_cpus)
> pmu_set_power_domain(0 + i, false);
> }
>
> +static void __init rk3036_smp_prepare_cpus(unsigned int max_cpus)
> +{
> + has_pmu = false;
> +
> + rockchip_smp_prepare_cpus(max_cpus);
> +}
> +
> #ifdef CONFIG_HOTPLUG_CPU
> static int rockchip_cpu_kill(unsigned int cpu)
> {
> @@ -340,6 +351,15 @@ static void rockchip_cpu_die(unsigned int cpu)
> }
> #endif
>
> +static struct smp_operations rk3036_smp_ops __initdata = {
> + .smp_prepare_cpus = rk3036_smp_prepare_cpus,
> + .smp_boot_secondary = rockchip_boot_secondary,
> +#ifdef CONFIG_HOTPLUG_CPU
> + .cpu_kill = rockchip_cpu_kill,
> + .cpu_die= rockchip_cpu_die,
> +#endif
> +};
> +
> static struct smp_operations rockchip_smp_ops __initdata = {
> .smp_prepare_cpus = rockchip_smp_prepare_cpus,
> .smp_boot_secondary = rockchip_boot_secondary,
> @@ -349,4 +369,5 @@ static struct smp_operations rockchip_smp_ops __initdata
> = {
> #endif
> };
>
> +CPU_METHOD_OF_DECLARE(rk3036_smp, "rockchip,rk3036-smp", &rk3036_smp_ops);
>
[PATCH v4 1/3] mtd: arasan: Add device tree binding documentation
This patch adds the dts binding document for arasan nand flash
controller.
Signed-off-by: Punnaiah Choudary Kalluri
---
Changes in v4:
- Added num-cs property
- Added clock support
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/mtd/arasan_nfc.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
new file mode 100644
index 000..02e1ce3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
@@ -0,0 +1,34 @@
+Arasan Nand Flash Controller with ONFI 3.1 support
+
+Required properties:
+- compatible: Should be "arasan,nfc-v3p10"
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain the interrupt for the device
+- clock-name: List of input clocks - "clk_sys", "clk_flash"
+ (See clock bindings for details)
+- clocks: Clock phandles (see clock bindings for details)
+
+Optional properties:
+- arasan,has-mdma: Enables Dma support
+- num-cs: Number of chip selects used
+
+for nand partition information please refer the below file
+Documentation/devicetree/bindings/mtd/partition.txt
+
+Example:
+ nand0: nand@ff10 {
+ compatible = "arasan,nfc-v3p10"
+ reg = <0x0 0xff10 0x1000>;
+ clock-name = "clk_sys", "clk_flash"
+ clocks = <&misc_clk &misc_clk>;
+ interrupt-parent = <&gic>;
+ interrupts = <0 14 4>;
+ arasan,has-mdma;
+ num-cs = <1>;
+ partition@0 {
+ label = "filesystem";
+ reg = <0x0 0x0 0x100>;
+ };
+ (...)
+ };
--
2.1.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 V2 2/5] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
On 04-11-15, 21:02, Rob Herring wrote: > > +- turbo-mode-: Named turbo-mode property. Similar to > > opp-microvolt- > > + property, but for turbo mode instead. > > + > > - opp-suspend: Marks the OPP to be used during device suspend. Only one > > OPP in > >the table should have this. > > > > +- opp-suspend-: Named opp-suspend property. Similar to > > + opp-microvolt- property, but for suspend opp instead. > > + > > I don't think these last 2 make sense. turbo-mode is a flag that the > mode has restrictions such as other cores have to be idle or something. > Similarly, opp-suspend should not vary by . Based on what version of the hardware you are running, via opp-supported-hw property, the platform can enable a different set of OPPs. And in that case we may want to select different OPPs marked as turbo or suspend freq. That's what I thought at least. For example, on version A of the hardware we have following available frequencies: 800, 1000, 1100, 1200 MHz. Where 800 MHz is the suspend freq and 1200 is the turbo one. But on a slightly different version of hardware B, we have two more OPPs available: 700 and 1400 MHz. And in that case we want the suspend freq to be 700 and turbo OPP to be only 1400 MHz. -- 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 V2 4/5] PM / OPP: Rename OPP nodes as opp@
On Thu, Nov 05, 2015 at 07:11:55AM +0530, Viresh Kumar wrote:
> It would be better to name OPP nodes as opp@ as that will ensure
> that multiple DT nodes don't contain the same frequency. Of course we
> expect the writer to name the node with its opp-hz frequency and not any
> other frequency.
>
> And that will let the compile error out if multiple nodes are using the
> same opp-hz frequency.
>
> Suggested-by: Stephen Boyd
> Reviewed-by: Stephen Boyd
> Signed-off-by: Viresh Kumar
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 38
> +--
> 1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt
> b/Documentation/devicetree/bindings/opp/opp.txt
> index 30c4bb3718bc..10ef08dc1b4c 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -183,20 +183,20 @@ Example 1: Single cluster Dual-core ARM cortex A9,
> switch DVFS states together.
> compatible = "operating-points-v2";
> opp-shared;
>
> - opp00 {
> + opp@10 {
> opp-hz = /bits/ 64 <10>;
> opp-microvolt = <97 975000 985000>;
> opp-microamp = <7>;
> clock-latency-ns = <30>;
> opp-suspend;
> };
> - opp01 {
> + opp@11 {
> opp-hz = /bits/ 64 <11>;
> opp-microvolt = <98 100 101>;
> opp-microamp = <8>;
> clock-latency-ns = <31>;
> };
> - opp02 {
> + opp@12 {
> opp-hz = /bits/ 64 <12>;
> opp-microvolt = <1025000>;
> clock-latency-ns = <29>;
> @@ -262,20 +262,20 @@ independently.
>* independently.
>*/
>
> - opp00 {
> + opp@10 {
> opp-hz = /bits/ 64 <10>;
> opp-microvolt = <97 975000 985000>;
> opp-microamp = <7>;
> clock-latency-ns = <30>;
> opp-suspend;
> };
> - opp01 {
> + opp@11 {
> opp-hz = /bits/ 64 <11>;
> opp-microvolt = <98 100 101>;
> opp-microamp = <8>;
> clock-latency-ns = <31>;
> };
> - opp02 {
> + opp@12 {
> opp-hz = /bits/ 64 <12>;
> opp-microvolt = <1025000>;
> opp-microamp = <9;
> @@ -338,20 +338,20 @@ DVFS state together.
> compatible = "operating-points-v2";
> opp-shared;
>
> - opp00 {
> + opp@10 {
> opp-hz = /bits/ 64 <10>;
> opp-microvolt = <97 975000 985000>;
> opp-microamp = <7>;
> clock-latency-ns = <30>;
> opp-suspend;
> };
> - opp01 {
> + opp@11 {
> opp-hz = /bits/ 64 <11>;
> opp-microvolt = <98 100 101>;
> opp-microamp = <8>;
> clock-latency-ns = <31>;
> };
> - opp02 {
> + opp@12 {
> opp-hz = /bits/ 64 <12>;
> opp-microvolt = <1025000>;
> opp-microamp = <9>;
> @@ -364,20 +364,20 @@ DVFS state together.
> compatible = "operating-points-v2";
> opp-shared;
>
> - opp10 {
> + opp@13 {
> opp-hz = /bits/ 64 <13>;
> opp-microvolt = <1045000 105 1055000>;
> opp-microamp = <95000>;
> clock-latency-ns = <40>;
> opp-suspend;
> };
> - opp11 {
> + opp@14 {
> opp-hz = /bits/ 64 <14>;
> opp-microvolt = <1075000>;
> opp-microamp = <10>;
> clock-latency-ns = <40>;
> };
> - opp12 {
> + opp@15 {
> opp-hz = /bits/ 64 <15>;
> opp-microvolt = <101 110 111>;
> opp-microamp = <95000>;
> @@ -404,7 +404,7 @@ Example 4: Handling multiple regulators
> compatible = "operating-points-v2";
>
[PATCH V2] powerpc/dts: Add DT alias for Freescale eSPI controller
From: Hou Zhiqiang
Add aliases for eSPI device node to assign the alias id to the
bus number of spi_master.
For the platforms used the device tree, the bus numbers are
dynamically assigned and are not predictable. However, sometimes
it must be figured out, e.g. using mtdparts in cmdline to specify
the layout of spi flash.
Signed-off-by: Hou Zhiqiang
---
V2:
- Generate the patch base on the latest source code.
arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi | 1 +
arch/powerpc/boot/dts/fsl/p1020si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p1021si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1021si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p1023si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p2041si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p3041si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p4080si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p5020si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/p5040si-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t102xsi-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/t1040si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t104xsi-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/t2081si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t208xsi-pre.dtsi| 1 +
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 2 +-
arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi| 1 +
31 files changed, 31 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
index 338af7e..7e164da 100644
--- a/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4420si-pre.dtsi
@@ -54,6 +54,7 @@
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
+ spi0 = &spi0;
};
diff --git a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
index 1948f73..b6e1724 100644
--- a/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4860si-pre.dtsi
@@ -54,6 +54,7 @@
dma0 = &dma0;
dma1 = &dma1;
sdhc = &sdhc;
+ spi0 = &spi0;
};
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 603910a..6fbd651 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -439,7 +439,7 @@
};
/include/ "qoriq-espi-0.dtsi"
- spi@11 {
+ spi0: spi@11 {
fsl,espi-num-chipselects = <4>;
};
diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
index c8b2daa..1c1c1fe 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
@@ -164,7 +164,7 @@
/include/ "pq3-duart-0.dtsi"
/include/ "pq3-espi-0.dtsi"
- spi@7000 {
+ spi0: spi@7000 {
fsl,espi-num-chipselects = <4>;
};
diff --git a/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
index 152906f..8a6b7e7 100644
--- a/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/mpc8536si-pre.dtsi
@@ -51,6 +51,7 @@
pci1 = &pci1;
pci2 = &pci2;
pci3 = &pci3;
+ spi0 = &spi0;
};
cpus {
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
index 642dc3a..2ee2c0f 100644
--- a/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1020si-post.dtsi
@@ -127,7 +127,7 @@
/include/ "pq3-duart-0.dtsi"
/include/ "pq3-espi-0.dtsi"
- spi@7000 {
+ spi0: spi@7000 {
fsl,espi-num-chipselects = <4>;
};
diff --git a/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
b/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
index fed9c4c..e40eef8 100644
--- a/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1020si-pre.dtsi
@@ -50,6 +50,7 @@
ethernet2 = &enet2;
pci0 = &pci0;
pci1 = &pci1;
+ spi0 = &spi0;
};
cpus {
diff --git a/arch/powerpc/boot/dts/fsl/p1021si-post.
Re: [PATCH V2 3/5] PM / OPP: Remove 'operating-points-names' binding
On Thu, Nov 05, 2015 at 07:11:54AM +0530, Viresh Kumar wrote:
> These aren't used until now by any DT files and wouldn't be used now as
> we have a better scheme in place now, i.e. opp-property-
> properties.
>
> Remove the (useless) binding without breaking ABI.
>
> Reviewed-by: Stephen Boyd
> Signed-off-by: Viresh Kumar
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 62
> +--
> 1 file changed, 2 insertions(+), 60 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt
> b/Documentation/devicetree/bindings/opp/opp.txt
> index 61c6f25cf8e2..30c4bb3718bc 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -45,21 +45,10 @@ Devices supporting OPPs must set their
> "operating-points-v2" property with
> phandle to a OPP table in their DT node. The OPP core will use this phandle
> to
> find the operating points for the device.
>
> -Devices may want to choose OPP tables at runtime and so can provide a list of
> -phandles here. But only *one* of them should be chosen at runtime. This must
> be
> -accompanied by a corresponding "operating-points-names" property, to uniquely
> -identify the OPP tables.
> -
> If required, this can be extended for SoC vendor specfic bindings. Such
> bindings
> should be documented as
> Documentation/devicetree/bindings/power/-opp.txt
> and should have a compatible description like:
> "operating-points-v2-".
>
> -Optional properties:
> -- operating-points-names: Names of OPP tables (required if multiple OPP
> - tables are present), to uniquely identify them. The same list must be
> present
> - for all the CPUs which are sharing clock/voltage rails and hence the OPP
> - tables.
> -
> * OPP Table Node
>
> This describes the OPPs belonging to a device. This node can have following
> @@ -454,54 +443,7 @@ Example 4: Handling multiple regulators
> };
> };
>
> -Example 5: Multiple OPP tables
> -
> -/ {
> - cpus {
> - cpu@0 {
> - compatible = "arm,cortex-a7";
> - ...
> -
> - cpu-supply = <&cpu_supply>
> - operating-points-v2 = <&cpu0_opp_table_slow>,
> <&cpu0_opp_table_fast>;
> - operating-points-names = "slow", "fast";
> - };
> - };
> -
> - cpu0_opp_table_slow: opp_table_slow {
> - compatible = "operating-points-v2";
> - status = "okay";
> - opp-shared;
> -
> - opp00 {
> - opp-hz = /bits/ 64 <6>;
> - ...
> - };
> -
> - opp01 {
> - opp-hz = /bits/ 64 <8>;
> - ...
> - };
> - };
> -
> - cpu0_opp_table_fast: opp_table_fast {
> - compatible = "operating-points-v2";
> - status = "okay";
> - opp-shared;
> -
> - opp10 {
> - opp-hz = /bits/ 64 <10>;
> - ...
> - };
> -
> - opp11 {
> - opp-hz = /bits/ 64 <11>;
> - ...
> - };
> - };
> -};
> -
> -Example 6: opp-supported-hw
> +Example 5: opp-supported-hw
> (example: three level hierarchy of versions: cuts, substrate and process)
>
> / {
> @@ -546,7 +488,7 @@ Example 6: opp-supported-hw
> };
> };
>
> -Example 7: opp-microvolt-, opp-microamp-, turbo-mode-,
> +Example 6: opp-microvolt-, opp-microamp-, turbo-mode-,
> opp-suspend-:
> (example: device with two possible microvolt ranges: slow and fast)
>
> --
> 2.6.2.198.g614a2ac
>
--
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/2] powerpc/fsl: Add PCI node in device tree of bsc9132qds
On Thu, 2015-11-05 at 10:52 +0800, Zhiqiang Hou wrote: > From: Harninder Rai > > Signed-off-by: Harninder Rai > Signed-off-by: Minghuan Lian > Reviewed-by: Zang Tiefei-R61911 > Reviewed-by: Kushwaha Prabhakar-B32579 > Reviewed-by: Fleming Andrew-AFLEMING > Tested-by: Fleming Andrew-AFLEMING > Signed-off-by: Hou Zhiqiang > --- > V3: > - Remove gerrit stuff. No, you didn't remove all of the Gerrit stuff. Get rid of all the Reviewed- by and Tested-by since they are not relevant to this context. Hitting "+1" in Gerrit to allow a patch to go into the SDK tree a few years ago is not the same as reviewing it for inclusion in mainline Linux today. -Scott -- 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 1/8] dt-bindings: add documentation of rk3036 clock controller
On 2015年11月05日 07:39, Heiko Stuebner wrote: Hi, Am Mittwoch, 4. November 2015, 20:18:16 schrieb Xing Zheng: Add the devicetree binding for the cru on the rk3036 which quite similar structured as previous clock controllers. Signed-off-by: Xing Zheng Reviewed-by: Heiko Stuebner --- your recipient-list is missing the clock maintainers+lists - sorry for not noticing this earlier. While the devicetree-maintainers may Review it, we expect the clock- maintainers to actually apply all 4 clock-related patches. Same comment is true for [PATCH v6 2/8] clk: rockchip: add dt-binding header for rk3036 Heiko Sorry, and I will loop them in the next versioin. Thanks. -- 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 2/3] arm64: dts: Add Hi6220 gpio configuration nodes
arm64: dts: Add Hi6220 gpio configuration nodes
Signed-off-by: Kaihua Zhong
Signed-off-by: Xinwei Kong
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 38 +
arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi | 195 +
3 files changed, 234 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index e36a539..f2b9c98 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -11,6 +11,7 @@
/memreserve/ 0x05e0 0x0010;
#include "hi6220.dtsi"
+#include "hikey-gpio.dtsi"
/ {
model = "HiKey Development Board";
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index 3f03380..c2b8925 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -167,5 +167,43 @@
clocks = <&ao_ctrl 36>, <&ao_ctrl 36>;
clock-names = "uartclk", "apb_pclk";
};
+ gpio0: gpio@f8011000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf8011000 0x0 0x1000>;
+ interrupts = <0 52 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
+
+ gpio1: gpio@f8012000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf8012000 0x0 0x1000>;
+ interrupts = <0 53 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
+
+ gpio2: gpio@f8013000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf8013000 0x0 0x1000>;
+ interrupts = <0 54 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
};
};
diff --git a/arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
b/arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
new file mode 100644
index 000..6eabf40
--- /dev/null
+++ b/arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi
@@ -0,0 +1,195 @@
+/*
+ * gpio dts file for Hisilicon HiKey development board
+ *
+ */
+/ {
+ gpio_rstout_n:gpio_rstout_n {
+ gpios;
+ };
+ gpio_pmu_peri_en:gpio_pmu_peri_en {
+ gpios;
+ };
+ gpio_sysclk0_en:gpio_sysclk0_en {
+ gpios;
+ };
+ gpio_jtag_tdo:gpio_jtag_tdo {
+ gpios;
+ };
+ /* LCB: PWR_HOLD_GPIO0_0 */
+ gpio_pwr_hold:gpio_pwr_hold {
+ gpios = <&gpio0 0 0>;
+ };
+ /* LCB: DSI_SEL_GPIO0_1 */
+ gpio_dsi_sel:gpio_dsi_sel {
+ gpios = <&gpio0 1 0>;
+ };
+ /* LCB: USB_HUB_RESET_N_GPIO0_2 */
+ gpio_usb_hub_reset_n:gpio_usb_hub_reset_n {
+ gpios = <&gpio0 2 0>;
+ };
+ /* LCB: USB_SEL_GPIO0_3 */
+ gpio_usb_sel:gpio_usb_sel {
+ gpios = <&gpio0 3 0>;
+ };
+ /* LCB: HDMI_PD_GPIO0_4 */
+ gpio_hdmi_pd:gpio_hdmi_pd {
+ gpios = <&gpio0 4 0>;
+ };
+ /* LCB: WL_REG_ON_GPIO0_5 */
+ gpio_wl_en:gpio_wl_en {
+ gpios = <&gpio0 5 0>;
+ };
+ /* LCB: PWRON_DET_GPIO0_6 */
+ gpio_pwron_det:gpio_pwron_det {
+ gpios = <&gpio0 6 0>;
+ };
+ /* LCB: 5V_HUB_EN_GPIO0_7 */
+ gpio_usb_dev_det:gpio_usb_dev_det {
+ gpios = <&gpio0 7 0>;
+ };
+ /* LCB: SD_DET_GPIO1_0 */
+ gpio_sd_det:gpio_sd_det {
+ gpios = <&gpio1 0 0>;
+ };
+ /* LCB: HDMI_INT_GPIO1_1 */
+ gpio_hdmi_int:gpio_hdmi_int {
+ gpios = <&gpio1 1 0>;
+ };
+ /* LCB: PMU_IRQ_N_GPIO1_2 */
+ gpio_pmu_irq_n:gpio_pmu_irq_n {
+ gpios = <&gpio1 2 0>;
+ };
+ /* LCB: WL_HOST_WAKE_GPIO1_3 */
+ gpio_wl_host_wake:gpio_wl_host_wake {
+ gpios = <&gpio1 3 0>;
+ };
+ gpio_nfc_int:gpi
[PATCH V2 3/3] arm64: dts: add Hi6220 pinctrl configuration nodes
arm64: dts: add Hi6220 pinctrl configuration nodes
Signed-off-by: Kaihua Zhong
Signed-off-by: Xinwei Kong
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
arch/arm64/boot/dts/hisilicon/hi6220.dtsi| 243
arch/arm64/boot/dts/hisilicon/hikey-gpio.dtsi| 416 ++
arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi | 684 +++
include/dt-bindings/pinctrl/hisi.h | 59 ++
5 files changed, 1403 insertions(+)
create mode 100644 arch/arm64/boot/dts/hisilicon/hikey-pinctrl.dtsi
create mode 100644 include/dt-bindings/pinctrl/hisi.h
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index f2b9c98..71a72d7 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -12,6 +12,7 @@
#include "hi6220.dtsi"
#include "hikey-gpio.dtsi"
+#include "hikey-pinctrl.dtsi"
/ {
model = "HiKey Development Board";
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
index c2b8925..8e209c2 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
@@ -5,6 +5,7 @@
*/
#include
+#include
/ {
compatible = "hisilicon,hi6220";
@@ -205,5 +206,247 @@
clock-names = "apb_pclk";
status = "ok";
};
+
+ gpio3: gpio@f8014000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf8014000 0x0 0x1000>;
+ interrupts = <0 55 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pmx0 0 80 8>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
+
+ gpio4: gpio@f702 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf702 0x0 0x1000>;
+ interrupts = <0 56 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pmx0 0 88 8>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
+
+ gpio5: gpio@f7021000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf7021000 0x0 0x1000>;
+ interrupts = <0 57 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pmx0 0 96 8>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
+
+ gpio6: gpio@f7022000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf7022000 0x0 0x1000>;
+ interrupts = <0 58 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pmx0 0 104 8>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
+
+ gpio7: gpio@f7023000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf7023000 0x0 0x1000>;
+ interrupts = <0 59 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pmx0 0 112 8>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
+
+ gpio8: gpio@f7024000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf7024000 0x0 0x1000>;
+ interrupts = <0 60 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&pmx0 0 120 2 &pmx0 2 2 6>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+
[PATCH V2 1/3] dt-bindings: gpio: Documentation for Hi6220 gpio driver
dt-bindings: gpio: Documentation for Hi6220 gpio driver
Signed-off-by: Kaihua Zhong
Signed-off-by: Xinwei Kong
Acked-by: Rob Herring
---
.../devicetree/bindings/gpio/gpio-hi6220.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
b/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
new file mode 100644
index 000..a9cbf21
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
@@ -0,0 +1,23 @@
+Hisilicon Hi6220 GPIO controller bindings
+
+Required properties:
+ - compatible: "arm,pl061","arm,primecell"
+ - gpio-controller: Marks the device node as a GPIO controller.
+ - #gpio-cells: Should be 2. See gpio.txt in this directory for a
+description of the cells format.
+ - interrupt-controller: Mark the device node as an interrupt controller
+
+Example:
+
+ gpio0: gpio@f8011000 {
+ compatible = "arm,pl061", "arm,primecell";
+ reg = <0x0 0xf8011000 0x0 0x1000>;
+ interrupts = <0 52 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ clocks = <&ao_ctrl 2>;
+ clock-names = "apb_pclk";
+ status = "ok";
+ };
--
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 V2 2/5] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
On Thu, Nov 05, 2015 at 07:11:53AM +0530, Viresh Kumar wrote: > Depending on the version of hardware or its properties, which are only > known at runtime, various properties of the OPP can change. For example, > an OPP with frequency 1.2 GHz, may have different voltage/current > requirements based on the version of the hardware it is running on. > Similarly, it may or may not be a turbo or suspend OPP on those > circumstances. > > In order to not replicate the same OPP tables for varying values of all > such fields, this commit introduces the concept of opp-property-. > The can be chosen by the platform at runtime, and OPPs will be > initialized depending on that name string. Currently support is extended > for the following properties: > - opp-microvolt- > - opp-microamp- > - turbo-mode- > - opp-suspend- > > If the name string isn't provided by the platform, or if it is provided > but doesn't match the properties present in the OPP node, we will fall > back to the original properties without the - string, if they are > available. > > Reviewed-by: Stephen Boyd > Signed-off-by: Viresh Kumar > --- > Documentation/devicetree/bindings/opp/opp.txt | 58 > +++ > 1 file changed, 58 insertions(+) > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > b/Documentation/devicetree/bindings/opp/opp.txt > index d072fa0ffbd4..61c6f25cf8e2 100644 > --- a/Documentation/devicetree/bindings/opp/opp.txt > +++ b/Documentation/devicetree/bindings/opp/opp.txt > @@ -100,6 +100,14 @@ properties. >Entries for multiple regulators must be present in the same order as >regulators are specified in device's DT node. > > +- opp-microvolt-: Named opp-microvolt property. This is exactly > similar to > + the above opp-microvolt property, but allows multiple voltage ranges to be > + provided for the same OPP. At runtime, the platform can pick a and > + matching opp-microvolt- property will be enabled for all OPPs. If the > + platform doesn't pick a specific or the doesn't match with > any > + opp-microvolt- properties, then opp-microvolt property shall be > used, if > + present. > + > - opp-microamp: The maximum current drawn by the device in microamperes >considering system specific parameters (such as transients, process, aging, >maximum operating temperature range etc.) as necessary. This may be used to > @@ -112,6 +120,9 @@ properties. >for few regulators, then this should be marked as zero for them. If it > isn't >required for any regulator, then this property need not be present. > > +- opp-microamp-: Named opp-microamp property. Similar to > + opp-microvolt- property, but for microamp instead. > + > - clock-latency-ns: Specifies the maximum possible transition latency (in >nanoseconds) for switching to this OPP from any other OPP. > > @@ -120,9 +131,15 @@ properties. >frequency for a short duration of time limited by the device's power, > current >and thermal limits. > > +- turbo-mode-: Named turbo-mode property. Similar to > opp-microvolt- > + property, but for turbo mode instead. > + > - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP > in >the table should have this. > > +- opp-suspend-: Named opp-suspend property. Similar to > + opp-microvolt- property, but for suspend opp instead. > + I don't think these last 2 make sense. turbo-mode is a flag that the mode has restrictions such as other cores have to be idle or something. Similarly, opp-suspend should not vary by . 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 2/3] dt-bindings: gpio: Documentation for Hi6220 gpio driver
On 2015/11/2 23:09, Rob Herring wrote:
> On Fri, Oct 30, 2015 at 9:24 PM, Zhong Kaihua wrote:
>> dt-bindings: gpio: Documentation for Hi6220 gpio driver
>>
>> Signed-off-by: Zhong Kaihua
>> ---
>> .../devicetree/bindings/gpio/gpio-hi6220.txt | 23
>> ++
>> 1 file changed, 23 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
>> b/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
>> new file mode 100644
>> index 000..76a8932
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-hi6220.txt
>> @@ -0,0 +1,23 @@
>> +Hisilicon Hi6220 GPIO controller bindings
>> +
>> +Required properties:
>> + - compatible:"arm,pl061", "arm,primecell"
>> + - gpio-controller: Marks the device node as aGPIO controller.
>> + - #gpio-cells: Shouldbe 2. See gpio.txt in this directory for a
>
> Some strange spacing in here. Otherwise,
>
> Acked-by: Rob Herring
Style problems have been fixed in V2 patch.
Rearrange the document patch to the first of patch set.
>
>> +description of the cells format.
>> + - interrupt-controller: Mark the device node as an interrupt controller
>> +
>> +Example:
>> +
>> + gpio0: gpio@f8011000 {
>> + compatible = "arm,pl061", "arm,primecell";
>> + reg = <0x0 0xf8011000 0x0 0x1000>;
>> + interrupts = <0 52 0x4>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + clocks = <&ao_ctrl 2>;
>> + clock-names = "apb_pclk";
>> + status = "ok";
>> + };
>> --
>> 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
>
> .
>
--
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 6/8] ARM: rockchip: add support smp for rk3036
On 2015年11月05日 07:33, Heiko Stuebner wrote: Am Mittwoch, 4. November 2015, 20:25:16 schrieb Xing Zheng: From: Heiko Stuebner The dual-core Cortex A7 rk3036 is a bit special in that it does not allow to control the actual powerdomain of the cpu cores, while the rest of the smp-bringup like reset control and entry address handling stays the same. Its bigger sibling, the quad-core rk3128 again allows powerdomain control. So allow that case by introducing a separate smp-enable-method, that simply disables powerdomain handling in the common code. Signed-off-by: Heiko Stuebner Tested-by: Xing Zheng Signed-off-by: Xing Zheng This patch can work standalone, so I took the liberty of applying it to my soc branch for 4.5 already, so you don't need to resend it in future versions. OK， thanks Heiko. :) -- 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/2] powerpc/85xx: Add PCIe controller support for bsc9132qds
From: Harninder Rai
1. Use machine_arch_initcall to hook mpc85xx_common_publish_devices
This can ensure before pcibios_init() is called, pci controllers have
been probed and added to the hose_list.
2. Add a workaround for errata A-005434
For the BSC9132, PEX_PEXIWARn[TRGT] for all windows defaults to 0xF,
which is mapped to CCSRBAR. However, for other products, 0xF is
mapped to the local memory. Therefore, for the BSC9132, any default
PCI Express access to the local memory (DDR) will now access the
CCSRBAR. This patch changes the mapping of targets of inbound windows
PEX_PEXIWARn[TRGT] to the Local address space – 0x0 (from 0xF).
Signed-off-by: Harninder Rai
Signed-off-by: Minghuan Lian
Reviewed-by: Zang Tiefei-R61911
Reviewed-by: Kushwaha Prabhakar-B32579
Reviewed-by: Fleming Andrew-AFLEMING
Tested-by: Fleming Andrew-AFLEMING
Signed-off-by: Hou Zhiqiang
---
V3:
- Remove gerrit stuff.
arch/powerpc/platforms/85xx/bsc913x_qds.c | 8 +++-
arch/powerpc/sysdev/fsl_pci.c | 13 +
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/85xx/bsc913x_qds.c
b/arch/powerpc/platforms/85xx/bsc913x_qds.c
index f0927e5..dcfafd6 100644
--- a/arch/powerpc/platforms/85xx/bsc913x_qds.c
+++ b/arch/powerpc/platforms/85xx/bsc913x_qds.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "mpc85xx.h"
@@ -46,10 +47,12 @@ static void __init bsc913x_qds_setup_arch(void)
mpc85xx_smp_init();
#endif
+ fsl_pci_assign_primary();
+
pr_info("bsc913x board from Freescale Semiconductor\n");
}
-machine_device_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
+machine_arch_initcall(bsc9132_qds, mpc85xx_common_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -67,6 +70,9 @@ define_machine(bsc9132_qds) {
.probe = bsc9132_qds_probe,
.setup_arch = bsc913x_qds_setup_arch,
.init_IRQ = bsc913x_qds_pic_init,
+#ifdef CONFIG_PCI
+ .pcibios_fixup_bus = fsl_pcibios_fixup_bus,
+#endif
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index ebc1f412..b8607f6 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -193,6 +193,19 @@ static void setup_pci_atmu(struct pci_controller *hose)
const u64 *reg;
int len;
+ if (of_device_is_compatible(hose->dn, "fsl,bsc9132-pcie")) {
+ /*
+* BSC9132 Rev1.0 has an issue where all the PEX inbound
+* windows have implemented the default target value as 0xf
+* for CCSR space.In all Freescale legacy devices the target
+* of 0xf is reserved for local memory space. 9132 Rev1.0
+* now has local mempry space mapped to target 0x0 instead of
+* 0xf. Hence adding a workaround to remove the target 0xf
+* defined for memory space from Inbound window attributes.
+*/
+ piwar &= ~PIWAR_TGI_LOCAL;
+ }
+
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
if (in_be32(&pci->block_rev1) >= PCIE_IP_REV_2_2) {
win_idx = 2;
--
2.1.0.27.g96db324
--
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 1/5] PM / OPP: Add "opp-supported-hw" binding
On Thu, Nov 05, 2015 at 07:11:52AM +0530, Viresh Kumar wrote:
> We may want to enable only a subset of OPPs, from the bigger list of
> OPPs, based on what version of the hardware we are running on. This
> would enable us to not duplicate OPP tables for every version of the
> hardware we support.
>
> To enable that, this patch defines a new property 'opp-supported-hw'. It
> can support any number of hierarchy levels of the versions the hardware
> follows. And based on the selected hardware versions, we can pick only
> the relevant OPPs at runtime.
>
> Reviewed-by: Stephen Boyd
> Signed-off-by: Viresh Kumar
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 65
> +++
> 1 file changed, 65 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt
> b/Documentation/devicetree/bindings/opp/opp.txt
> index 0cb44dc21f97..d072fa0ffbd4 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -123,6 +123,26 @@ properties.
> - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP
> in
>the table should have this.
>
> +- opp-supported-hw: This enables us to select only a subset of OPPs from the
> + larger OPP table, based on what version of the hardware we are running on.
> We
> + still can't have multiple nodes with the same opp-hz value in OPP table.
> +
> + It's an user defined array containing a hierarchy of hardware version
> numbers,
> + supported by the OPP. For example: a platform with hierarchy of three
> levels
> + of versions (A, B and C), this field should be like , where X
> + corresponds to Version hierarchy A, Y corresponds to version hierarchy B
> and Z
> + corresponds to version hierarchy C.
> +
> + Each level of hierarchy is represented by a 32 bit value, and so there can
> be
> + only 32 different supported version per hierarchy. i.e. 1 bit per version.
> A
> + value of 0x will enable the OPP for all versions for that hierarchy
> + level. And a value of 0x will disable the OPP completely, and so we
> + never want that to happen.
> +
> + If 32 values aren't sufficient for a version hierarchy, than that version
> + hierarchy can be contained in multiple 32 bit values. i.e. in
> the
> + above example, Z1 & Z2 refer to the version hierarchy Z.
> +
> - status: Marks the node enabled/disabled.
>
> Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states
> together.
> @@ -463,3 +483,48 @@ Example 5: Multiple OPP tables
> };
> };
> };
> +
> +Example 6: opp-supported-hw
> +(example: three level hierarchy of versions: cuts, substrate and process)
> +
> +/ {
> + cpus {
> + cpu@0 {
> + compatible = "arm,cortex-a7";
> + ...
> +
> + cpu-supply = <&cpu_supply>
> + operating-points-v2 = <&cpu0_opp_table_slow>;
> + };
> + };
> +
> + opp_table {
> + compatible = "operating-points-v2";
> + status = "okay";
> + opp-shared;
> +
> + opp00 {
> + /*
> + * Supports all substrate and process versions for 0xF
> + * cuts, i.e. only first four cuts.
> + */
> + opp-supported-hw = <0xF 0x 0x>
> + opp-hz = /bits/ 64 <6>;
> + opp-microvolt = <90 915000 925000>;
> + ...
> + };
> +
> + opp01 {
> + /*
> + * Supports:
> + * - cuts: only one, 6th cut (represented by 6th bit).
> + * - substrate: supports 16 different substrate versions
> + * - process: supports 9 different process versions
> + */
> + opp-supported-hw = <0x20 0xffff 0xf4f0>
> + opp-hz = /bits/ 64 <8>;
> + opp-microvolt = <90 915000 925000>;
> + ...
> + };
> + };
> +};
> --
> 2.6.2.198.g614a2ac
>
--
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 2/2 V2] drivers/gpio: Port gpio driver to layerscape platform
Layerscape has the same ip block/controller as
GPIO on powerpc platform(MPC8XXX).
So use portable i/o accessors, as in_be32/out_be32
accessors are Power architecture specific whereas
ioread32/iowrite32 and ioread32be/iowrite32be are
available in other architectures.
Layerscape GPIO controller's registers may be big
or little endian, so the code needs to get the
endian property from DTB, then make additional
functions to fit right register read/write
operations.
Currently the code can support ls2080a GPIO with
little endian registers. And it can also work well
on other layerscape platform with big endian GPIO
registers.
Signed-off-by: Liu Gang
Signed-off-by: Shaveta Leekha
---
V2 changes: Add '|| COMPILE_TEST' based on Arnd's comments.
drivers/gpio/Kconfig| 6 ++--
drivers/gpio/gpio-mpc8xxx.c | 87 +
2 files changed, 67 insertions(+), 26 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 8949b3f..8d4f159 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -290,12 +290,12 @@ config GPIO_MPC5200
depends on PPC_MPC52xx
config GPIO_MPC8XXX
- bool "MPC512x/MPC8xxx GPIO support"
+ bool "MPC512x/MPC8xxx/QorIQ GPIO support"
depends on PPC_MPC512x || PPC_MPC831x || PPC_MPC834x || PPC_MPC837x || \
- FSL_SOC_BOOKE || PPC_86xx
+ FSL_SOC_BOOKE || PPC_86xx || ARCH_LAYERSCAPE || COMPILE_TEST
help
Say Y here if you're going to use hardware that connects to the
- MPC512x/831x/834x/837x/8572/8610 GPIOs.
+ MPC512x/831x/834x/837x/8572/8610/QorIQ GPIOs.
config GPIO_MSM_V2
tristate "Qualcomm MSM GPIO v2"
diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
index 48ef368..eb7a1ca 100644
--- a/drivers/gpio/gpio-mpc8xxx.c
+++ b/drivers/gpio/gpio-mpc8xxx.c
@@ -1,5 +1,5 @@
/*
- * GPIOs on MPC512x/8349/8572/8610 and compatible
+ * GPIOs on MPC512x/8349/8572/8610/QorIQ and compatible
*
* Copyright (C) 2008 Peter Korsgaard
*
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define MPC8XXX_GPIO_PINS 32
@@ -44,6 +45,27 @@ struct mpc8xxx_gpio_chip {
const void *of_dev_id_data;
};
+static bool gpio_little_endian;
+static inline u32 gpio_in32(void __iomem *addr)
+{
+ u32 val;
+
+ if (gpio_little_endian)
+ val = ioread32(addr);
+ else
+ val = ioread32be(addr);
+
+ return val;
+}
+
+static inline void gpio_out32(u32 val, void __iomem *addr)
+{
+ if (gpio_little_endian)
+ iowrite32(val, addr);
+ else
+ iowrite32be(val, addr);
+}
+
static inline u32 mpc8xxx_gpio2mask(unsigned int gpio)
{
return 1u << (MPC8XXX_GPIO_PINS - 1 - gpio);
@@ -59,9 +81,17 @@ static void mpc8xxx_gpio_save_regs(struct of_mm_gpio_chip
*mm)
{
struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
- mpc8xxx_gc->data = in_be32(mm->regs + GPIO_DAT);
+ mpc8xxx_gc->data = gpio_in32(mm->regs + GPIO_DAT);
}
+/* Generic set and clear bits accessor ports */
+#define bgpio_setbits32(_addr, _v) \
+ gpio_out32(gpio_in32(_addr) | (_v), (_addr))
+#define bgpio_clrbits32(_addr, _v) \
+ gpio_out32(gpio_in32(_addr) & ~(_v), (_addr))
+#define bgpio_clrsetbits32(addr, clear, set) \
+ gpio_out32((gpio_in32(addr) & ~(clear)) | (set), (addr))
+
/* Workaround GPIO 1 errata on MPC8572/MPC8536. The status of GPIOs
* defined as output cannot be determined by reading GPDAT register,
* so we use shadow data register instead. The status of input pins
@@ -74,9 +104,9 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned
int gpio)
struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
u32 out_mask, out_shadow;
- out_mask = in_be32(mm->regs + GPIO_DIR);
+ out_mask = gpio_in32(mm->regs + GPIO_DIR);
- val = in_be32(mm->regs + GPIO_DAT) & ~out_mask;
+ val = gpio_in32(mm->regs + GPIO_DAT) & ~out_mask;
out_shadow = mpc8xxx_gc->data & out_mask;
return (val | out_shadow) & mpc8xxx_gpio2mask(gpio);
@@ -86,7 +116,7 @@ static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned
int gpio)
{
struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
- return in_be32(mm->regs + GPIO_DAT) & mpc8xxx_gpio2mask(gpio);
+ return gpio_in32(mm->regs + GPIO_DAT) & mpc8xxx_gpio2mask(gpio);
}
static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
@@ -102,7 +132,7 @@ static void mpc8xxx_gpio_set(struct gpio_chip *gc, unsigned
int gpio, int val)
else
mpc8xxx_gc->data &= ~mpc8xxx_gpio2mask(gpio);
- out_be32(mm->regs + GPIO_DAT, mpc8xxx_gc->data);
+ gpio_out32(mpc8xxx_gc->data, mm->regs + GPIO_DAT);
raw_spin_unlock_irqrestore(&mpc8xxx_gc->lock, flags);
}
@@ -128,7 +158,7 @@ static void mpc8xxx_gpio_set_multiple(s
Re: [PATCH V2 3/3] dma: add Qualcomm Technologies HIDMA channel driver
/*
* We are posting descriptors to the hardware as soon as
* they are ready, so this function does nothing.
*/
So, the Freescale driver was written before change went effective. I
guess in 2011 DMA Engine drivers should use issue pending.
Please, refactor since this behaviour is expected.
done
+/*
+ * Submit descriptor to hardware.
+ * Lock the PM for each descriptor we are sending.
+ */
+static dma_cookie_t hidma_tx_submit(struct dma_async_tx_descriptor *txd)
+{
+ struct hidma_chan *mchan = to_hidma_chan(txd->chan);
+ struct hidma_dev *dmadev = mchan->dmadev;
+ struct hidma_desc *mdesc;
+ unsigned long irqflags;
+ dma_cookie_t cookie;
+
+ if (!hidma_ll_isenabled(dmadev->lldev))
+ return -ENODEV;
+
+ pm_runtime_get_sync(dmadev->ddev.dev);
No point to do it here. It should be done on the function that
actually starts the transfer (see issue pending).
comment above
See above as well.
done
+static int hidma_probe(struct platform_device *pdev)
+{
+ struct hidma_dev *dmadev;
+ int rc = 0;
+ struct resource *trca_resource;
+ struct resource *evca_resource;
+ int chirq;
+ int current_channel_index = atomic_read(&channel_ref_count);
+
+ /* Set DMA mask to 64 bits. */
+ rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
+ if (rc) {
+ dev_warn(&pdev->dev, "unable to set coherent mask to
64");
+ rc = dma_set_mask_and_coherent(&pdev->dev,
DMA_BIT_MASK(32));
+ }
+ if (rc)
+ goto dmafree;
Maybe move these two lines inside previous condition?
ok
+
+ dmadev->lldev = hidma_ll_init(dmadev->ddev.dev,
+ dmadev->nr_descriptors, dmadev->dev_trca,
+ dmadev->dev_evca, dmadev->evridx);
+ if (!dmadev->lldev) {
+ rc = -EPROBE_DEFER;
+ goto dmafree;
+ }
+
+ rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler, 0,
+ "qcom-hidma", &dmadev->lldev);
Better to use request_irq().
why? I thought we favored managed functions over standalone functions in
simplify the exit path.
IRQ is slightly different in workflow. In most cases, unfortunately,
there is no achievement by devm_ variant.
At least I know two for now. One of them is DMA Engine slave drivers,
though I didn't notice if you are using tasklet's here.
Otherwise it's okay.
I'm keeping it as it is for maintenance reasons.
--
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project
--
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: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
On Tue, Oct 27, 2015 at 11:06 AM, wrote:
> +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id)
> +{
> + struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id;
> + struct watchdog_device *wdd = &gwdt->wdd;
> +
> + /* We don't use pretimeout, trigger WS1 now */
> + if (!wdd->pretimeout)
> + sbsa_gwdt_set_wcv(wdd, 0);
So I'm still concerned about the fact this driver depends on an
interrupt handler in order to properly program the hardware. Unlike
some other devices, the SBSA watchdog does not need assistance to
reset on a timeout -- it is a "fire and forget" device. What happens
if there is a hard lockup, and interrupts no longer work?
Keep in mind that 99% of watchdog daemons will not enable the
pre-timeout feature because it's new.
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
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 5/5] ARM: dts: exynos4412: Rename OPP nodes as opp@
On 05-11-15, 10:51, Krzysztof Kozlowski wrote: > I see this patch does not depend on the rest of patchset so I presume > this can co through samsung-soc? Yeah, I wouldn't mind that. But I would wait for a confirmation from Rafael for the bindings first, for an unlikely case where he doesn't like the fourth patch ;) -- 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 V2 5/5] ARM: dts: exynos4412: Rename OPP nodes as opp@
On 05.11.2015 10:41, Viresh Kumar wrote: > OPP bindings got updated to name OPP nodes this way, make changes > according to that. > > Signed-off-by: Viresh Kumar > --- > arch/arm/boot/dts/exynos4412.dtsi | 28 ++-- > 1 file changed, 14 insertions(+), 14 deletions(-) I see this patch does not depend on the rest of patchset so I presume this can co through samsung-soc? 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
[PATCH V2 3/5] PM / OPP: Remove 'operating-points-names' binding
These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-
properties.
Remove the (useless) binding without breaking ABI.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 62 +--
1 file changed, 2 insertions(+), 60 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 61c6f25cf8e2..30c4bb3718bc 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -45,21 +45,10 @@ Devices supporting OPPs must set their
"operating-points-v2" property with
phandle to a OPP table in their DT node. The OPP core will use this phandle to
find the operating points for the device.
-Devices may want to choose OPP tables at runtime and so can provide a list of
-phandles here. But only *one* of them should be chosen at runtime. This must be
-accompanied by a corresponding "operating-points-names" property, to uniquely
-identify the OPP tables.
-
If required, this can be extended for SoC vendor specfic bindings. Such
bindings
should be documented as
Documentation/devicetree/bindings/power/-opp.txt
and should have a compatible description like: "operating-points-v2-".
-Optional properties:
-- operating-points-names: Names of OPP tables (required if multiple OPP
- tables are present), to uniquely identify them. The same list must be present
- for all the CPUs which are sharing clock/voltage rails and hence the OPP
- tables.
-
* OPP Table Node
This describes the OPPs belonging to a device. This node can have following
@@ -454,54 +443,7 @@ Example 4: Handling multiple regulators
};
};
-Example 5: Multiple OPP tables
-
-/ {
- cpus {
- cpu@0 {
- compatible = "arm,cortex-a7";
- ...
-
- cpu-supply = <&cpu_supply>
- operating-points-v2 = <&cpu0_opp_table_slow>,
<&cpu0_opp_table_fast>;
- operating-points-names = "slow", "fast";
- };
- };
-
- cpu0_opp_table_slow: opp_table_slow {
- compatible = "operating-points-v2";
- status = "okay";
- opp-shared;
-
- opp00 {
- opp-hz = /bits/ 64 <6>;
- ...
- };
-
- opp01 {
- opp-hz = /bits/ 64 <8>;
- ...
- };
- };
-
- cpu0_opp_table_fast: opp_table_fast {
- compatible = "operating-points-v2";
- status = "okay";
- opp-shared;
-
- opp10 {
- opp-hz = /bits/ 64 <10>;
- ...
- };
-
- opp11 {
- opp-hz = /bits/ 64 <11>;
- ...
- };
- };
-};
-
-Example 6: opp-supported-hw
+Example 5: opp-supported-hw
(example: three level hierarchy of versions: cuts, substrate and process)
/ {
@@ -546,7 +488,7 @@ Example 6: opp-supported-hw
};
};
-Example 7: opp-microvolt-, opp-microamp-, turbo-mode-,
+Example 6: opp-microvolt-, opp-microamp-, turbo-mode-,
opp-suspend-:
(example: device with two possible microvolt ranges: slow and fast)
--
2.6.2.198.g614a2ac
--
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/5] PM / OPP: Rename OPP nodes as opp@
It would be better to name OPP nodes as opp@ as that will ensure
that multiple DT nodes don't contain the same frequency. Of course we
expect the writer to name the node with its opp-hz frequency and not any
other frequency.
And that will let the compile error out if multiple nodes are using the
same opp-hz frequency.
Suggested-by: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 38 +--
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 30c4bb3718bc..10ef08dc1b4c 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -183,20 +183,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch
DVFS states together.
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <97 975000 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
- opp01 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <98 100 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
- opp02 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
clock-latency-ns = <29>;
@@ -262,20 +262,20 @@ independently.
* independently.
*/
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <97 975000 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
- opp01 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <98 100 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
- opp02 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9;
@@ -338,20 +338,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <97 975000 985000>;
opp-microamp = <7>;
clock-latency-ns = <30>;
opp-suspend;
};
- opp01 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <98 100 101>;
opp-microamp = <8>;
clock-latency-ns = <31>;
};
- opp02 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1025000>;
opp-microamp = <9>;
@@ -364,20 +364,20 @@ DVFS state together.
compatible = "operating-points-v2";
opp-shared;
- opp10 {
+ opp@13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <1045000 105 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <40>;
opp-suspend;
};
- opp11 {
+ opp@14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1075000>;
opp-microamp = <10>;
clock-latency-ns = <40>;
};
- opp12 {
+ opp@15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <101 110 111>;
opp-microamp = <95000>;
@@ -404,7 +404,7 @@ Example 4: Handling multiple regulators
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
[PATCH V2 2/5] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
Depending on the version of hardware or its properties, which are only
known at runtime, various properties of the OPP can change. For example,
an OPP with frequency 1.2 GHz, may have different voltage/current
requirements based on the version of the hardware it is running on.
Similarly, it may or may not be a turbo or suspend OPP on those
circumstances.
In order to not replicate the same OPP tables for varying values of all
such fields, this commit introduces the concept of opp-property-.
The can be chosen by the platform at runtime, and OPPs will be
initialized depending on that name string. Currently support is extended
for the following properties:
- opp-microvolt-
- opp-microamp-
- turbo-mode-
- opp-suspend-
If the name string isn't provided by the platform, or if it is provided
but doesn't match the properties present in the OPP node, we will fall
back to the original properties without the - string, if they are
available.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 58 +++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index d072fa0ffbd4..61c6f25cf8e2 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -100,6 +100,14 @@ properties.
Entries for multiple regulators must be present in the same order as
regulators are specified in device's DT node.
+- opp-microvolt-: Named opp-microvolt property. This is exactly similar
to
+ the above opp-microvolt property, but allows multiple voltage ranges to be
+ provided for the same OPP. At runtime, the platform can pick a and
+ matching opp-microvolt- property will be enabled for all OPPs. If the
+ platform doesn't pick a specific or the doesn't match with any
+ opp-microvolt- properties, then opp-microvolt property shall be used,
if
+ present.
+
- opp-microamp: The maximum current drawn by the device in microamperes
considering system specific parameters (such as transients, process, aging,
maximum operating temperature range etc.) as necessary. This may be used to
@@ -112,6 +120,9 @@ properties.
for few regulators, then this should be marked as zero for them. If it isn't
required for any regulator, then this property need not be present.
+- opp-microamp-: Named opp-microamp property. Similar to
+ opp-microvolt- property, but for microamp instead.
+
- clock-latency-ns: Specifies the maximum possible transition latency (in
nanoseconds) for switching to this OPP from any other OPP.
@@ -120,9 +131,15 @@ properties.
frequency for a short duration of time limited by the device's power, current
and thermal limits.
+- turbo-mode-: Named turbo-mode property. Similar to opp-microvolt-
+ property, but for turbo mode instead.
+
- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
the table should have this.
+- opp-suspend-: Named opp-suspend property. Similar to
+ opp-microvolt- property, but for suspend opp instead.
+
- opp-supported-hw: This enables us to select only a subset of OPPs from the
larger OPP table, based on what version of the hardware we are running on. We
still can't have multiple nodes with the same opp-hz value in OPP table.
@@ -528,3 +545,44 @@ Example 6: opp-supported-hw
};
};
};
+
+Example 7: opp-microvolt-, opp-microamp-, turbo-mode-,
+opp-suspend-:
+(example: device with two possible microvolt ranges: slow and fast)
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ ...
+
+ operating-points-v2 = <&cpu0_opp_table>;
+ };
+ };
+
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp00 {
+ opp-hz = /bits/ 64 <10>;
+ opp-microvolt-slow = <90 915000 925000>;
+ opp-microvolt-fast = <97 975000 985000>;
+ opp-microamp-slow = <7>;
+ opp-microamp-fast = <71000>;
+ turbo-mode-slow; /* Will be used as turbo only if
'slow' is chosen */
+ opp-suspend-slow; /* Will be used as suspend-opp only
if 'slow' is chosen */
+ };
+
+ opp01 {
+ opp-hz = /bits/ 64 <12>;
+ opp-microvolt-slow = <90 915000 925000>, /* Supply
vcc0 */
+ <91 925000 935000>; /* Supply
vcc1 */
+ opp-microvolt-fast = <97 975000 985000>, /* Supply
vcc0 */
+<96 965000 975000>; /* Supply
vcc1 */
+ opp-microamp = <7>; /* Will be used for both
slo
[PATCH V2 1/5] PM / OPP: Add "opp-supported-hw" binding
We may want to enable only a subset of OPPs, from the bigger list of
OPPs, based on what version of the hardware we are running on. This
would enable us to not duplicate OPP tables for every version of the
hardware we support.
To enable that, this patch defines a new property 'opp-supported-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.
Reviewed-by: Stephen Boyd
Signed-off-by: Viresh Kumar
---
Documentation/devicetree/bindings/opp/opp.txt | 65 +++
1 file changed, 65 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree/bindings/opp/opp.txt
index 0cb44dc21f97..d072fa0ffbd4 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -123,6 +123,26 @@ properties.
- opp-suspend: Marks the OPP to be used during device suspend. Only one OPP in
the table should have this.
+- opp-supported-hw: This enables us to select only a subset of OPPs from the
+ larger OPP table, based on what version of the hardware we are running on. We
+ still can't have multiple nodes with the same opp-hz value in OPP table.
+
+ It's an user defined array containing a hierarchy of hardware version
numbers,
+ supported by the OPP. For example: a platform with hierarchy of three levels
+ of versions (A, B and C), this field should be like , where X
+ corresponds to Version hierarchy A, Y corresponds to version hierarchy B and
Z
+ corresponds to version hierarchy C.
+
+ Each level of hierarchy is represented by a 32 bit value, and so there can be
+ only 32 different supported version per hierarchy. i.e. 1 bit per version. A
+ value of 0x will enable the OPP for all versions for that hierarchy
+ level. And a value of 0x will disable the OPP completely, and so we
+ never want that to happen.
+
+ If 32 values aren't sufficient for a version hierarchy, than that version
+ hierarchy can be contained in multiple 32 bit values. i.e. in the
+ above example, Z1 & Z2 refer to the version hierarchy Z.
+
- status: Marks the node enabled/disabled.
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
@@ -463,3 +483,48 @@ Example 5: Multiple OPP tables
};
};
};
+
+Example 6: opp-supported-hw
+(example: three level hierarchy of versions: cuts, substrate and process)
+
+/ {
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ ...
+
+ cpu-supply = <&cpu_supply>
+ operating-points-v2 = <&cpu0_opp_table_slow>;
+ };
+ };
+
+ opp_table {
+ compatible = "operating-points-v2";
+ status = "okay";
+ opp-shared;
+
+ opp00 {
+ /*
+* Supports all substrate and process versions for 0xF
+* cuts, i.e. only first four cuts.
+*/
+ opp-supported-hw = <0xF 0x 0x>
+ opp-hz = /bits/ 64 <6>;
+ opp-microvolt = <90 915000 925000>;
+ ...
+ };
+
+ opp01 {
+ /*
+* Supports:
+* - cuts: only one, 6th cut (represented by 6th bit).
+* - substrate: supports 16 different substrate versions
+* - process: supports 9 different process versions
+*/
+ opp-supported-hw = <0x20 0xffff 0xf4f0>
+ opp-hz = /bits/ 64 <8>;
+ opp-microvolt = <90 915000 925000>;
+ ...
+ };
+ };
+};
--
2.6.2.198.g614a2ac
--
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/5] PM / OPP: opp-supported-hw and -name bindings
Hi Rafael,
All the bindings are Reviewed by Stephen now and Rob didn't had a
problem with them (though he didn't Ack them separately yet) :)
The first patch enables us to select only a subset of OPPs from the
bigger table, based on what version of the hardware we are running on.
The second one enables us to select slightly different values for
multiple properties, based on what kind of hardware they are running on.
The third one removes an (unused) binding, which is replaced by the
second patch with a better solution.
The fourth patch is based on what Stephen suggested (and then reviewed)
in the earlier series, and the 5th one updates the existing users of
these bindings for it.
Viresh Kumar (5):
PM / OPP: Add "opp-supported-hw" binding
PM / OPP: Add
{opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
PM / OPP: Remove 'operating-points-names' binding
PM / OPP: Rename OPP nodes as opp@
ARM: dts: exynos4412: Rename OPP nodes as opp@
Documentation/devicetree/bindings/opp/opp.txt | 143 +++---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++---
2 files changed, 118 insertions(+), 53 deletions(-)
--
2.6.2.198.g614a2ac
--
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 5/5] ARM: dts: exynos4412: Rename OPP nodes as opp@
OPP bindings got updated to name OPP nodes this way, make changes
according to that.
Signed-off-by: Viresh Kumar
---
arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412.dtsi
b/arch/arm/boot/dts/exynos4412.dtsi
index 294cfe40388d..40beede46e55 100644
--- a/arch/arm/boot/dts/exynos4412.dtsi
+++ b/arch/arm/boot/dts/exynos4412.dtsi
@@ -64,73 +64,73 @@
compatible = "operating-points-v2";
opp-shared;
- opp00 {
+ opp@2 {
opp-hz = /bits/ 64 <2>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp01 {
+ opp@3 {
opp-hz = /bits/ 64 <3>;
opp-microvolt = <90>;
clock-latency-ns = <20>;
};
- opp02 {
+ opp@4 {
opp-hz = /bits/ 64 <4>;
opp-microvolt = <925000>;
clock-latency-ns = <20>;
};
- opp03 {
+ opp@5 {
opp-hz = /bits/ 64 <5>;
opp-microvolt = <95>;
clock-latency-ns = <20>;
};
- opp04 {
+ opp@6 {
opp-hz = /bits/ 64 <6>;
opp-microvolt = <975000>;
clock-latency-ns = <20>;
};
- opp05 {
+ opp@7 {
opp-hz = /bits/ 64 <7>;
opp-microvolt = <987500>;
clock-latency-ns = <20>;
};
- opp06 {
+ opp@8 {
opp-hz = /bits/ 64 <8>;
opp-microvolt = <100>;
clock-latency-ns = <20>;
opp-suspend;
};
- opp07 {
+ opp@9 {
opp-hz = /bits/ 64 <9>;
opp-microvolt = <1037500>;
clock-latency-ns = <20>;
};
- opp08 {
+ opp@10 {
opp-hz = /bits/ 64 <10>;
opp-microvolt = <1087500>;
clock-latency-ns = <20>;
};
- opp09 {
+ opp@11 {
opp-hz = /bits/ 64 <11>;
opp-microvolt = <1137500>;
clock-latency-ns = <20>;
};
- opp10 {
+ opp@12 {
opp-hz = /bits/ 64 <12>;
opp-microvolt = <1187500>;
clock-latency-ns = <20>;
};
- opp11 {
+ opp@13 {
opp-hz = /bits/ 64 <13>;
opp-microvolt = <125>;
clock-latency-ns = <20>;
};
- opp12 {
+ opp@14 {
opp-hz = /bits/ 64 <14>;
opp-microvolt = <1287500>;
clock-latency-ns = <20>;
};
- opp13 {
+ opp@15 {
opp-hz = /bits/ 64 <15>;
opp-microvolt = <135>;
clock-latency-ns = <20>;
--
2.6.2.198.g614a2ac
--
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: IIO device indexing issue
On 5/11/2015 2:53 AM, Vesa Jääskeläinen wrote:
On 04/11/15 11:38, Lars-Peter Clausen wrote:
On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
Hi,
When we were using kernel 3.2 and with that board files we just got IIO
devices with static order so that we knew exactly what iio:device0 is.
Now with device tree that order is not so static anymore especially
when
using device overlays (have not yet tried that thou). If there would be
deferred probe for the device then if we have multiple iio:device's
then
those could in theory be in any order.
In example libiio uses iio device index to open the IIO device. So the
problem is to know what iio:device is what.
If we look files under /sys/bus/iio/iio:deviceX. They do not reveal
what
device this is (especially if there are multiple device of same
type). There
does not seem to be a way to give custom name for the iio device
from device
tree that could have been used as a cue.
Device tree aliases kinda sounded a good idea to try. Eg. define
adc0 alias
and then link it to actual device node in tree.
Aliases could be found under /proc/device-tree/aliases. Looking at
it shows
what device tree node it is. However there does not seem to be
actual link
from any /proc/device-tree entries to kernel drivers exposed under
sysfs.
And even the path components in device tree are not in same format
as in
sysfs. So there is no 1:1 mapping possible here.
IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
devices under /sys/devices and from there is physical path to the
device and
under that the IIO device with the same name as is under /sys/bus/iio.
So in theory we could make a mapping configuration file that specifies
logical name for iio device and then physical parent path for the
device and
then find under it iio:device* files to determine what is the iio
device
index for this physical device. Then open IIO device with that index in
example with libiio. Sounds a bit complex?
So did we miss something on how this should be defined/accessed or
is there
a slight issue here on how to identify iio devices?
Don't know how device tree overlays affect this if we first load
device tree
overlay with some configuration and then unload it and load another
one with
different configuration.
Hi,
Yes, excellent analysis. This is a real issue. As you said there is no
guarantee that the IIO device numbers are stable, they are assigned
in the
order the devices are registered. If the device are registered in a
different order for whatever reason the numbers will change. You can use
readlink on the IIO device in /sys/bus/iio/devices to get its
position in
the global device topology and be able to tell what the parent device
is,
but this path might not be completely stable either though. E.g. if your
device is on a I2C bus and the number of the I2C bus is dynamically
assigned
it might change when the probe order changes.
Alias seem to be one way to solve this issue. The big question
remains is
how to communicate the alias to userspace. For other device classes the
alias index is used as the device index e.g. a device with alias i2c0
ends
up being the i2c adapter with index 0. But with IIO where we support
a wide
range of different devices that does not really work. E.g. what to do
if you
have adc0 and dac0 as aliases for different devices. So you'd need a
different way to expose the alias.
Some bindings also use the "label" property to assign a unique name
to node.
But again the same issue how to expose that information to applications.
To continue from this "label" property idea I was wondering if we
would add it as new optional(?) file node for IIO devices.
One could then specify it like:
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
...
am335x_adc: adc {
compatible = "ti,am3359-adc";
...
label = "Port A";
};
};
And this would generate file /sys/bus/iio/iio:deviceX/label with
contents of "Port A".
Then during the application startup it would just need to scan all
devices under /sys/bus/iio and determine what labelled device it wants
to use.
It would be up to device's developer to determine what labels to use
in their designs. This would not break ABI and would be just an
extension for it.
One could also auto-assign label "am335x_adc" in this case too. But if
you include existing arch device tree then changing label in top level
is kinda a bit annoying as you would then need to duplicate all
properties with another label and disable arch device tree's settings.
Could cause also conflict if there are references elsewhere to
existing arch nodes.
Having following in device's device tree file would allow one to
override label or just only specify that.
#include "am33xx.dtsi"
&tscadc {
status = "okay";
adc {
ti,adc-channels = <4 5 6 7>;
label = "Port A";
};
};
I think this "label" model would be simple to understand.
Whether this ne
Re: [RFC v2 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
Hi Philipp
I'll fixed those comments on V3.
Thank you very much.
Best Regards.
On Mon, 2015-11-02 at 12:34 +0100, Philipp Zabel wrote:
> Hi Jitao,
>
> a few comments below.
>
> Am Montag, den 02.11.2015, 11:54 +0800 schrieb jitao shi:
> [...]
> > > +static int ps8640_check_valid_id(struct ps8640 *ps_bridge)
>
> This could be bool and return true/false.
>
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > + u8 rev_id_low, rev_id_high, chip_id_low, chip_id_high;
> > > + int retry_cnt = 0;
> > > +
> > > + do {
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_CHIP_H,
> > > + &chip_id_high);
> > > + if (chip_id_high != 0x30)
> > > + DRM_INFO("chip_id_high = 0x%x\n", chip_id_high);
> > > + } while ((retry_cnt++ < 2) && (chip_id_high != 0x30));
> > > +
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_REV_L, &rev_id_low);
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_REV_H, &rev_id_high);
> > > + ps8640_regr(client, ps_bridge->base_reg + 4, PAGE4_CHIP_L,
> > > + &chip_id_low);
> > > +
> > > + if ((rev_id_low == 0x00) && (rev_id_high == 0x0a) &&
> > > + (chip_id_low == 0x00) && (chip_id_high == 0x30))
> > > + return 1;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void ps8640_show_mcu_fw_version(struct ps8640 *ps_bridge)
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > + u8 major_ver, minor_ver;
> > > +
> > > + ps8640_regr(client, ps_bridge->base_reg + 5, 0x4, &major_ver);
> > > + ps8640_regr(client, ps_bridge->base_reg + 5, 0x5, &minor_ver);
> > > +
> > > + DRM_INFO_ONCE("ps8640 rom fw version %d.%d\n", major_ver, minor_ver);
> > > +}
> > > +
> > > +static int ps8640_bdg_enable(struct ps8640 *ps_bridge)
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > +
> > > + if (ps8640_check_valid_id(ps_bridge)) {
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xfe, 0x13);
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xff, 0x18);
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xfe, 0x13);
> > > + ps8640_regw(client, ps_bridge->base_reg + 3, 0xff, 0x1c);
>
> Can you introduce #defines with descriptive names for those magic
> constants and register offsets, and maybe also i2c address offsets?
>
> > > +
> > > + return 0;
> > > + }
> > > +
> > > + return -1;
>
> Never return -1 to signal a problem.
> If there was an error, use a proper error code.
>
> > > +}
> > > +
> > > +static void ps8640_prepare(struct ps8640 *ps_bridge)
> > > +{
> > > + struct i2c_client *client = ps_bridge->client;
> > > + int err, retry_cnt = 0;
> > > + u8 set_vdo_done;
> > > +
> > > + if (ps_bridge->enabled)
> > > + return;
> > > +
> > > + if (drm_panel_prepare(ps_bridge->panel)) {
> > > + DRM_ERROR("failed to prepare panel\n");
> > > + return;
> > > + }
> > > +
> > > + err = regulator_enable(ps_bridge->pwr_1v2_supply);
> > > + if (err < 0) {
> > > + DRM_ERROR("failed to enable pwr_1v2_supply: %d\n", err);
>
> Missing panel unprepare.
>
> > > + return;
> > > + }
> > > +
> > > + err = regulator_enable(ps_bridge->pwr_3v3_supply);
> > > + if (err < 0) {
> > > + DRM_ERROR("failed to enable pwr_3v3_supply: %d\n", err);
>
> Missing panel unprepare and vdd12 regulator disable.
>
> > > + return;
> > > + }
> > > +
> > > + gpiod_set_value(ps_bridge->gpio_slp_n, 1);
> > > + gpiod_set_value(ps_bridge->gpio_rst_n, 0);
> > > + usleep_range(500, 700);
> > > + gpiod_set_value(ps_bridge->gpio_rst_n, 1);
> > > +
> > > + do {
> > > + msleep(50);
> > > + ps8640_regr(client, ps_bridge->base_reg + 2, PAGE2_GPIO_H,
> > > + &set_vdo_done);
> > > + } while ((retry_cnt++ < 70) && ((set_vdo_done & PS_GPIO9) != PS_GPIO9));
> > > +
> > > + ps8640_show_mcu_fw_version(ps_bridge);
> > > + ps_bridge->enabled = true;
> > > +}
> > > +
> > > +static void ps8640_pre_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> > > +
> > > + ps8640_prepare(ps_bridge);
> > > +}
> > > +
> > > +static void ps8640_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> > > +
> > > + ps8640_bdg_enable(ps_bridge);
> > > +
> > > + if (drm_panel_enable(ps_bridge->panel)) {
> > > + DRM_ERROR("failed to enable panel\n");
> > > + return;
>
> The return is superfluous.
>
> > > + }
> > > +}
> > > +
> > > +static void ps8640_disable(struct drm_bridge *bridge)
> > > +{
> > > + struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> > > +
> > > + if (!ps_bridge->enabled)
> > > + return;
> > > +
> > > + ps_bridge->enabled = false;
> > > +
> > > + if (drm_panel_disable(ps_bridge->panel)) {
> > > + DRM_ERROR("failed to disable panel\n");
> > > + return;
>
> Shouldn't we still disable the bridge, even if panel disable fails?
>
> > > + }
Re: [RFC v2 1/2] Documentation: bridge: Add documentation for ps8640 DT properties
On Mon, 2015-11-02 at 12:09 +0100, Philipp Zabel wrote:
> Hi Jitao,
>
> Am Montag, den 02.11.2015, 11:53 +0800 schrieb jitao shi:
> [...]
> > > +Example:
> > > + edp-bridge@18 {
> > > + compatible = "parade,ps8640";
> > > + reg = <0x18>;
> > > + sleep-gpios = <&pio 116 GPIO_ACTIVE_HIGH>;
> > > + reset-gpios = <&pio 115 GPIO_ACTIVE_HIGH>;
> > > + mode-sel-gpios = <&pio 92 GPIO_ACTIVE_HIGH>;
> > > + ps8640-1v2-supply = <&ps8640_fixed_1v2>;
>
> This should be vdd12-supply now.
Thanks a lot. I'll fix it on V3.
>
> > > + ps8640-3v3-supply = <&mt6397_vgp2_reg>;
>
> Should be vdd33-supply now.
I'll fix it on V3.
>
> regards
> Philipp
>
--
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/4] ARM: dts: kirkwood: add Linksys EA3500
On Wed, Nov 04, 2015 at 10:25:07PM +, Luka Perkov wrote: > Based on dts files from OpenWrt. Hi Luka Thanks for spending the time to submit these upstream. It looks like a lot of the same comments apply to these files, so i won't keep repeat them. One thing i did notice is that turning off the internal RTC is common, but there is no i2c RTC. Is this correct? Do these devices not have an RTC? Thanks Andrew -- 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/4] ARM: dts: kirkwood: add Seagate GoFlex Home
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/sda1
> rootdelay=10";
It is not normal to specify the root device. Is this really required?
And rootdelay is also unusual.
> + stdout-path = &uart0;
> + };
> +
> + ocp@f100 {
> + pinctrl: pin-controller@1 {
> + pmx_usb_power_enable: pmx-usb-power-enable {
> + marvell,pins = "mpp29";
> + marvell,function = "gpio";
> + };
> + pmx_led_white: pmx-led-white {
> + marvell,pins = "mpp40";
> + marvell,function = "gpio";
> + };
> + pmx_led_green: pmx-led_green {
> + marvell,pins = "mpp46";
That last _ should be -..
> + marvell,function = "gpio";
> + };
> + pmx_led_orange: pmx-led-orange {
> + marvell,pins = "mpp47";
> + marvell,function = "gpio";
> + };
> + };
> + serial@12000 {
> + status = "ok";
> + };
> +
> + sata@8 {
> + status = "okay";
> + nr-ports = <2>;
> + };
> +
> + };
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + health {
> + label = "status:green:health";
This does not fit the naming convention. status should be the machine
name.
Andrew
--
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 1/8] dt-bindings: add documentation of rk3036 clock controller
Hi,
Am Mittwoch, 4. November 2015, 20:18:16 schrieb Xing Zheng:
> Add the devicetree binding for the cru on the rk3036 which quite similar
> structured as previous clock controllers.
>
> Signed-off-by: Xing Zheng
> Reviewed-by: Heiko Stuebner
> ---
your recipient-list is missing the clock maintainers+lists - sorry for
not noticing this earlier.
While the devicetree-maintainers may Review it, we expect the clock-
maintainers to actually apply all 4 clock-related patches.
Same comment is true for
[PATCH v6 2/8] clk: rockchip: add dt-binding header for rk3036
Heiko
>
> Changes in v6: None
>
> .../bindings/clock/rockchip,rk3036-cru.txt | 56
>
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
>
> diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> new file mode 100644
> index 000..ace0599
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/rockchip,rk3036-cru.txt
> @@ -0,0 +1,56 @@
> +* Rockchip RK3036 Clock and Reset Unit
> +
> +The RK3036 clock controller generates and supplies clock to various
> +controllers within the SoC and also implements a reset controller for SoC
> +peripherals.
> +
> +Required Properties:
> +
> +- compatible: should be "rockchip,rk3036-cru"
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- #clock-cells: should be 1.
> +- #reset-cells: should be 1.
> +
> +Optional Properties:
> +
> +- rockchip,grf: phandle to the syscon managing the "general register files"
> + If missing pll rates are not changeable, due to the missing pll lock
> status.
> +
> +Each clock is assigned an identifier and client nodes can use this identifier
> +to specify the clock which they consume. All available clocks are defined as
> +preprocessor macros in the dt-bindings/clock/rk3036-cru.h headers and can be
> +used in device tree sources. Similar macros exist for the reset sources in
> +these files.
> +
> +External clocks:
> +
> +There are several clocks that are generated outside the SoC. It is expected
> +that they are defined using standard clock bindings with following
> +clock-output-names:
> + - "xin24m" - crystal input - required,
> + - "ext_i2s" - external I2S clock - optional,
> + - "ext_gmac" - external GMAC clock - optional
> +
> +Example: Clock controller node:
> +
> + cru: cru@2000 {
> + compatible = "rockchip,rk3036-cru";
> + reg = <0x2000 0x1000>;
> + rockchip,grf = <&grf>;
> +
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + };
> +
> +Example: UART controller node that consumes the clock generated by the clock
> + controller:
> +
> + uart0: serial@2006 {
> + compatible = "snps,dw-apb-uart";
> + reg = <0x2006 0x100>;
> + interrupts = ;
> + reg-shift = <2>;
> + reg-io-width = <4>;
> + clocks = <&cru SCLK_UART0>;
> + };
>
--
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/4] ARM: dts: kirkwood: add Linksys EA3500
Hi Luka
> "lacie,netspace_mini_v2"
> "lacie,netspace_v2"
> "linksys,ea4500"
> +"linksys,ea3500"
Other way around please, to keep the sorted order.
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
stdout = ...
> +&nand {
> + status = "okay";
> + pinctrl-0 = <&pmx_nand>;
> + pinctrl-names = "default";
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x000 0x8>;
> + read-only;
> + };
> +
> + partition@8 {
> + label = "u-boot environment";
> + reg = <0x8 0x2>;
> + };
Same hole?
> + partition@20 {
> + label = "kernel";
> + reg = <0x20 0x20>;
> + };
> +
> + partition@40 {
> + label = "root";
> + reg = <0x40 0x120>;
> + };
> +};
Andrew
--
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/4] ARM: dts: kirkwood: add Linksys EA4500
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 82d2ac9..264f8ba 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -124,6 +124,7 @@ lantiqLantiq Semiconductor
> lenovo Lenovo Group Ltd.
> lg LG Corporation
> linuxLinux-specific binding
> +linksys Belkin International, Inc.
> lsi LSI Corp. (LSI Logic)
> lltc Linear Technology Corporation
> marvell Marvell Technology Group Ltd.
Hi Luka
This part should probably be a patch of its own, sent to the DT
maintainers.
> +/ {
> + model = "Linksys EA4500";
> + compatible = "linksys,ea4500", "marvell,kirkwood-88f6282",
> "marvell,kirkwood";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x 0x800>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
Please use stdout-path = &uart0; You can also put the baud rate etc on
the end.
> +&nand {
> + status = "okay";
> + pinctrl-0 = <&pmx_nand>;
> + pinctrl-names = "default";
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x000 0x8>;
> + };
> +
> + partition@8 {
> + label = "u-boot environment";
> + reg = <0x8 0x2>;
> + };
Is there a hole here?
> +
> + partition@20 {
> + label = "kernel";
> + reg = <0x20 0x20>;
> + };
> +
> + partition@40 {
> + label = "root";
> + reg = <0x40 0x1c0>;
> + };
> +};
> +ð0 {
> + status = "okay";
> + ethernet0-port@0 {
> + speed = <1000>;
> + duplex = <1>;
> + };
> +};
> +
> +ð1 {
> + status = "okay";
> + ethernet1-port@0 {
> + speed = <1000>;
> + duplex = <1>;
> + };
> +};
Why fix the speed? Are they connected to a switch?
Andrew
--
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 6/8] ARM: rockchip: add support smp for rk3036
Am Mittwoch, 4. November 2015, 20:25:16 schrieb Xing Zheng: > From: Heiko Stuebner > > The dual-core Cortex A7 rk3036 is a bit special in that it does not allow > to control the actual powerdomain of the cpu cores, while the rest of the > smp-bringup like reset control and entry address handling stays the same. > Its bigger sibling, the quad-core rk3128 again allows powerdomain control. > > So allow that case by introducing a separate smp-enable-method, that simply > disables powerdomain handling in the common code. > > Signed-off-by: Heiko Stuebner > Tested-by: Xing Zheng > Signed-off-by: Xing Zheng This patch can work standalone, so I took the liberty of applying it to my soc branch for 4.5 already, so you don't need to resend it in future versions. -- 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 v7 45/50] drivers/of: Avoid recursively calling unflatten_dt_node()
On Thu, Nov 05, 2015 at 10:23:15AM +1100, Gavin Shan wrote:
>On Wed, Nov 04, 2015 at 10:07:50AM -0600, Rob Herring wrote:
>>On Wed, Nov 4, 2015 at 7:12 AM, Gavin Shan wrote:
>>> In current implementation, unflatten_dt_node() is called recursively
>>> to unflatten device nodes in FDT blob. It's stress to limited stack
>>> capacity.
>>
>>Did you actually hit a problem?
>>
>>Now we have a max depth of 64. Seems like that should be plenty... Any
>>idea how this compares to when we run out of stack space?
>>
>
>When I rebased last revision (v6), particular below patch, to 4.3.rc6,
>the kernel won't boot in P7 and P8 boxes. On P7 boxes, the stack overruns
>according to the printed kernel messages. On P8 boxes, the /bin/init in
>initramfs image can't be loaded/executed properly and it's potentially
>caused by memory corruption. That's why I reworked it to avoid recursive
>calling to unflatten_dt_node().
>
Missed the link to the patch here:
https://patchwork.ozlabs.org/patch/504512/
>The max depth "64" wasn't selected based on the stack usage. I was thinking
>the device tree is converted to friendly *.dts format and it's using TAB
>as the prefix for each line. If the device tree has 64 depth, Each line
>in *.dts for leaf nodes have to be wrapped and spanning multiple lines.
>That's why I choosed 64, maybe 32 is enough. Did you see a device-tree
>that has more than 16 depth in field? :-)
>
>>> This avoids calling the function recursively, meaning the device
>>> nodes are unflattened in one call on unflatten_dt_node(): two arrays
>>> are introduced to track the parent path size and the device node of
>>> current level of depth, which will be used by the device node on next
>>> level of depth to be unflattened. Also, the parameter "poffset" and
>>> "fpsize" are unused and dropped.
>>
>>Yay. I'm happy to see parameters removed instead of added to this function.
>>
>>>
>>> Signed-off-by: Gavin Shan
>>> ---
>>> drivers/of/fdt.c | 94
>>> +---
>>> 1 file changed, 56 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>>> index 173b036..f4793d0 100644
>>> --- a/drivers/of/fdt.c
>>> +++ b/drivers/of/fdt.c
>>> @@ -355,61 +355,82 @@ static unsigned long populate_node(const void *blob,
>>> return fpsize;
>>> }
>>>
>>> +static void reverse_nodes(struct device_node *parent)
>>> +{
>>> + struct device_node *child, *next;
>>> +
>>> + /* In-depth first */
>>> + child = parent->child;
>>> + while (child) {
>>> + reverse_nodes(child);
>>> +
>>> + child = child->sibling;
>>> + }
>>> +
>>> + /* Reverse the nodes in the child list */
>>> + child = parent->child;
>>> + parent->child = NULL;
>>> + while (child) {
>>> + next = child->sibling;
>>> +
>>> + child->sibling = parent->child;
>>> + parent->child = child;
>>> + child = next;
>>> + }
>>> +}
>>> +
>>> /**
>>> * unflatten_dt_node - Alloc and populate a device_node from the flat tree
>>> * @blob: The parent device tree blob
>>> * @mem: Memory chunk to use for allocating device nodes and properties
>>> - * @poffset: pointer to node in flat tree
>>> * @dad: Parent struct device_node
>>> * @nodepp: The device_node tree created by the call
>>> - * @fpsize: Size of the node path up at the current depth.
>>> * @dryrun: If true, do not allocate device nodes but still calculate
>>> needed
>>> * memory size
>>> */
>>> static void *unflatten_dt_node(const void *blob,
>>>void *mem,
>>> - int *poffset,
>>>struct device_node *dad,
>>>struct device_node **nodepp,
>>> - unsigned long fpsize,
>>>bool dryrun)
>>
>>We can probably further simplify things by returning an int with
>>negative being errors and positive being the size. Also, dryrun can be
>>dropped and implied by mem and/or nodepp being NULL.
>>
>
>Yeah, I think it's reasonable to return "size" from this function. "dryrun"
>can be dropped and implied by NULL @mem. @nodepp can't be NULL. I perhaps
>have separate patch to address it in next revision.
>
>>> {
>>> - struct device_node *np;
>>> - static int depth;
>>> - int old_depth;
>>> -
>>> - fpsize = populate_node(blob, *poffset, &mem, dad, fpsize, &np,
>>> dryrun);
>>> - if (!fpsize)
>>> - return mem;
>>> + struct device_node *root;
>>> + int offset = 0, depth = 0;
>>> + unsigned long fpsizes[64];
>>> + struct device_node *nps[64];
>>
>>Use a define here.
>>
>
>Fair enough, will do in next revision. I'm not good at naming. Would
>"FDT_MAX_DEPTH" is a good one?
>
>>>
>>> - old_depth = depth;
>>> - *poffset = fdt_next_node(blob, *poffset, &depth);
>>> - if (de
Re: [PATCH v7 49/50] drivers/of: Export OF changeset functions
On Wed, Nov 04, 2015 at 10:12:00AM -0600, Rob Herring wrote:
>On Wed, Nov 4, 2015 at 7:12 AM, Gavin Shan wrote:
>> The PowerNV PCI hotplug driver is going to use the OF changeset
>> to manage the changed device sub-tree. This exports those OF
>> changeset functions for that.
>>
>> Signed-off-by: Gavin Shan
>
>Acked-by: Rob Herring
>
Rob, thank you for the quick response :-)
Thanks,
Gavin
>> ---
>> drivers/of/dynamic.c| 65
>> ++---
>> drivers/of/of_private.h | 2 ++
>> drivers/of/overlay.c| 8 +++---
>> drivers/of/unittest.c | 4 ---
>> 4 files changed, 52 insertions(+), 27 deletions(-)
>>
>> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
>> index 53826b8..c647bd1 100644
>> --- a/drivers/of/dynamic.c
>> +++ b/drivers/of/dynamic.c
>> @@ -646,6 +646,7 @@ void of_changeset_init(struct of_changeset *ocs)
>> memset(ocs, 0, sizeof(*ocs));
>> INIT_LIST_HEAD(&ocs->entries);
>> }
>> +EXPORT_SYMBOL_GPL(of_changeset_init);
>>
>> /**
>> * of_changeset_destroy - Destroy a changeset
>> @@ -662,20 +663,9 @@ void of_changeset_destroy(struct of_changeset *ocs)
>> list_for_each_entry_safe_reverse(ce, cen, &ocs->entries, node)
>> __of_changeset_entry_destroy(ce);
>> }
>> +EXPORT_SYMBOL_GPL(of_changeset_destroy);
>>
>> -/**
>> - * of_changeset_apply - Applies a changeset
>> - *
>> - * @ocs: changeset pointer
>> - *
>> - * Applies a changeset to the live tree.
>> - * Any side-effects of live tree state changes are applied here on
>> - * sucess, like creation/destruction of devices and side-effects
>> - * like creation of sysfs properties and directories.
>> - * Returns 0 on success, a negative error value in case of an error.
>> - * On error the partially applied effects are reverted.
>> - */
>> -int of_changeset_apply(struct of_changeset *ocs)
>> +int __of_changeset_apply(struct of_changeset *ocs)
>> {
>> struct of_changeset_entry *ce;
>> int ret;
>> @@ -704,17 +694,30 @@ int of_changeset_apply(struct of_changeset *ocs)
>> }
>>
>> /**
>> - * of_changeset_revert - Reverts an applied changeset
>> + * of_changeset_apply - Applies a changeset
>> *
>> * @ocs: changeset pointer
>> *
>> - * Reverts a changeset returning the state of the tree to what it
>> - * was before the application.
>> - * Any side-effects like creation/destruction of devices and
>> - * removal of sysfs properties and directories are applied.
>> + * Applies a changeset to the live tree.
>> + * Any side-effects of live tree state changes are applied here on
>> + * success, like creation/destruction of devices and side-effects
>> + * like creation of sysfs properties and directories.
>> * Returns 0 on success, a negative error value in case of an error.
>> + * On error the partially applied effects are reverted.
>> */
>> -int of_changeset_revert(struct of_changeset *ocs)
>> +int of_changeset_apply(struct of_changeset *ocs)
>> +{
>> + int ret;
>> +
>> + mutex_lock(&of_mutex);
>> + ret = __of_changeset_apply(ocs);
>> + mutex_unlock(&of_mutex);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(of_changeset_apply);
>> +
>> +int __of_changeset_revert(struct of_changeset *ocs)
>> {
>> struct of_changeset_entry *ce;
>> int ret;
>> @@ -742,6 +745,29 @@ int of_changeset_revert(struct of_changeset *ocs)
>> }
>>
>> /**
>> + * of_changeset_revert - Reverts an applied changeset
>> + *
>> + * @ocs: changeset pointer
>> + *
>> + * Reverts a changeset returning the state of the tree to what it
>> + * was before the application.
>> + * Any side-effects like creation/destruction of devices and
>> + * removal of sysfs properties and directories are applied.
>> + * Returns 0 on success, a negative error value in case of an error.
>> + */
>> +int of_changeset_revert(struct of_changeset *ocs)
>> +{
>> + int ret;
>> +
>> + mutex_lock(&of_mutex);
>> + ret = __of_changeset_revert(ocs);
>> + mutex_unlock(&of_mutex);
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL_GPL(of_changeset_revert);
>> +
>> +/**
>> * of_changeset_action - Perform a changeset action
>> *
>> * @ocs: changeset pointer
>> @@ -779,3 +805,4 @@ int of_changeset_action(struct of_changeset *ocs,
>> unsigned long action,
>> list_add_tail(&ce->node, &ocs->entries);
>> return 0;
>> }
>> +EXPORT_SYMBOL_GPL(of_changeset_action);
>> diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
>> index 8e882e7..829469f 100644
>> --- a/drivers/of/of_private.h
>> +++ b/drivers/of/of_private.h
>> @@ -45,6 +45,8 @@ static inline struct device_node
>> *kobj_to_device_node(struct kobject *kobj)
>> extern int of_property_notify(int action, struct device_node *np,
>> struct property *prop, struct property
>> *old_prop);
>> extern void of_node_release(struct kobject *kobj);
>> +extern int __of_changeset_apply(struct of_changeset *ocs);
>
Re: [PATCH v7 45/50] drivers/of: Avoid recursively calling unflatten_dt_node()
On Wed, Nov 04, 2015 at 10:07:50AM -0600, Rob Herring wrote:
>On Wed, Nov 4, 2015 at 7:12 AM, Gavin Shan wrote:
>> In current implementation, unflatten_dt_node() is called recursively
>> to unflatten device nodes in FDT blob. It's stress to limited stack
>> capacity.
>
>Did you actually hit a problem?
>
>Now we have a max depth of 64. Seems like that should be plenty... Any
>idea how this compares to when we run out of stack space?
>
When I rebased last revision (v6), particular below patch, to 4.3.rc6,
the kernel won't boot in P7 and P8 boxes. On P7 boxes, the stack overruns
according to the printed kernel messages. On P8 boxes, the /bin/init in
initramfs image can't be loaded/executed properly and it's potentially
caused by memory corruption. That's why I reworked it to avoid recursive
calling to unflatten_dt_node().
The max depth "64" wasn't selected based on the stack usage. I was thinking
the device tree is converted to friendly *.dts format and it's using TAB
as the prefix for each line. If the device tree has 64 depth, Each line
in *.dts for leaf nodes have to be wrapped and spanning multiple lines.
That's why I choosed 64, maybe 32 is enough. Did you see a device-tree
that has more than 16 depth in field? :-)
>> This avoids calling the function recursively, meaning the device
>> nodes are unflattened in one call on unflatten_dt_node(): two arrays
>> are introduced to track the parent path size and the device node of
>> current level of depth, which will be used by the device node on next
>> level of depth to be unflattened. Also, the parameter "poffset" and
>> "fpsize" are unused and dropped.
>
>Yay. I'm happy to see parameters removed instead of added to this function.
>
>>
>> Signed-off-by: Gavin Shan
>> ---
>> drivers/of/fdt.c | 94
>> +---
>> 1 file changed, 56 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 173b036..f4793d0 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -355,61 +355,82 @@ static unsigned long populate_node(const void *blob,
>> return fpsize;
>> }
>>
>> +static void reverse_nodes(struct device_node *parent)
>> +{
>> + struct device_node *child, *next;
>> +
>> + /* In-depth first */
>> + child = parent->child;
>> + while (child) {
>> + reverse_nodes(child);
>> +
>> + child = child->sibling;
>> + }
>> +
>> + /* Reverse the nodes in the child list */
>> + child = parent->child;
>> + parent->child = NULL;
>> + while (child) {
>> + next = child->sibling;
>> +
>> + child->sibling = parent->child;
>> + parent->child = child;
>> + child = next;
>> + }
>> +}
>> +
>> /**
>> * unflatten_dt_node - Alloc and populate a device_node from the flat tree
>> * @blob: The parent device tree blob
>> * @mem: Memory chunk to use for allocating device nodes and properties
>> - * @poffset: pointer to node in flat tree
>> * @dad: Parent struct device_node
>> * @nodepp: The device_node tree created by the call
>> - * @fpsize: Size of the node path up at the current depth.
>> * @dryrun: If true, do not allocate device nodes but still calculate needed
>> * memory size
>> */
>> static void *unflatten_dt_node(const void *blob,
>>void *mem,
>> - int *poffset,
>>struct device_node *dad,
>>struct device_node **nodepp,
>> - unsigned long fpsize,
>>bool dryrun)
>
>We can probably further simplify things by returning an int with
>negative being errors and positive being the size. Also, dryrun can be
>dropped and implied by mem and/or nodepp being NULL.
>
Yeah, I think it's reasonable to return "size" from this function. "dryrun"
can be dropped and implied by NULL @mem. @nodepp can't be NULL. I perhaps
have separate patch to address it in next revision.
>> {
>> - struct device_node *np;
>> - static int depth;
>> - int old_depth;
>> -
>> - fpsize = populate_node(blob, *poffset, &mem, dad, fpsize, &np,
>> dryrun);
>> - if (!fpsize)
>> - return mem;
>> + struct device_node *root;
>> + int offset = 0, depth = 0;
>> + unsigned long fpsizes[64];
>> + struct device_node *nps[64];
>
>Use a define here.
>
Fair enough, will do in next revision. I'm not good at naming. Would
"FDT_MAX_DEPTH" is a good one?
>>
>> - old_depth = depth;
>> - *poffset = fdt_next_node(blob, *poffset, &depth);
>> - if (depth < 0)
>> - depth = 0;
>> - while (*poffset > 0 && depth > old_depth)
>> - mem = unflatten_dt_node(blob, mem, poffset, np, NULL,
>> - fpsize, dryrun);
>> + if (nodepp)
>> + *node
Re: [PATCH v7 44/50] drivers/of: Split unflatten_dt_node()
On Wed, Nov 04, 2015 at 12:43:08PM -0600, Rob Herring wrote:
>On Wed, Nov 4, 2015 at 7:12 AM, Gavin Shan wrote:
>> The function unflatten_dt_node() is called recursively to unflatten
>> device nodes and properties in the FDT blob. It looks complicated
>> and hard to be understood.
>>
>> This splits the function into 3 functions: populate_properties(),
>> populate_node() and unflatten_dt_node(). populate_properties(),
>> which is called by populate_node(), creates properties for the
>> indicated device node. The later one creates the device nodes
>> from FDT blob. populate_node() gets the offset in FDT blob for
>> next device nodes and then calls populate_node(). No logical
>> changes introduced.
>>
>> Signed-off-by: Gavin Shan
>> ---
>> drivers/of/fdt.c | 275
>> ---
>> 1 file changed, 160 insertions(+), 115 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 6e82bc42..173b036 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -160,39 +160,127 @@ static void *unflatten_dt_alloc(void **mem, unsigned
>> long size,
>> return res;
>> }
>>
>> -/**
>> - * unflatten_dt_node - Alloc and populate a device_node from the flat tree
>> - * @blob: The parent device tree blob
>> - * @mem: Memory chunk to use for allocating device nodes and properties
>> - * @poffset: pointer to node in flat tree
>> - * @dad: Parent struct device_node
>> - * @nodepp: The device_node tree created by the call
>> - * @fpsize: Size of the node path up at the current depth.
>> - * @dryrun: If true, do not allocate device nodes but still calculate needed
>> - * memory size
>> - */
>> -static void * unflatten_dt_node(const void *blob,
>> - void *mem,
>> - int *poffset,
>> - struct device_node *dad,
>> - struct device_node **nodepp,
>> - unsigned long fpsize,
>> +static void populate_properties(const void *blob,
>> + int offset,
>> + void **mem,
>> + struct device_node *np,
>> + const char *nodename,
>> bool dryrun)
>
>I'd like to make dryrun implicit. It is basically a function of NULL
>or near NULL pointers.
>
[1] The condition would be something like below:
if ((unsigned long)(*mem) < limit)
dryrun = true;
else
dryrun = false;
The question here is how to choose a sane @limit in practice. In !dryrun case,
the memory is allocated from memblock at system booting time, or slab when
system
is up. memblock could assign memory in bottom-up fasion.
When @limit is too small, the condition wouldn't be comprehensive in !dryrun
case. When @limit is too large, the !dryrun cases can be regarded as dryrun
case.
>> {
>> - const __be32 *p;
>> + struct property *pp, **pprev = NULL;
>> + int cur;
>> + bool has_name = false;
>> +
>> + pprev = &np->properties;
>> + cur = fdt_first_property_offset(blob, offset);
>> + while (cur >= 0) {
>
>This could be better written as a for loop to avoid the gotos:
>
>for (cur = fdt_first_property_offset(blob, offset); cur >=0; cur =
>fdt_next_property_offset(blob, cur))
>
Thanks, the changes will be included in next revision.
>> + const __be32 *val;
>> + const char *pname;
>> + u32 sz;
>> +
>> + val = fdt_getprop_by_offset(blob, cur, &pname, &sz);
>> + if (!val) {
>> + pr_warn("%s: Cannot locate property at 0x%x\n",
>> + __func__, cur);
>> + goto next;
>> + }
>> +
>> + if (!pname) {
>> + pr_warn("%s: Cannot find property name at 0x%x\n",
>> + __func__, cur);
>> + goto next;
>> + } else if (!strcmp(pname, "name")) {
>> + has_name = true;
>> + }
>> +
>> + pp = unflatten_dt_alloc(mem, sizeof(struct property),
>> + __alignof__(struct property));
>> + if (!dryrun) {
>
>Then:
>
>if (dryrun)
> continue;
>
>to save some indentation and vertical code.
>
Good idea, it will be included in next revision.
>> + /* We accept flattened tree phandles either in
>> +* ePAPR-style "phandle" properties, or the
>> +* legacy "linux,phandle" properties. If both
>> +* appear and have different values, things
>> +* will get weird. Don't do that.
>> +*/
>> + if (!strcmp(pname, "phandle") ||
>> + !strcmp(pname, "linux,phandle")) {
>> +
Re: [PATCH v3 3/6] Documentation: tps65086: Add DT bindings for the TPS65086 GPO controller
On Wed, Nov 04, 2015 at 11:12:12AM -0600, Andrew F. Davis wrote:
> The TPS65086 PMIC contains several regulators and a GPO controller.
> Add bindings for the TPS65086 GPO controller.
>
> Signed-off-by: Andrew F. Davis
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/gpio/gpio-tps65086.txt | 16
>
> 1 file changed, 16 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
> b/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
> new file mode 100644
> index 000..ba05107
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-tps65086.txt
> @@ -0,0 +1,16 @@
> +* TPS65086 GPO Controller bindings
> +
> +Required properties:
> + - compatible: Should be "ti,tps65086-gpio".
> + - gpio-controller : Marks the device node as a GPIO Controller.
> + - #gpio-cells : Should be two. The first cell is the pin
> number
> + and the second cell is used to specify flags.
> + See ../gpio/gpio.txt for possible values.
> +
> +Example:
> +
> + gpio4: gpio {
> + compatible = "ti,tps65086-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> --
> 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 1/4] ARM: dts: kirkwood: add Linksys EA4500
On Wed, Nov 04, 2015 at 11:41:01PM +0100, Arnd Bergmann wrote:
> On Wednesday 04 November 2015 22:25:05 Luka Perkov wrote:
> > +/ {
> > + model = "Linksys EA4500";
> > + compatible = "linksys,ea4500", "marvell,kirkwood-88f6282",
> > "marvell,kirkwood";
>
> According to https://wikidevi.com/wiki/Linksys_EA4500 there are multiple
> versions
> of this device, and at least EA4500v3 is completely incompatible with the
> version
> in this patch. Should we add "linksys,ea4500v1" as a compatible string to
> identify
> this better?
Right. I'll send v2 after getting some more comments.
Luka
--
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/6] Documentation: tps65086: Add DT bindings for the TPS65086 PMIC
On Wed, Nov 04, 2015 at 11:12:10AM -0600, Andrew F. Davis wrote:
> The TPS65086 PMIC contains several regulators and a GPO controller.
> Add bindings for the TPS65086 PMIC.
>
> Signed-off-by: Andrew F. Davis
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/mfd/tps65086.txt | 46
> ++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/tps65086.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/tps65086.txt
> b/Documentation/devicetree/bindings/mfd/tps65086.txt
> new file mode 100644
> index 000..2fd5394
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/tps65086.txt
> @@ -0,0 +1,46 @@
> +* TPS65086 Power Management Integrated Circuit bindings
> +
> +Required properties:
> + - compatible: Should be "ti,tps65086".
> + - reg : I2C slave address.
> + - interrupt-parent : Phandle to he parent interrupt controller.
> + - interrupts: The interrupt line the device is connected to.
> + - interrupt-controller : Marks the device node as an interrupt
> controller.
> + - #interrupt-cells : The number of cells to describe an IRQ, this
> + should be 2. The first cell is the IRQ number,
> + the second cell is the flags, encoded as the trigger
> + masks from .
> +
> +Additional nodes defined in:
> + - Regulators: ../regulator/tps65086-regulator.txt
> + - GPIO : ../gpio/gpio-tps65086.txt
> +
> +Example:
> +
> + pmic: tps65086@5e {
> + compatible = "ti,tps65086";
> + reg = <0x5e>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + regulators {
> + compatible = "ti,tps65086-regulator";
> +
> + buck1 {
> + regulator-name = "vcc1";
> + regulator-min-microvolt = <160>;
> + regulator-max-microvolt = <160>;
> + regulator-boot-on;
> + ti,regulator-decay;
> + ti,regulator-step-size-25mv;
> + };
> + };
> +
> + gpio4: gpio {
> + compatible = "ti,tps65086-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> --
> 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 2/6] Documentation: tps65086: Add DT bindings for the TPS65086 regulators
On Wed, Nov 04, 2015 at 11:12:11AM -0600, Andrew F. Davis wrote:
> The TPS65086 PMIC contains several regulators and a GPO controller.
> Add bindings for the TPS65086 regulators.
>
> Signed-off-by: Andrew F. Davis
Acked-by: Rob Herring
> ---
> .../bindings/regulator/tps65086-regulator.txt | 35
> ++
> 1 file changed, 35 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
>
> diff --git
> a/Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
> b/Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
> new file mode 100644
> index 000..de7d2d6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/tps65086-regulator.txt
> @@ -0,0 +1,35 @@
> +* TPS65086 regulator bindings
> +
> +Required properties:
> + - compatible: Should be "ti,tps65086-regulator".
> + - list of regulators provided by this controller, must be named after their
> + hardware counterparts: buck[1-6], ldoa[1-3], swa1, swb[1-2], and vtt.
> +
> +Optional properties:
> + - Per-regulator optional properties are defined in regulator.txt.
> + - ti,regulator-step-size-25mv : This is applicable for buck[1,2,6],
> set this
> + if the regulator is factory set with a 25mv
> + step voltage mapping.
> + - ti,regulator-decay: This is applicable for buck[1-6], set
> this if
> + the output needs to decay, default is for the
> + output to slew down.
> +
> +Example:
> +
> + regulators {
> + compatible = "ti,tps65086-regulator";
> +
> + buck1 {
> + regulator-name = "vcc1";
> + regulator-min-microvolt = <160>;
> + regulator-max-microvolt = <160>;
> + regulator-boot-on;
> + ti,regulator-step-size-25mv;
> + ti,regulator-decay;
> + };
> +
> + swa1 {
> + regulator-name = "ls1";
> + 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 2/4] ARM: dts: kirkwood: add Linksys EA3500
Based on dts files from OpenWrt.
Signed-off-by: Luka Perkov
---
.../devicetree/bindings/arm/marvell,kirkwood.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-ea3500.dts | 149 +
3 files changed, 151 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-ea3500.dts
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
index 7a99d4a..ed381a3 100644
--- a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
@@ -50,6 +50,7 @@ board. Currently known boards are:
"lacie,netspace_mini_v2"
"lacie,netspace_v2"
"linksys,ea4500"
+"linksys,ea3500"
"marvell,db-88f6281-bp"
"marvell,db-88f6282-bp"
"marvell,mv88f6281gtw-ge"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index a16c04b..ebe5b73 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -168,6 +168,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-ds411.dtb \
kirkwood-ds411j.dtb \
kirkwood-ds411slim.dtb \
+ kirkwood-ea3500.dtb \
kirkwood-ea4500.dtb \
kirkwood-goflexnet.dtb \
kirkwood-guruplug-server-plus.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-ea3500.dts
b/arch/arm/boot/dts/kirkwood-ea3500.dts
new file mode 100644
index 000..3a064f6
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ea3500.dts
@@ -0,0 +1,149 @@
+/*
+ * kirkwood-ea3500.dts - Device Tree file for Linksys EA3500
+ *
+ * (c) 2013 Jonas Gorski
+ * (c) 2013 Deutsche Telekom Innovation Laboratories
+ * (c) 2014 Luka Perkov
+ * (c) 2014 Dan Walters
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
+
+/ {
+ model = "Linksys EA3500";
+ compatible = "linksys,ea3500", "marvell,kirkwood-88f6282",
"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x400>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ };
+
+ mbus {
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ status = "okay";
+ };
+
+ pcie@2,0 {
+ status = "okay";
+ };
+ };
+ };
+
+ ocp@f100 {
+ pinctrl: pin-controller@1 {
+ pmx_led_green_power: pmx-led-green-power {
+ marvell,pins = "mpp7";
+ marvell,function = "gpo";
+ };
+ pmx_btn_wps: pmx-btn-wps {
+ marvell,pins = "mpp47";
+ marvell,function = "gpio";
+ };
+ pmx_btn_reset: pmx-btn-reset {
+ marvell,pins = "mpp48";
+ marvell,function = "gpio";
+ };
+ };
+
+ rtc@10300 {
+ status = "disabled";
+ };
+
+ serial@12000 {
+ status = "okay";
+ };
+
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = < &pmx_btn_wps &pmx_btn_reset >;
+ pinctrl-names = "default";
+
+ button@15 {
+ label = "WPS Button";
+ linux,code = ;
+ gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+ };
+
+ button@16 {
+ label = "Reset Button";
+ linux,code = ;
+ gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = < &pmx_led_green_power >;
+ pinctrl-names = "default";
+
+ green-power {
+ label = "ea3500:green:power";
+ gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&nand {
+ status = "okay";
+ pinctrl-0 = <&pmx_nand>;
+ pinctrl-names = "default";
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x000 0x8>;
+ read-only;
+ };
+
+ partition@8 {
+ label = "u-boot environment";
+ reg = <0x8 0x2>;
+ };
+
+ partition@20 {
+ label = "kernel";
+
[PATCH 1/4] ARM: dts: kirkwood: add Linksys EA4500
Based on dts files from OpenWrt.
Signed-off-by: Luka Perkov
---
.../devicetree/bindings/arm/marvell,kirkwood.txt | 1 +
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-ea4500.dts | 156 +
4 files changed, 159 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-ea4500.dts
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
index 5171ad8..7a99d4a 100644
--- a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
@@ -49,6 +49,7 @@ board. Currently known boards are:
"lacie,netspace_max_v2"
"lacie,netspace_mini_v2"
"lacie,netspace_v2"
+"linksys,ea4500"
"marvell,db-88f6281-bp"
"marvell,db-88f6282-bp"
"marvell,mv88f6281gtw-ge"
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..264f8ba 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -124,6 +124,7 @@ lantiq Lantiq Semiconductor
lenovo Lenovo Group Ltd.
lg LG Corporation
linux Linux-specific binding
+linksysBelkin International, Inc.
lsiLSI Corp. (LSI Logic)
lltc Linear Technology Corporation
marvellMarvell Technology Group Ltd.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..a16c04b 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -168,6 +168,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-ds411.dtb \
kirkwood-ds411j.dtb \
kirkwood-ds411slim.dtb \
+ kirkwood-ea4500.dtb \
kirkwood-goflexnet.dtb \
kirkwood-guruplug-server-plus.dtb \
kirkwood-ib62x0.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-ea4500.dts
b/arch/arm/boot/dts/kirkwood-ea4500.dts
new file mode 100644
index 000..caccc8e
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-ea4500.dts
@@ -0,0 +1,156 @@
+/*
+ * kirkwood-ea4500.dts - Device Tree file for Linksys EA4500
+ *
+ * (c) 2013 Jonas Gorski
+ * (c) 2013 Deutsche Telekom Innovation Laboratories
+ * (c) 2014 Luka Perkov
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6282.dtsi"
+
+/ {
+ model = "Linksys EA4500";
+ compatible = "linksys,ea4500", "marvell,kirkwood-88f6282",
"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x800>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ };
+
+ mbus {
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ status = "okay";
+ };
+
+ pcie@2,0 {
+ status = "okay";
+ };
+ };
+ };
+
+ ocp@f100 {
+ pinctrl: pin-controller@1 {
+ pmx_led_white_health: pmx-led-white-health {
+ marvell,pins = "mpp7";
+ marvell,function = "gpo";
+ };
+ pmx_led_white_pulse: pmx-led-white-pulse {
+ marvell,pins = "mpp14";
+ marvell,function = "gpio";
+ };
+ pmx_btn_wps: pmx-btn-wps {
+ marvell,pins = "mpp47";
+ marvell,function = "gpio";
+ };
+ pmx_btn_reset: pmx-btn-reset {
+ marvell,pins = "mpp48";
+ marvell,function = "gpio";
+ };
+ };
+
+ rtc@10300 {
+ status = "disabled";
+ };
+
+ serial@12000 {
+ status = "okay";
+ };
+
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = < &pmx_btn_wps &pmx_btn_reset >;
+ pinctrl-names = "default";
+
+ button@15 {
+ label = "WPS Button";
+ linux,code = ;
+ gpios = <&gpio1 15 GPIO_ACTIVE_LOW>;
+ };
+
+ button@16 {
+ label = "Reset Button";
+ linux,code = ;
+ gpios = <&gpio1 16 GPIO_ACT
Re: [PATCH 1/4] ARM: dts: kirkwood: add Linksys EA4500
On Wednesday 04 November 2015 22:25:05 Luka Perkov wrote:
> +/ {
> + model = "Linksys EA4500";
> + compatible = "linksys,ea4500", "marvell,kirkwood-88f6282",
> "marvell,kirkwood";
According to https://wikidevi.com/wiki/Linksys_EA4500 there are multiple
versions
of this device, and at least EA4500v3 is completely incompatible with the
version
in this patch. Should we add "linksys,ea4500v1" as a compatible string to
identify
this better?
Arnd
--
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 4/4] ARM: dts: kirkwood: add ZyXEL NSA310s
Based on dts files from OpenWrt.
Signed-off-by: Luka Perkov
Signed-off-by: Tony Dinh
---
.../devicetree/bindings/arm/marvell,kirkwood.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-nsa310s.dts | 282 +
3 files changed, 284 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-nsa310s.dts
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
index 37bd190..8a1a7f7 100644
--- a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
@@ -101,3 +101,4 @@ board. Currently known boards are:
"usi,topkick-1281P2"
"zyxel,nsa310"
"zyxel,nsa310a"
+"zyxel,nsa310s"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 1d6fb0d..b2ea55f 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -196,6 +196,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-ns2mini.dtb \
kirkwood-nsa310.dtb \
kirkwood-nsa310a.dtb \
+ kirkwood-nsa310s.dtb \
kirkwood-openblocks_a6.dtb \
kirkwood-openblocks_a7.dtb \
kirkwood-openrd-base.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-nsa310s.dts
b/arch/arm/boot/dts/kirkwood-nsa310s.dts
new file mode 100644
index 000..afc8ecf
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-nsa310s.dts
@@ -0,0 +1,282 @@
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
+
+/ {
+ model = "ZyXEL NSA310S";
+ compatible = "zyxel,nsa310s", "marvell,kirkwood-88f6702",
"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk";
+ stdout-path = &uart0;
+ };
+
+ mbus {
+ pcie-controller {
+ status = "okay";
+
+ pcie@1,0 {
+ status = "okay";
+ };
+ };
+ };
+
+ ocp@f100 {
+ pinctrl: pin-controller@1 {
+ pinctrl-names = "default";
+
+ pmx_sata0: pmx-sata0 {
+ marvell,pins;
+ marvell,function = "sata0";
+ };
+ pmx_sata1: pmx-sata1 {
+ marvell,pins;
+ marvell,function = "sata1";
+ };
+ pmx_usb_power: pmx-usb-power {
+ marvell,pins = "mpp21";
+ marvell,function = "gpio";
+ };
+ pmx_pwr_off: pmx-pwr-off {
+ marvell,pins = "mpp27";
+ marvell,function = "gpio";
+ };
+ pmx_btn_reset: pmx-btn-reset {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+ pmx_btn_copy: pmx-btn-copy {
+ marvell,pins = "mpp25";
+ marvell,function = "gpio";
+ };
+ pmx_btn_power: pmx-btn-power {
+ marvell,pins = "mpp26";
+ marvell,function = "gpio";
+ };
+ pmx_led_hdd2_green: pmx-led-hdd2-green {
+ marvell,pins = "mpp34";
+ marvell,function = "gpio";
+ };
+ pmx_led_hdd2_red: pmx-led-hdd2-red {
+ marvell,pins = "mpp12";
+ marvell,function = "gpio";
+ };
+ pmx_led_usb_green: pmx-led-usb-green {
+ marvell,pins = "mpp15";
+ marvell,function = "gpio";
+ };
+ pmx_led_copy_green: pmx-led-copy-green {
+ marvell,pins = "mpp22";
+ marvell,function = "gpio";
+ };
+ pmx_led_copy_red: pmx-led-copy-red {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+ pmx_led_sys_green: pmx-led-sys-green {
+ marvell,pins = "mpp28";
+ marvell,function = "gpio";
+ };
+ pmx_led_sys_orange: pmx-led-sys-orange {
+ marvell,pins = "mpp29";
+
[PATCH 3/4] ARM: dts: kirkwood: add Seagate GoFlex Home
Based on dts files from OpenWrt.
Signed-off-by: Luka Perkov
---
.../devicetree/bindings/arm/marvell,kirkwood.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/kirkwood-goflexhome.dts | 127 +
3 files changed, 129 insertions(+)
create mode 100644 arch/arm/boot/dts/kirkwood-goflexhome.dts
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
index ed381a3..37bd190 100644
--- a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
@@ -72,6 +72,7 @@ board. Currently known boards are:
"raidsonic,ib-nas6220-b"
"raidsonic,ib-nas62x0"
"seagate,dockstar"
+"seagate,goflexhome"
"seagate,goflexnet"
"synology,ds109"
"synology,ds110jv10"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ebe5b73..1d6fb0d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -170,6 +170,7 @@ dtb-$(CONFIG_MACH_KIRKWOOD) += \
kirkwood-ds411slim.dtb \
kirkwood-ea3500.dtb \
kirkwood-ea4500.dtb \
+ kirkwood-goflexhome.dtb \
kirkwood-goflexnet.dtb \
kirkwood-guruplug-server-plus.dtb \
kirkwood-ib62x0.dtb \
diff --git a/arch/arm/boot/dts/kirkwood-goflexhome.dts
b/arch/arm/boot/dts/kirkwood-goflexhome.dts
new file mode 100644
index 000..5f933d4
--- /dev/null
+++ b/arch/arm/boot/dts/kirkwood-goflexhome.dts
@@ -0,0 +1,127 @@
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
+
+/ {
+ model = "Seagate GoFlex Home";
+ compatible = "seagate,goflexhome", "marvell,kirkwood-88f6281",
"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x800>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 earlyprintk root=/dev/sda1
rootdelay=10";
+ stdout-path = &uart0;
+ };
+
+ ocp@f100 {
+ pinctrl: pin-controller@1 {
+ pmx_usb_power_enable: pmx-usb-power-enable {
+ marvell,pins = "mpp29";
+ marvell,function = "gpio";
+ };
+ pmx_led_white: pmx-led-white {
+ marvell,pins = "mpp40";
+ marvell,function = "gpio";
+ };
+ pmx_led_green: pmx-led_green {
+ marvell,pins = "mpp46";
+ marvell,function = "gpio";
+ };
+ pmx_led_orange: pmx-led-orange {
+ marvell,pins = "mpp47";
+ marvell,function = "gpio";
+ };
+ };
+ serial@12000 {
+ status = "ok";
+ };
+
+ sata@8 {
+ status = "okay";
+ nr-ports = <2>;
+ };
+
+ };
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ health {
+ label = "status:green:health";
+ gpios = <&gpio1 14 1>;
+ linux,default-trigger = "default-on";
+ };
+ fault {
+ label = "status:orange:fault";
+ gpios = <&gpio1 15 1>;
+ };
+ misc {
+ label = "status:white:misc";
+ gpios = <&gpio1 8 1>;
+ linux,default-trigger = "ide-disk";
+ };
+ };
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <&pmx_usb_power_enable>;
+ pinctrl-names = "default";
+
+ usb_power: regulator@1 {
+ compatible = "regulator-fixed";
+ reg = <1>;
+ regulator-name = "USB Power";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&nand {
+ chip-delay = <40>;
+ status = "okay";
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x000 0x10>;
+ read-only;
+ };
+
+ partition@10 {
+ label = "uImage";
+ reg = <0x010 0x40>;
+ };
+
+ partition@50 {
+ label = "pogoplug";
+ reg = <0x050 0x200>;
+ };
+
Re: [linux-sunxi] [PATCH v4 2/6] clk: sunxi: Add H3 clocks support
Hi Maxime,
On Thu, Nov 5, 2015 at 3:23 AM, Maxime Ripard
wrote:
> Hi Julian,
>
> On Wed, Oct 28, 2015 at 10:12:09AM +1100, Julian Calaby wrote:
>> > + of_property_for_each_u32(node, "clock-indices", prop, p, index) {
>> > + of_property_read_string_index(node, "clock-output-names",
>> > + i, &clk_name);
>> > +
>> > + if (index == 17 || (index >= 29 && index <= 31))
>> > + clk_parent = AHB2;
>> > + else if (index <= 63 || index >= 128)
>> > + clk_parent = AHB1;
>> > + else if (index >= 64 && index <= 95)
>> > + clk_parent = APB1;
>> > + else if (index >= 96 && index <= 127)
>> > + clk_parent = APB2;
>>
>> A way to make this reusable in the future might be to encode it in a
>> structure like:
>>
>> static const struct bus_clock_paths sun8i_h3_bus_clock_paths __initdata = {
>> {.parent = 2, .min = 17, .max = 17}, /* index 17 is from AHB2 */
>> {.parent = 2, .min = 29, .max = 31}, /* AHB2 bank */
>> {.parent = 1, .min = 63, .max = 128}, /* AHB1 bank */
>> ...
>> {}
>> };
>>
>> Then the code here can be reused for other clocks like this in the
>> future without too much bloat. (And this would potentially could be
>> generic enough for other platforms.)
>
> We don't really need that at the moment. There's not point in writing
> more complicated code to support a use case we don't have yet.
>
> (However, something along these lines will definitely be needed if we
> ever have another SoC having the same bus gates madness)
This was a suggestion for the future to address Jens' comment about
having a bus clock driver instead of encoding it in devicetree.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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] PM / OPP: Add "opp-supported-hw" binding
On 11/03, Viresh Kumar wrote: > On 02-11-15, 11:21, Stephen Boyd wrote: > > Ah I see that after looking at the previous thread. Perhaps we > > can add such information into the documentation so that people > > aren't misled into thinking they're limited to 32 bits? > > What about these changes: Yep looks good. Assuming this is squashed into the original: Reviewed-by: Stephen Boyd One typo below. > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt > b/Documentation/devicetree/bindings/opp/opp.txt > index 96892057586a..b6ca2239838b 100644 > --- a/Documentation/devicetree/bindings/opp/opp.txt > +++ b/Documentation/devicetree/bindings/opp/opp.txt > @@ -123,11 +123,15 @@ properties. > - opp-suspend: Marks the OPP to be used during device suspend. Only one OPP > in >the table should have this. > > -- opp-supported-hw: User defined array containing a hierarchy of hardware > - version numbers, supported by the OPP. For example: a platform with > hierarchy > - of three levels of versions (A, B and C), this field should be like Z>, > - where X corresponds to Version hierarchy A, Y corresponds to version > hierarchy > - B and Z corresponds to version hierarchy C. > +- opp-supported-hw: This enables us to select only a subset of OPPs from the > + larger OPP table, based on what version of the hardware we are running on. > We > + still can't have multiple nodes with the same opp-hz value in OPP table. > + > + Its an user defined array containing a hierarchy of hardware version > numbers, s/Its/It's/ -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] PM / OPP: Add "opp-supported-hw" binding
On 11/03, Viresh Kumar wrote:
> On 30-10-15, 15:18, Stephen Boyd wrote:
> > A side-note. I wonder if it would be better style to have the
> > node name be:
> >
> > opp@6 {
> >
> > At least it seems that the assumption is we can store all the
> > possible combinations of OPP values for a particular frequency in
> > the same node. Following this style would make dt compilation
> > fail if two nodes have the same frequency.
>
> From: Viresh Kumar
> Date: Tue, 3 Nov 2015 07:51:09 +0530
> Subject: [PATCH] PM / OPP: Rename OPP nodes as opp@
>
> It would be better to name OPP nodes as opp@ as that will ensure
> that multiple DT nodes don't contain the same frequency. Of course we
> expect the writer to name the node with its opp-hz frequency and not any
> other frequency.
>
> And that will let the compile error out if multiple nodes are using the
> same opp-hz frequency.
>
> Suggested-by: Stephen Boyd
> Signed-off-by: Viresh Kumar
> ---
Reviewed-by: Stephen Boyd
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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: sun4i: inet9f-rev03: Add support for game buttons / joysticks
On Tue, Nov 03, 2015 at 04:51:48PM +0100, Hans de Goede wrote: > The inet9f-rev03 tablet has multiple fire-buttons / direction controls, > add support for these using the same axis mapping as ps2 compatible game > controllers with the same stick / button layout use. > > Signed-off-by: Hans de Goede Queued for 4.5, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor
On 11/04/2015 01:40 PM, Jonathan Cameron wrote:
On 02/11/15 20:37, Andrew F. Davis wrote:
On 11/01/2015 02:52 PM, Jonathan Cameron wrote:
On 31/10/15 16:31, Andrew F. Davis wrote:
Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
This device detects reflected LED light fluctuations and presents an ADC
value to the user space for further signal processing.
Data sheet located here:
http://www.ti.com/product/AFE4404/datasheet
Signed-off-by: Andrew F. Davis
Hi Andrew,
Good to see this resurface. It's a fascinating little device.
Anyhow, most of the interesting bit in here is unsuprisingly concerned
with the interface. I know we went round a few loops of this before but
it still feels like we haven't worked out to handle it well. I would like
as much input as we can get on this as inevitablly it will have
repercussions outside this driver.
Your approach of hammering out descriptive sysfs attributes is a good
starting point but we need to work towards a formal description that
can be generalised. Whilst there are not many similar devices out there
to this one, I suspect there are a few and more may well show up in
future.
Yeah, I'm working on brining up drivers for them now :)
cool
The escence of my rather roundabout response inline is that I'm suggesting
adding a new channel type to represent light transmission, taking the analogous
case of proximity devices in which we are looking at light reflection.
I've also taken the justification we use for illuminance vs intensity readings
for two sensor ALS sensors as a precident for having compound channels of a
different
type to the 'raw' data that feeds them. Hence I propose something along
the lines of:
in_intensityX_raw (raw channel value with the led on)
in_intensityX_ambient_raw (raw channel value with the led off)
I'm not sure, I know it may be too late for a lot of drivers but putting the 'X'
against the 'intensity' works for devices like ADCs/DACs with a simple list
of numeric channels, but for any other device with named channels this will
become very inconsistent, especially when adding modified channels and
differential channels.
Sadly its ABI now so we can't realistically change it. We can extend, we can't
replace (we we can over the course of a lot of years but that's a nightmare).
For example:
in_intensity5_name_ambient-2_mean_raw
The oddity here is that in your case the device in interacting with a stimulus
output. Normally the index reflects an actual sensor. We are kind of
bludgeoning
it in. The only equivalently nasty case I know of is touch screens where
different
resistances are being connected - from a generic point of view those are a
nightmare
as well (as every implementation does it differently).
Yeah, this part really doesn't fit the mold for this subsystem, or
any really, hwmon, input, were also considered, but the plan is still
to attempt to shoehorn it in to this one, so hopefully you can bear with me
on all these oddities :)
This is the differential of name and an unnamed channel '2', also something
is an average, is it channel '2', is it the whole differential channel? Is
5 this channels id or part of the first differential channel name? Who knows!
The way I would do it is with this more universal format:
[direction]_[type]_[name|number]_[info]
Hind sight is a great thing in that the extra _ would have made parsing
marginally
easier.
And then we just drop trying to deal with modifiers and differential stuff
internally, just let the driver give the channel a name with those. We then
wouldn't need to deal with channels numbers ether, just names.
See my reply to the cover letter thread. You can't pass a name in an event
to userspace and we'd end up string matching all over the place or you end
up not encoding the information currently in the modifier at all.
Perhaps you are right in that it would still have been neater but such is hind
sight!
Time for IIO2 :)
The one I wonder about occasionally is similar to what you suggest, but don't
ever having anything other than number (and I'd keep the differential channels.
Then have an extra sysfs attribute that provides the modifier string.
Then I'm not sure it gains us much.
Also note that in the classic ADC case (and there are a whole load more
of those than weird light sensors ;) there are only indexes and differential
channels
so it all becomes rather cleaner.
in_voltage0-1_raw
It's also worth noting that whilst we do allow freeform extend_name elements
they are very rarely accepted in drivers as the moment you do that you have
something that standard userspace code won't know what to do with.
struct iio_chan_spec {
enum iio_chan_typetype;
const char*name;
unsigned longaddress;
intscan_index;
struct {
charsign;
u8realbits;
u8storagebits;
u8shift;
u8repeat;
enum iio_endian endiann
Re: [PATCH 2/2] dt-bindings: phy: tegra-xusb-padctl: Add Tegra210 support
On 11/04/2015 10:11 AM, Thierry Reding wrote: From: Thierry Reding Extend the binding to cover the set of feature found in Tegra210. diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt +PCIe pad: +- + +Required properties: +- clocks: Must contain an entry for each entry in clock-names. +- clock-names: Must contain the following entries: + - "pll": phandle and specifier referring to the PLLE +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must contain the following entries: + - "phy": reset for the PCIe UPHY block I don't recall any clocks or resets properties in the pads for Tegra124. Do we really not need any? +SATA pad: +- + +Required properties: +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must contain the following entries: + - "phy": reset for the SATA UPHY block + PHY nodes: Nit: 2 blank lines there. +For Tegra210, the list of valid PHY nodes is given below: +- utmi: utmi-0, utmi-1, utmi-2, utmi-3 + - functions: "snps", "xusb", "uart" +- hsic: hsic-0, hsic-1 + - functions: "snps", "xusb" +- pcie: pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6 + - functions: "pcie-x1", "usb3-ss", "pcie-x4" +- sata: sata-0 + - functions: "usb3-ss", "sata" usb2-bias also needs to be present. + + Port nodes: === Nit: 2 blank lines there. +For Tegra210, the XUSB pad controller exposes the following ports: +- 4x UTMI: utmi-0, utmi-1, utmi-2, utmi-3 +- 2x HSIC: hsic-0, hsic-1 +- 4x super-speed USB: usb3-0, usb3-1, usb3-2, usb3-3 + Examples: = Nit: 2 blank lines there. -- 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] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
On 11/04/2015 10:11 AM, Thierry Reding wrote: From: Thierry Reding The NVIDIA Tegra XUSB pad controller provides a set of pads, each with a set of lanes that are used for PCIe, SATA and USB. .../bindings/phy/nvidia,tegra-xusb-padctl.txt | 359 + For Tegra bindings, we usually use the full compatible value as the filename, so I'd expect the chip number in the filename too. I'd expect to see a patch in this series that edits the existing Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt and mentions that the binding is deprecated. diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra-xusb-padctl.txt +Device tree binding for NVIDIA Tegra XUSB pad controller + + +The Tegra XUSB pad controller manages a set of pads, each of which controls +one or more lanes. The term "pad" usually refers to a single pad/pin/ball/signal on the chip. As such, saying "pad" here for something that's more than one pin is a bit confusing, even if that is what our HW documentation calls it. Each lane can in turn be assigned to one out of a set of +different outputs. That doesn't sound correct. That phrasing implies that the mux is between the HW-blocks-known-as-pads and the "outputs", whereas the mux is actually between the IO controllers and the HW-blocks-known-as-pads > A pad contains logic common for all its lanes. Each lane +can additionally be separately configured and powered up. I'd suggest rephrasing that all as: The Tegra XUSB pad controller manages a set of IO lanes (differential signals) which connect directly to pins/pads on the SoC package. Each lane is controlled by a HW block referred to as a "pad" in the Tegra HW documentation. Each such "pad" may control either one or multiple lanes, and contains any logic common to all its lanes. Each lane can be separately configured and powered up. +Some of the lanes are high-speed lanes, which can be used for PCIe, SATA or +super-speed USB. Other lanes are for various types of low-speed, full-speed +or high-speed USB (such as UTMI, ULPI and HSIC). Perhaps add the following after that? The XUSB pad controller contains a software-configurable mux that sits between the IO controller ports (e.g. PCIe) and the lanes. +Required properties: + +- compatible: Must be: + - "nvidia,tegra124-xusb-padctl": for Tegra124 and Tegra132 For Tegra132, we need both a "tegra124" and a "tegra132 value". I would suggest listing the valid complete property values for each SoC for simplicity and preciseness, as I did in the XUSB controller binding proposal I link to later: - compatible: Valid options are: - Tegra124: "nvidia,tegra124-xusb-padctl". - Tegra132: "nvidia,tegra132-xusb-padctl", \ "nvidia,tegra124-xusb-padctl". This also makes it very easy to add entries for future SoCs without editing the diff touching any existing lines of text. +- reg: Physical base address and length of the controller's registers. +- resets: Must contain an entry for each entry in reset-names. +- reset-names: Must include the following entries: + - "padctl" Are there no clocks or power domains that affect XUSB padctl? I suppose we can start off without any, and add them later if we need. +- mboxes: Must contain an entry for each entry in mbox-names. +- mbox-names: Must include the following entries: + - "xusb" I thought we'd decided not to use any mbox binding or drivers in XUSB now? See for example my proposed XUSB controller binding at: http://www.spinics.net/lists/linux-tegra/msg23922.html [PATCH V9] dt: add NVIDIA Tegra XUSB controller binding The idea is that the mailbox should be entirely internal to the XUSB controller driver, and if the receipt of a mailbox message requires any change in the XUSB pad controller programming, the XUSB controller driver should simply call the XUSB pad controller driver to perform that operation. +Pad nodes: +== +For Tegra124 and Tegra132, the following pads exist: utmi, ulpi, hsic, pcie +and sata. No extra resources are required for operation of these pads. Judging by the diagram in the TRM (e.g. figure 41 in the Tegra124 TRM, figure 36 in the Tegra210 TRM), there is not a single "utmi" pad, but rather a separate pad per USB2 lane. However, the other types of pads are indeed multi-lane. The TRM also refers to "USB2" pads rather than "UTMI" pads. I don't see a ULPI pad in the diagram either. Assuming the diagram in the TRM is consistent with the register layout, I think we should have the following set of pad nodes: utmi-0 utmi-1 utmi-2 hsic pcie sata +Required properties: + +For Tegra124 and Tegra132, the list of valid PHY nodes is given below: +- utmi: utmi-0, utmi-1, utmi-2 + - functions: "snps", "xusb", "uart"
Re: [PATCH v3 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.
On Thu, Oct 22, 2015 at 08:02:39PM +0800, Dawei Chien wrote:
> Add thermal zone node to mt8173.dtsi.
>
> Signed-off-by: Dawei Chien
> ---
> This patch is base on
> https://patchwork.kernel.org/patch/7249821/
> https://patchwork.kernel.org/patch/7249861/
> https://patchwork.kernel.org/patch/7249891/
> ---
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 90
> ++
This patch adds also the static / dynamic power models too. Can you
please split this patch in two: one for the thermal zones, one for the
models.
> 1 file changed, 90 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 3b18f37..eaf12bf 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include "mt8173-pinfunc.h"
>
> / {
> @@ -54,6 +55,18 @@
> reg = <0x000>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SLEEP_0>;
> + static-power-points = <
> + 859000 43
> + 908000 52
> + 983000 86
> + 1009000 123
> + 1028000 138
> + 1083000 172
> + 1110900 180
> + 1125000 192
> + >;
> + dynamic-power-coefficient = <263>;
> + #cooling-cells = <2>;
> };
>
> cpu1: cpu@1 {
> @@ -62,6 +75,17 @@
> reg = <0x001>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SLEEP_0>;
> + static-power-points = <
> + 859000 43
> + 908000 52
> + 983000 86
> + 1009000 123
> + 1028000 138
> + 1083000 172
> + 1110900 180
> + 1125000 192
> + >;
> + dynamic-power-coefficient = <263>;
> };
>
> cpu2: cpu@100 {
> @@ -70,6 +94,18 @@
> reg = <0x100>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SLEEP_0>;
> + static-power-points = <
> + 828000 72
> + 867000 90
> + 927000 156
> + 968000 181
> + 1007000 298
> + 1049000 435
> + 1089900 533
> + 1125000 533
> + >;
> + dynamic-power-coefficient = <530>;
> + #cooling-cells = <2>;
> };
>
> cpu3: cpu@101 {
> @@ -78,6 +114,17 @@
> reg = <0x101>;
> enable-method = "psci";
> cpu-idle-states = <&CPU_SLEEP_0>;
> + static-power-points = <
> + 828000 72
> + 867000 90
> + 927000 156
> + 968000 181
> + 1007000 298
> + 1049000 435
> + 1089900 533
> + 1125000 533
> + >;
> + dynamic-power-coefficient = <530>;
> };
>
> idle-states {
> @@ -116,6 +163,49 @@
> clock-output-names = "clk32k";
> };
>
> + thermal-zones {
> + cpu_thermal: cpu_thermal {
> + polling-delay-passive = <1000>; /* milliseconds */
> + polling-delay = <1000>; /* milliseconds */
> +
> + thermal-sensors = <&thermal MT8173_THERMAL_ZONE_CA57>;
> + sustainable-power = <1500>;
> +
> + trips {
> + threshold: trip-point@0 {
> + temperature = <68000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + target: trip-point@1 {
> + temperature = <85000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_crit: cpu_crit@0 {
> + temperature = <115000>;
> +
Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor
On 02/11/15 20:37, Andrew F. Davis wrote:
> On 11/01/2015 02:52 PM, Jonathan Cameron wrote:
>> On 31/10/15 16:31, Andrew F. Davis wrote:
>>> Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
>>> This device detects reflected LED light fluctuations and presents an ADC
>>> value to the user space for further signal processing.
>>>
>>> Data sheet located here:
>>> http://www.ti.com/product/AFE4404/datasheet
>>>
>>> Signed-off-by: Andrew F. Davis
>> Hi Andrew,
>>
>> Good to see this resurface. It's a fascinating little device.
>>
>> Anyhow, most of the interesting bit in here is unsuprisingly concerned
>> with the interface. I know we went round a few loops of this before but
>> it still feels like we haven't worked out to handle it well. I would like
>> as much input as we can get on this as inevitablly it will have
>> repercussions outside this driver.
>>
>> Your approach of hammering out descriptive sysfs attributes is a good
>> starting point but we need to work towards a formal description that
>> can be generalised. Whilst there are not many similar devices out there
>> to this one, I suspect there are a few and more may well show up in
>> future.
>>
>
> Yeah, I'm working on brining up drivers for them now :)
cool
>
>> The escence of my rather roundabout response inline is that I'm suggesting
>> adding a new channel type to represent light transmission, taking the
>> analogous
>> case of proximity devices in which we are looking at light reflection.
>> I've also taken the justification we use for illuminance vs intensity
>> readings
>> for two sensor ALS sensors as a precident for having compound channels of a
>> different
>> type to the 'raw' data that feeds them. Hence I propose something along
>> the lines of:
>>
>> in_intensityX_raw (raw channel value with the led on)
>> in_intensityX_ambient_raw (raw channel value with the led off)
>>
>
> I'm not sure, I know it may be too late for a lot of drivers but putting the
> 'X'
> against the 'intensity' works for devices like ADCs/DACs with a simple list
> of numeric channels, but for any other device with named channels this will
> become very inconsistent, especially when adding modified channels and
> differential channels.
Sadly its ABI now so we can't realistically change it. We can extend, we can't
replace (we we can over the course of a lot of years but that's a nightmare).
>
> For example:
>
> in_intensity5_name_ambient-2_mean_raw
The oddity here is that in your case the device in interacting with a stimulus
output. Normally the index reflects an actual sensor. We are kind of
bludgeoning
it in. The only equivalently nasty case I know of is touch screens where
different
resistances are being connected - from a generic point of view those are a
nightmare
as well (as every implementation does it differently).
>
> This is the differential of name and an unnamed channel '2', also something
> is an average, is it channel '2', is it the whole differential channel? Is
> 5 this channels id or part of the first differential channel name? Who knows!
>
> The way I would do it is with this more universal format:
>
> [direction]_[type]_[name|number]_[info]
Hind sight is a great thing in that the extra _ would have made parsing
marginally
easier.
>
>
> And then we just drop trying to deal with modifiers and differential stuff
> internally, just let the driver give the channel a name with those. We then
> wouldn't need to deal with channels numbers ether, just names.
See my reply to the cover letter thread. You can't pass a name in an event
to userspace and we'd end up string matching all over the place or you end
up not encoding the information currently in the modifier at all.
Perhaps you are right in that it would still have been neater but such is hind
sight!
The one I wonder about occasionally is similar to what you suggest, but don't
ever having anything other than number (and I'd keep the differential channels.
Then have an extra sysfs attribute that provides the modifier string.
Then I'm not sure it gains us much.
Also note that in the classic ADC case (and there are a whole load more
of those than weird light sensors ;) there are only indexes and differential
channels
so it all becomes rather cleaner.
in_voltage0-1_raw
It's also worth noting that whilst we do allow freeform extend_name elements
they are very rarely accepted in drivers as the moment you do that you have
something that standard userspace code won't know what to do with.
>
> struct iio_chan_spec {
> enum iio_chan_typetype;
const char*name;
> unsigned longaddress;
> intscan_index;
> struct {
> charsign;
> u8realbits;
> u8storagebits;
> u8shift;
> u8repeat;
> enum iio_endian endianness;
> } scan_type;
> const struct iio_event_spec *event_spec;
> unsigned intnum_event_specs;
> const struct i
Re: [PATCH v3 1/2] thermal: mediatek: Add cpu power cooling model.
On Thu, Oct 22, 2015 at 08:02:38PM +0800, Dawei Chien wrote:
> This power model is base on Intelligent Power Allocation (IPA)
> technical, requires that the operating-points of the CPUs are
> registered using the kernel's opp library and the
> `cpufreq_frequency_table` is assigned to the `struct device`
> of the cpu MT8173.
>
> Signed-off-by: Dawei.Chien
> ---
> This patch is base on
> https://patchwork.kernel.org/patch/7034601/
> ---
> drivers/cpufreq/mt8173-cpufreq.c | 152
> --
Given that you are proposing this on top a DT binding, why reading a
table of static power model applicable only to mt8173 cpufreq driver?
I have not seen anything specific (formula etc) that prevents this code
to be generalized to other CPUs.
Can you please help me to understand?
BR,
> 1 file changed, 144 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/cpufreq/mt8173-cpufreq.c
> b/drivers/cpufreq/mt8173-cpufreq.c
> index 49caed2..23c19c5 100644
> --- a/drivers/cpufreq/mt8173-cpufreq.c
> +++ b/drivers/cpufreq/mt8173-cpufreq.c
> @@ -29,6 +29,16 @@
> #define MAX_VOLT_LIMIT (115)
> #define VOLT_TOL (1)
>
> +struct mtk_cpu_static_power {
> + unsigned long voltage;
> + unsigned int power;
> +};
> +
> +static struct mtk_cpu_static_power *mtk_ca53_static_power_table;
> +static struct mtk_cpu_static_power *mtk_ca57_static_power_table;
> +static int mtk_ca53_static_table_length;
> +static int mtk_ca57_static_table_length;
> +
> /*
> * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU
> DVFS
> * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in
> @@ -51,6 +61,110 @@ struct mtk_cpu_dvfs_info {
> bool need_voltage_tracking;
> };
>
> +unsigned int mtk_cpufreq_lookup_power(const struct mtk_cpu_static_power
> *table,
> + unsigned int count, unsigned long voltage)
> +{
> + int i;
> +
> + for (i = 0; i < count; i++) {
> + if (voltage <= table[i].voltage)
> + return table[i].power;
> + }
> +
> + return table[count - 1].power;
> +}
> +
> +int mtk_cpufreq_get_static(cpumask_t *cpumask, int interval,
> + unsigned long voltage, u32 *power)
> +{
> + int nr_cpus = cpumask_weight(cpumask);
> +
> + *power = 0;
> +
> + if (nr_cpus) {
> + if (cpumask_test_cpu(0, cpumask))
> + *power += mtk_cpufreq_lookup_power(
> + mtk_ca53_static_power_table,
> + mtk_ca53_static_table_length,
> + voltage);
> +
> + if (cpumask_test_cpu(2, cpumask))
> + *power += mtk_cpufreq_lookup_power(
> + mtk_ca57_static_power_table,
> + mtk_ca57_static_table_length,
> + voltage);
> + }
> +
> + return 0;
> +}
> +
> +unsigned int mtk_get_power_table_info(struct cpufreq_policy *policy,
> + struct device_node *np, const char *node_name)
> +{
> + int mtk_static_table_length;
> + const struct property *prop;
> + struct mtk_cpu_dvfs_info *info = policy->driver_data;
> + struct device *cpu_dev = info->cpu_dev;
> + const __be32 *val;
> + int nr, i;
> +
> + prop = of_find_property(np, node_name, NULL);
> +
> + if (!prop) {
> + pr_err("failed to get static-power-points\n");
> + return -ENODEV;
> + }
> +
> + if (!prop->value) {
> + pr_err("failed to get static power array data\n");
> + return -EINVAL;
> + }
> +
> + nr = prop->length / sizeof(u32);
> +
> + if (nr % 2) {
> + pr_err("Invalid OPP list\n");
> + return -EINVAL;
> + }
> +
> + mtk_static_table_length = nr / 2;
> +
> + if (cpumask_test_cpu(0, policy->related_cpus)) {
> + mtk_ca53_static_table_length = mtk_static_table_length;
> + mtk_ca53_static_power_table = devm_kcalloc(cpu_dev,
> + mtk_static_table_length,
> + sizeof(*mtk_ca53_static_power_table),
> + GFP_KERNEL);
> +
> + val = prop->value;
> + for (i = 0; i < mtk_static_table_length; ++i) {
> + unsigned long voltage = be32_to_cpup(val++);
> + unsigned int power = be32_to_cpup(val++);
> +
> + mtk_ca53_static_power_table[i].voltage = voltage;
> + mtk_ca53_static_power_table[i].power = power;
> + pr_info("volt:%ld uv, power:%d mW\n", voltage, power);
> + }
> + } else {
> +mtk_ca57_static_table_length = mtk_static_table_length;
> + mtk_ca57_static_power_table = devm_kcalloc(cpu_dev,
> + mtk_static
Re: [PATCH v3 0/2] thermal: mediatek: Add cpu power cooling model
On Mon, Nov 02, 2015 at 03:53:33PM +, Punit Agrawal wrote: > Viresh Kumar writes: > > > On 22-10-15, 20:02, Dawei Chien wrote: > >> Use Intelligent Power Allocation (IPA) technical to add static/dynamic > >> power model for binding CPU thermal zone. > >> The power allocator governor allocates power budget to control CPU > >> temperature. > >> > >> Power Allocator governor is able to keep SOC temperature within a > >> defined temperature range to avoid SOC overheat and keep it's > >> performance. mt8173-cpufreq.c need to register its' own power model > >> with power allocator thermal governor, so that power allocator > >> governor can allocates suitable power budget to control CPU > >> temperature. > >> > >> PATCH1 is base on > >> https://patchwork.kernel.org/patch/7034601/ > >> > >> PATCH2 is base on Sascha's thermal driver V9 > >> https://patchwork.kernel.org/patch/7249821/ > >> https://patchwork.kernel.org/patch/7249861/ > >> https://patchwork.kernel.org/patch/7249891/ > >> > >> Change since V1: > >> include mt8171.h and sort header file for mt8173.dtsi > >> > >> Change since V2: > >> Move dynamic/static power model in device tree > >> > >> Dawei.Chien (2): > >> thermal: mediatek: Add cpu power cooling model. > >> arm64: dts: mt8173: Add thermal zone node for mt8173. > > > > Sorry for being extremely late in reviewing this stuff. You are > > already on v3 and I haven't reviewed it once. Mostly due to bad timing > > of my holidays and other work pressure. > > > > Now, there are few things that I feel are not properly addressed here, > > and I may be wrong: > > - Where are the bindings for static-power-points and > > dynamic-power-coefficient. Sorry I failed to see them in this or > > other series you mentioned. > > For dynamic power, I had posted some patches[0][1][2] introducing the > binding as well as updating cooling device registration via cpufreq > driver. Now that the SCPI hwmon driver is merged, I should re-send the > remaining patches. > > [0] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01020.html Are you sure this binding is applicable only to ARM cpus? > [1] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01022.html > [3] http://lkml.iu.edu/hypermail/linux/kernel/1508.0/01031.html > > > - Even then, why should we be adding another table into DT for > > voltage/power ? And not reuse and extend the opp-v2 stuff which is > > already mainlined now. > > - There are few issues with the code as well, but I want to see where > > the bindings should go first. And then only discuss the code > > further. > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" 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 0/2] iio: Heart Rate Monitors
On 02/11/15 16:31, Andrew F. Davis wrote: > On 11/01/2015 12:35 PM, Jonathan Cameron wrote: >> On 31/10/15 16:31, Andrew F. Davis wrote: >>> Hello all, >>> >>> This series adds the TI AFE4404 "Ultra-small, Integrated AFE for >>> Wearable, Optical Heart Rate Monitoring and Bio-Sensing". >>> >>> This work is based on previous work by Dan Murphy [0] who is working >>> on other tasks at the moment, so I will be helping to continue >>> upstreaming this driver. This is more of a re-write than a continuation >>> and there are many changes so I am submitting this as a v1. >>> >>> This device is very similar to the AFE4403 and I was originally planning >>> on pushing the two drivers together with common core functions in a >>> third file. The AFE4403 driver is still being tested so I merged common >>> code back into this driver, this is why this driver may seem a bit >>> unnecessarily modular. I will probably split this stuff back out when >>> I push the AFE4403. >>> >>> I also had some issues with sysfs naming for the channels; this device >>> has three input channels from three LED stages and two ambient >>> channels based on the LED stages. This might have been be a good place >>> for using IIO modifiers[1], but we also have two differential channels >>> based on the ambient channels, and channels cannot have both modifiers >>> and be differential (the modifier is stored in the differential channel's >>> ID field?). >> True enough. Didn't expect to run into this particular problem, but I guess >> someone will always make hardware breaking any assumptions we make from the >> software side of things. > > Seems that way, it probably would work to have modified be more that a single > bit flag, maybe call it modifier and just store the modifier in there. Doesn't > look like it would be that hard right now to fix. As I stated below the issue is then to figure out how to get it into the event codes without breaking backwards compatibility. It could probably be done but would involve something hideous like a bit for this event is on a channel that is both differential and modified. Then we need to potentially sneak into the code 2 modifiers, 2 indexes and a bit saying to use them all. This is rapidly getting to some very long naming to avoid simply saying what the channel is in reality which is a measure of light transmission. I'm kind of thinking that information is more useful to userspace than ending up with something along the lines of in_intensity0_lit-intensity0_ambient_raw it's worth noting for the discussion below that if you didn't have modifiers you'd need to index those two channels separately as the event codes that might be generated can't have strings burried in them. So you'd have the even more cyptic. in_intensity0_lit-in_intensity1_ambient_raw (or if you dropped the extra string from these attributes simply in_intensity0-intensity1_raw vs in_intensitytransmitted0_raw > > I'm not really sure I understand the need for modifiers at all really, seems > most are used by a single driver to get around just naming the channel. In a sense they do serve that purpose, but their primary purpose is to provide a short hand lookup for common elements that 'identify' a channel. These get used in a couple of places in particular: 1) Event codes - now we could have insisted that any process using events holds sufficient state to allow it to identify the channel purely based on type and index but instead decided that the vast majority of cases where there is a reason to map to a unique identifier are straight forward (e.g. an axis for multi axis sensors). If anyone needs to still do a more detailed lookup to identify the source of an event they still can (effectively nothing is lost) 2) In kernel mappings - consumers of IIO channels could in theory do a name look up if it was all string based, but then all we've done is pushed the problem on one step and have to maintain copies of the magic string mapping that says 'This is an x axis'. Hwmon basically only ever uses string based naming (as it just has sysfs attributes instantiated by every driver from scratch). It works for that case, but has caused a lot of grief when people try for example to base a thermal driver on top of hwmon. Obviously this doesn't precisely map given the nature of hwmon channels is typically simpler and they are almost always accompanied by a userspace mapping in lm-sensors that identifies what they are wired to on a particular board. Input goes right the otherway and more or less provides no naming based stuff at all instead mapping to a set of big enums to identify things. So we could have done it all with strings but at the time it seems more straight forward to map onto a known subset using a simple look up. Perhaps we should have done this differently, but such is life! One thing it has really gained me from a maintainer point of view is avoiding small missnaming issues by effectively enforcing the ABI. Any bre
Re: IIO device indexing issue
On 04/11/15 11:38, Lars-Peter Clausen wrote:
On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
Hi,
When we were using kernel 3.2 and with that board files we just got IIO
devices with static order so that we knew exactly what iio:device0 is.
Now with device tree that order is not so static anymore especially when
using device overlays (have not yet tried that thou). If there would be
deferred probe for the device then if we have multiple iio:device's then
those could in theory be in any order.
In example libiio uses iio device index to open the IIO device. So the
problem is to know what iio:device is what.
If we look files under /sys/bus/iio/iio:deviceX. They do not reveal what
device this is (especially if there are multiple device of same type). There
does not seem to be a way to give custom name for the iio device from device
tree that could have been used as a cue.
Device tree aliases kinda sounded a good idea to try. Eg. define adc0 alias
and then link it to actual device node in tree.
Aliases could be found under /proc/device-tree/aliases. Looking at it shows
what device tree node it is. However there does not seem to be actual link
from any /proc/device-tree entries to kernel drivers exposed under sysfs.
And even the path components in device tree are not in same format as in
sysfs. So there is no 1:1 mapping possible here.
IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
devices under /sys/devices and from there is physical path to the device and
under that the IIO device with the same name as is under /sys/bus/iio.
So in theory we could make a mapping configuration file that specifies
logical name for iio device and then physical parent path for the device and
then find under it iio:device* files to determine what is the iio device
index for this physical device. Then open IIO device with that index in
example with libiio. Sounds a bit complex?
So did we miss something on how this should be defined/accessed or is there
a slight issue here on how to identify iio devices?
Don't know how device tree overlays affect this if we first load device tree
overlay with some configuration and then unload it and load another one with
different configuration.
Hi,
Yes, excellent analysis. This is a real issue. As you said there is no
guarantee that the IIO device numbers are stable, they are assigned in the
order the devices are registered. If the device are registered in a
different order for whatever reason the numbers will change. You can use
readlink on the IIO device in /sys/bus/iio/devices to get its position in
the global device topology and be able to tell what the parent device is,
but this path might not be completely stable either though. E.g. if your
device is on a I2C bus and the number of the I2C bus is dynamically assigned
it might change when the probe order changes.
Alias seem to be one way to solve this issue. The big question remains is
how to communicate the alias to userspace. For other device classes the
alias index is used as the device index e.g. a device with alias i2c0 ends
up being the i2c adapter with index 0. But with IIO where we support a wide
range of different devices that does not really work. E.g. what to do if you
have adc0 and dac0 as aliases for different devices. So you'd need a
different way to expose the alias.
Some bindings also use the "label" property to assign a unique name to node.
But again the same issue how to expose that information to applications.
To continue from this "label" property idea I was wondering if we would
add it as new optional(?) file node for IIO devices.
One could then specify it like:
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
...
am335x_adc: adc {
compatible = "ti,am3359-adc";
...
label = "Port A";
};
};
And this would generate file /sys/bus/iio/iio:deviceX/label with
contents of "Port A".
Then during the application startup it would just need to scan all
devices under /sys/bus/iio and determine what labelled device it wants
to use.
It would be up to device's developer to determine what labels to use in
their designs. This would not break ABI and would be just an extension
for it.
One could also auto-assign label "am335x_adc" in this case too. But if
you include existing arch device tree then changing label in top level
is kinda a bit annoying as you would then need to duplicate all
properties with another label and disable arch device tree's settings.
Could cause also conflict if there are references elsewhere to existing
arch nodes.
Having following in device's device tree file would allow one to
override label or just only specify that.
#include "am33xx.dtsi"
&tscadc {
status = "okay";
adc {
ti,adc-channels = <4 5 6 7>;
label = "Port A";
};
};
I think this "label" model would be simple to understand.
Whether this needs to be implemented as per device driver feature or
could be implemented as generic I
Re: [RFC v5 02/12] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
Hi Philipp, A bunch of review comments inline. On Wed, Nov 4, 2015 at 7:44 PM, Philipp Zabel wrote: > From: CK Hu > > This patch adds an initial DRM driver for the Mediatek MT8173 DISP > subsystem. It currently supports two fixed output streams from the > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively. > > Signed-off-by: CK Hu > Signed-off-by: YT Shen > Signed-off-by: Philipp Zabel > --- > Changes since v4: > - Add mtk_crtc_state to keep pending state > - Move drm pending vblank event into mtk_crtc_state > - Make mtk_drm_crtc private > - Use drm_dev_alloc and drm_dev_register directly instead of >drm_platform_init > - Drop unnecessary locking in mtk_drm_gem_dump_map_offset > - Remove currently unused mtk_drm_gem_mmap_buf > - Stop referencing plane framebuffers manually > - Set RDMA FIFO output threshold depending on frame width/height/rate > --- > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile| 1 + > drivers/gpu/drm/mediatek/Kconfig| 16 + > drivers/gpu/drm/mediatek/Makefile | 10 + > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 590 > > drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 56 +++ > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 218 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 39 ++ > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 424 > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 86 > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 572 +++ > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 61 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.c | 151 +++ > drivers/gpu/drm/mediatek/mtk_drm_fb.h | 29 ++ > drivers/gpu/drm/mediatek/mtk_drm_gem.c | 189 + > drivers/gpu/drm/mediatek/mtk_drm_gem.h | 56 +++ > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 167 > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 41 ++ > 18 files changed, 2708 insertions(+) > create mode 100644 drivers/gpu/drm/mediatek/Kconfig > create mode 100644 drivers/gpu/drm/mediatek/Makefile > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_crtc.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_drv.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_fb.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.c > create mode 100644 drivers/gpu/drm/mediatek/mtk_drm_plane.h > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 1a0a8df..9e9987b 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -264,3 +264,5 @@ source "drivers/gpu/drm/sti/Kconfig" > source "drivers/gpu/drm/amd/amdkfd/Kconfig" > > source "drivers/gpu/drm/imx/Kconfig" > + > +source "drivers/gpu/drm/mediatek/Kconfig" > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile > index 45e7719..af6b592 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -67,6 +67,7 @@ obj-$(CONFIG_DRM_MSM) += msm/ > obj-$(CONFIG_DRM_TEGRA) += tegra/ > obj-$(CONFIG_DRM_STI) += sti/ > obj-$(CONFIG_DRM_IMX) += imx/ > +obj-$(CONFIG_DRM_MEDIATEK) += mediatek/ > obj-y += i2c/ > obj-y += panel/ > obj-y += bridge/ > diff --git a/drivers/gpu/drm/mediatek/Kconfig > b/drivers/gpu/drm/mediatek/Kconfig > new file mode 100644 > index 000..5343cf1 > --- /dev/null > +++ b/drivers/gpu/drm/mediatek/Kconfig > @@ -0,0 +1,16 @@ > +config DRM_MEDIATEK > + tristate "DRM Support for Mediatek SoCs" > + depends on DRM > + depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST) > + select MTK_SMI > + select DRM_PANEL > + select DRM_MIPI_DSI > + select DRM_PANEL_SIMPLE > + select DRM_KMS_HELPER > + select IOMMU_DMA > + help > + Choose this option if you have a Mediatek SoCs. > + The module will be called mediatek-drm > + This driver provides kernel mode setting and > + buffer management to userspace. > + > diff --git a/drivers/gpu/drm/mediatek/Makefile > b/drivers/gpu/drm/mediatek/Makefile > new file mode 100644 > index 000..ba6d3fc > --- /dev/null > +++ b/drivers/gpu/drm/mediatek/Makefile > @@ -0,0 +1,10 @@ > +mediatek-drm-y := mtk_drm_drv.o \ > + mtk_drm_crtc.o \ > + mtk_drm_ddp.o \ > + mtk_drm_ddp_comp.o \ > + m
Re: [PATCH v7 44/50] drivers/of: Split unflatten_dt_node()
On Wed, Nov 4, 2015 at 7:12 AM, Gavin Shan wrote:
> The function unflatten_dt_node() is called recursively to unflatten
> device nodes and properties in the FDT blob. It looks complicated
> and hard to be understood.
>
> This splits the function into 3 functions: populate_properties(),
> populate_node() and unflatten_dt_node(). populate_properties(),
> which is called by populate_node(), creates properties for the
> indicated device node. The later one creates the device nodes
> from FDT blob. populate_node() gets the offset in FDT blob for
> next device nodes and then calls populate_node(). No logical
> changes introduced.
>
> Signed-off-by: Gavin Shan
> ---
> drivers/of/fdt.c | 275
> ---
> 1 file changed, 160 insertions(+), 115 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 6e82bc42..173b036 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -160,39 +160,127 @@ static void *unflatten_dt_alloc(void **mem, unsigned
> long size,
> return res;
> }
>
> -/**
> - * unflatten_dt_node - Alloc and populate a device_node from the flat tree
> - * @blob: The parent device tree blob
> - * @mem: Memory chunk to use for allocating device nodes and properties
> - * @poffset: pointer to node in flat tree
> - * @dad: Parent struct device_node
> - * @nodepp: The device_node tree created by the call
> - * @fpsize: Size of the node path up at the current depth.
> - * @dryrun: If true, do not allocate device nodes but still calculate needed
> - * memory size
> - */
> -static void * unflatten_dt_node(const void *blob,
> - void *mem,
> - int *poffset,
> - struct device_node *dad,
> - struct device_node **nodepp,
> - unsigned long fpsize,
> +static void populate_properties(const void *blob,
> + int offset,
> + void **mem,
> + struct device_node *np,
> + const char *nodename,
> bool dryrun)
I'd like to make dryrun implicit. It is basically a function of NULL
or near NULL pointers.
> {
> - const __be32 *p;
> + struct property *pp, **pprev = NULL;
> + int cur;
> + bool has_name = false;
> +
> + pprev = &np->properties;
> + cur = fdt_first_property_offset(blob, offset);
> + while (cur >= 0) {
This could be better written as a for loop to avoid the gotos:
for (cur = fdt_first_property_offset(blob, offset); cur >=0; cur =
fdt_next_property_offset(blob, cur))
> + const __be32 *val;
> + const char *pname;
> + u32 sz;
> +
> + val = fdt_getprop_by_offset(blob, cur, &pname, &sz);
> + if (!val) {
> + pr_warn("%s: Cannot locate property at 0x%x\n",
> + __func__, cur);
> + goto next;
> + }
> +
> + if (!pname) {
> + pr_warn("%s: Cannot find property name at 0x%x\n",
> + __func__, cur);
> + goto next;
> + } else if (!strcmp(pname, "name")) {
> + has_name = true;
> + }
> +
> + pp = unflatten_dt_alloc(mem, sizeof(struct property),
> + __alignof__(struct property));
> + if (!dryrun) {
Then:
if (dryrun)
continue;
to save some indentation and vertical code.
> + /* We accept flattened tree phandles either in
> +* ePAPR-style "phandle" properties, or the
> +* legacy "linux,phandle" properties. If both
> +* appear and have different values, things
> +* will get weird. Don't do that.
> +*/
> + if (!strcmp(pname, "phandle") ||
> + !strcmp(pname, "linux,phandle")) {
> + if (!np->phandle)
> + np->phandle = be32_to_cpup(val);
> + }
> +
> + /* And we process the "ibm,phandle" property
> +* used in pSeries dynamic device tree
> +* stuff
> +*/
> + if (!strcmp(pname, "ibm,phandle"))
> + np->phandle = be32_to_cpup(val);
> +
> + pp->name = (char *)pname;
> + pp->length = sz;
> + pp->value = (__be32 *)val;
> + *pprev = pp;
> + pprev = &pp->next;
> + }
> +next:
> + cur = fdt_next_property_offs
Re: [PATCH V2 3/3] dma: add Qualcomm Technologies HIDMA channel driver
On Wed, Nov 4, 2015 at 2:07 AM, Sinan Kaya wrote:
> On 11/3/2015 5:10 AM, Andy Shevchenko wrote:
>> On Mon, Nov 2, 2015 at 8:07 AM, Sinan Kaya wrote:
>>> +static void hidma_issue_pending(struct dma_chan *dmach)
>>> +{
>>
>>
>> Wrong. It should actually start the transfer. tx_submit() just puts
>> the descriptor to a queue.
>>
> Depends on the design.
>
> I started from the Freescale driver (mpc512x_dma.c). It follows the same
> model.
>
> I'll just drop the same comment into this code too.
>
>
> /*
> * We are posting descriptors to the hardware as soon as
> * they are ready, so this function does nothing.
> */
So, the Freescale driver was written before change went effective. I
guess in 2011 DMA Engine drivers should use issue pending.
Please, refactor since this behaviour is expected.
>>> +/*
>>> + * Submit descriptor to hardware.
>>> + * Lock the PM for each descriptor we are sending.
>>> + */
>>> +static dma_cookie_t hidma_tx_submit(struct dma_async_tx_descriptor *txd)
>>> +{
>>> + struct hidma_chan *mchan = to_hidma_chan(txd->chan);
>>> + struct hidma_dev *dmadev = mchan->dmadev;
>>> + struct hidma_desc *mdesc;
>>> + unsigned long irqflags;
>>> + dma_cookie_t cookie;
>>> +
>>> + if (!hidma_ll_isenabled(dmadev->lldev))
>>> + return -ENODEV;
>>> +
>>> + pm_runtime_get_sync(dmadev->ddev.dev);
>>
>>
>> No point to do it here. It should be done on the function that
>> actually starts the transfer (see issue pending).
>>
> comment above
See above as well.
>>> +static int hidma_probe(struct platform_device *pdev)
>>> +{
>>> + struct hidma_dev *dmadev;
>>> + int rc = 0;
>>> + struct resource *trca_resource;
>>> + struct resource *evca_resource;
>>> + int chirq;
>>> + int current_channel_index = atomic_read(&channel_ref_count);
>>> +
>>> + /* Set DMA mask to 64 bits. */
>>> + rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
>>> + if (rc) {
>>> + dev_warn(&pdev->dev, "unable to set coherent mask to
>>> 64");
>>> + rc = dma_set_mask_and_coherent(&pdev->dev,
>>> DMA_BIT_MASK(32));
>>> + }
>>> + if (rc)
>>> + goto dmafree;
Maybe move these two lines inside previous condition?
>>> +
>>> + dmadev->lldev = hidma_ll_init(dmadev->ddev.dev,
>>> + dmadev->nr_descriptors, dmadev->dev_trca,
>>> + dmadev->dev_evca, dmadev->evridx);
>>> + if (!dmadev->lldev) {
>>> + rc = -EPROBE_DEFER;
>>> + goto dmafree;
>>> + }
>>> +
>>> + rc = devm_request_irq(&pdev->dev, chirq, hidma_chirq_handler, 0,
>>> + "qcom-hidma", &dmadev->lldev);
>>
>>
>> Better to use request_irq().
>>
>
> why? I thought we favored managed functions over standalone functions in
> simplify the exit path.
IRQ is slightly different in workflow. In most cases, unfortunately,
there is no achievement by devm_ variant.
At least I know two for now. One of them is DMA Engine slave drivers,
though I didn't notice if you are using tasklet's here.
Otherwise it's okay.
--
With Best Regards,
Andy Shevchenko
--
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 v7 08/50] powerpc/powernv: Rename PE# fields in struct pnv_phb
This renames the fields related to PE number in "struct pnv_phb"
for better reflecting of their usages as Alexey suggested. No
logical changes introduced.
Signed-off-by: Gavin Shan
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
arch/powerpc/platforms/powernv/pci-ioda.c| 56 ++--
arch/powerpc/platforms/powernv/pci.c | 2 +-
arch/powerpc/platforms/powernv/pci.h | 4 +-
4 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-powernv.c
b/arch/powerpc/platforms/powernv/eeh-powernv.c
index e1c9072..861a7d2 100644
--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
+++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
@@ -75,7 +75,7 @@ static int pnv_eeh_init(void)
* and P7IOC separately. So we should regard
* PE#0 as valid for PHB3 and P7IOC.
*/
- if (phb->ioda.reserved_pe != 0)
+ if (phb->ioda.reserved_pe_idx != 0)
eeh_add_flag(EEH_VALID_PE_ZERO);
break;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 968da91..b4932c3 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -134,7 +134,7 @@ static inline bool pnv_pci_is_mem_pref_64(unsigned long
flags)
static void pnv_ioda_reserve_pe(struct pnv_phb *phb, int pe_no)
{
- if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe)) {
+ if (!(pe_no >= 0 && pe_no < phb->ioda.total_pe_num)) {
pr_warn("%s: Invalid PE %d on PHB#%x\n",
__func__, pe_no, phb->hose->global_number);
return;
@@ -154,8 +154,8 @@ static int pnv_ioda_alloc_pe(struct pnv_phb *phb)
do {
pe = find_next_zero_bit(phb->ioda.pe_alloc,
- phb->ioda.total_pe, 0);
- if (pe >= phb->ioda.total_pe)
+ phb->ioda.total_pe_num, 0);
+ if (pe >= phb->ioda.total_pe_num)
return IODA_INVALID_PE;
} while(test_and_set_bit(pe, phb->ioda.pe_alloc));
@@ -209,13 +209,13 @@ static int pnv_ioda2_init_m64(struct pnv_phb *phb)
* expected to be 0 or last one of PE capabicity.
*/
r = &phb->hose->mem_resources[1];
- if (phb->ioda.reserved_pe == 0)
+ if (phb->ioda.reserved_pe_idx == 0)
r->start += phb->ioda.m64_segsize;
- else if (phb->ioda.reserved_pe == (phb->ioda.total_pe - 1))
+ else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
r->end -= phb->ioda.m64_segsize;
else
pr_warn(" Cannot strip M64 segment for reserved PE#%d\n",
- phb->ioda.reserved_pe);
+ phb->ioda.reserved_pe_idx);
return 0;
@@ -284,7 +284,7 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus, bool
all)
return IODA_INVALID_PE;
/* Allocate bitmap */
- size = _ALIGN_UP(phb->ioda.total_pe / 8, sizeof(unsigned long));
+ size = _ALIGN_UP(phb->ioda.total_pe_num / 8, sizeof(unsigned long));
pe_alloc = kzalloc(size, GFP_KERNEL);
if (!pe_alloc) {
pr_warn("%s: Out of memory !\n",
@@ -300,7 +300,7 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus, bool
all)
* contributed by its child buses. For the case, we needn't
* pick M64 dependent PE#.
*/
- if (bitmap_empty(pe_alloc, phb->ioda.total_pe)) {
+ if (bitmap_empty(pe_alloc, phb->ioda.total_pe_num)) {
kfree(pe_alloc);
return IODA_INVALID_PE;
}
@@ -311,8 +311,8 @@ static int pnv_ioda2_pick_m64_pe(struct pci_bus *bus, bool
all)
*/
master_pe = NULL;
i = -1;
- while ((i = find_next_bit(pe_alloc, phb->ioda.total_pe, i + 1)) <
- phb->ioda.total_pe) {
+ while ((i = find_next_bit(pe_alloc, phb->ioda.total_pe_num, i + 1)) <
+ phb->ioda.total_pe_num) {
pe = &phb->ioda.pe_array[i];
if (!master_pe) {
@@ -364,7 +364,7 @@ static void __init pnv_ioda_parse_m64_window(struct pnv_phb
*phb)
hose->mem_offset[1] = res->start - pci_addr;
phb->ioda.m64_size = resource_size(res);
- phb->ioda.m64_segsize = phb->ioda.m64_size / phb->ioda.total_pe;
+ phb->ioda.m64_segsize = phb->ioda.m64_size / phb->ioda.total_pe_num;
phb->ioda.m64_base = pci_addr;
pr_info(" MEM64 0x%016llx..0x%016llx -> 0x%016llx\n",
@@ -465,7 +465,7 @@ static int pnv_ioda_get_pe_state(struct pnv_phb *phb, int
pe_no)
s64 rc;
/* Sanity check on PE number */
- if (pe_no < 0 || pe_no >= phb->ioda.total_pe)
+ if (pe_no < 0 || pe_no >= phb->ioda.total_pe_num)
return OPAL_EEH_STOPPED_PERM_UNAVAIL;
/*
@@ -1394,9
