* Re: [PATCH] ARM: dts: keystone-k2l: fix broken Ethernet due to disabled OSR
From: Arnd Bergmann @ 2017-03-31 10:13 UTC (permalink / raw)
To: santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org
Cc: arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Sekhar Nori,
Santosh Shilimkar, Rob Herring, Mark Rutland, Russell King,
Linux ARM, devicetree-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List, Tero Kristo, Murali Karicheri
In-Reply-To: <5adb4f5d-78c4-453d-898d-60c588eb1d14-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Wed, Mar 29, 2017 at 6:13 PM, santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org
<santosh.shilimkar-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>> Signed-off-by: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
>> Acked-by: Tero Kristo <t-kristo-l0cyMroinI0@public.gmane.org>
>> [nsekhar-l0cyMroinI0@public.gmane.org: commit message updates, port to latest mainline]
>> Signed-off-by: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
>> ---
>
> Acked-by: Santosh Shilimkar <ssantosh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>
> Can you please pick this up for rcx fixes ?
Applied, thanks!
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V2 1/2] mtd: move code reading DT specified part probes to the core
From: Rafał Miłecki @ 2017-03-31 10:12 UTC (permalink / raw)
To: Boris Brezillon
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Frank Rowand,
Linus Walleij, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331115654.41592eba@bbrezillon>
On 03/31/2017 11:56 AM, Boris Brezillon wrote:
> On Fri, 31 Mar 2017 11:30:12 +0200
> Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>>
>> Handling (creating) partitions for flash devices requires using a proper
>> driver that will read partition table (out of somewhere). We can't
>> simply try all existing drivers one by one, so MTD subsystem allows
>> drivers to specify a list of applicable part probes.
>>
>> So far physmap_of was the only driver with support for linux,part-probe
>> DT property. Other ones had list or probes hardcoded which wasn't making
>> them really flexible. It prevented using common flash drivers on
>> platforms that required some specific partition table access.
>>
>> This commit moves support for mentioned DT property to the MTD core
>> file. Thanks to calling it on device parse registration (as suggested by
>> Boris) all drivers gain support for it for free.
>>
>> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>> ---
>> drivers/mtd/maps/physmap_of.c | 36 +-----------------------------------
>> drivers/mtd/mtdcore.c | 34 ++++++++++++++++++++++++++++++++++
>
> Maybe you should split the patch:
> 1/ add core infrastructure
> 2/ remove open-coded version in drivers/mtd/maps/physmap_of.c
What's the gain of that? Is this patch too complex to review properly? Will that
be useful for anyone to have it split? For me it only adds an intermediate code
duplication.
> BTW, not sure the intermediate "mtd: physmap_of: use OF helpers
> for reading strings" patch is really useful, since you move to the
> common infrastructure here.
> By following my suggestion you get rid of the dependency you have
> between this series and patch "mtd: physmap_of: use OF helpers for
> reading strings".
I learned (the very hard way) MTD people can be really nitpicking so I'm
sending as simple patches as I can. I see it as the only way for someone from
OpenWrt/LEDE project to get patch through your review.
It's like with this patch: even a simple code move can be questioned. Please
drop this patchset, I'll resend it after/if I manage to get
[PATCH] mtd: physmap_of: use OF helpers for reading strings
accepted.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] arm64: dts: rk3399: add support for firefly-rk3399 board
From: Kever Yang @ 2017-03-31 9:59 UTC (permalink / raw)
To: heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Kever Yang,
devicetree-u79uwXL29TY76Z2rM5mHXA, Jianqun Xu,
Andreas Färber, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Andy Yan, Rob Herring,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Will Deacon,
Mark Rutland, Catalin Marinas, Matthias Brugger
Firefly-rk3399 is a bord from T-Firefly, you can find detail about
it here:
http://en.t-firefly.com/en/firenow/Firefly_RK3399/
This patch add basic node for the board and make it able to bring
up.
Peripheral works:
- usb hub which connect to ehci controller;
- UART2 debug
- eMMC
- PCIe
Not work:
- USB 3.0 HOST, type-C port
- sdio, sd-card
Not test for other peripheral:
- HDMI
- Ethernet
- OPTICAL
- WiFi/BT
- MIPI CSI/DSI
- IR
- EDP/DP
Signed-off-by: Kever Yang <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3399-firefly.dts | 772 ++++++++++++++++++++++++
2 files changed, 773 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 3a86289..dd3d550 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -4,6 +4,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-orion-r68-meta.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-px5-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-firefly.dtb
always := $(dtb-y)
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
new file mode 100644
index 0000000..686977b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-firefly.dts
@@ -0,0 +1,772 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * 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 <dt-bindings/pwm/pwm.h>
+#include "rk3399.dtsi"
+
+/ {
+ model = "Rockchip RK3399 Firefly Board (Linux Opensource)";
+ compatible = "rockchip,rk3399-firefly-linux", "rockchip,rk3399";
+
+ backlight: backlight {
+ status = "okay";
+ compatible = "pwm-backlight";
+ enable-gpios = <&gpio1 13 GPIO_ACTIVE_HIGH>;
+ pwms = <&pwm0 0 25000 0>;
+ brightness-levels = <
+ 0 1 2 3 4 5 6 7
+ 8 9 10 11 12 13 14 15
+ 16 17 18 19 20 21 22 23
+ 24 25 26 27 28 29 30 31
+ 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47
+ 48 49 50 51 52 53 54 55
+ 56 57 58 59 60 61 62 63
+ 64 65 66 67 68 69 70 71
+ 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87
+ 88 89 90 91 92 93 94 95
+ 96 97 98 99 100 101 102 103
+ 104 105 106 107 108 109 110 111
+ 112 113 114 115 116 117 118 119
+ 120 121 122 123 124 125 126 127
+ 128 129 130 131 132 133 134 135
+ 136 137 138 139 140 141 142 143
+ 144 145 146 147 148 149 150 151
+ 152 153 154 155 156 157 158 159
+ 160 161 162 163 164 165 166 167
+ 168 169 170 171 172 173 174 175
+ 176 177 178 179 180 181 182 183
+ 184 185 186 187 188 189 190 191
+ 192 193 194 195 196 197 198 199
+ 200 201 202 203 204 205 206 207
+ 208 209 210 211 212 213 214 215
+ 216 217 218 219 220 221 222 223
+ 224 225 226 227 228 229 230 231
+ 232 233 234 235 236 237 238 239
+ 240 241 242 243 244 245 246 247
+ 248 249 250 251 252 253 254 255>;
+ default-brightness-level = <200>;
+ };
+
+ clkin_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "clkin_gmac";
+ #clock-cells = <0>;
+ };
+
+ rt5640-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "rockchip,rt5640-codec";
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "Mic Jack", "MICBIAS1",
+ "IN1P", "Mic Jack",
+ "Headphone Jack", "HPOL",
+ "Headphone Jack", "HPOR";
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&rt5640>;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk808 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_enable_h>;
+
+ /*
+ * On the module itself this is one of these (depending
+ * on the actual card populated):
+ * - SDIO_RESET_L_WL_REG_ON
+ * - PDN (power down when low)
+ */
+ reset-gpios = <&gpio0 10 GPIO_ACTIVE_LOW>; /* GPIO0_B2 */
+ };
+
+ vcc3v3_pcie: vcc3v3-pcie-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio1 17 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_drv>;
+ regulator-name = "vcc3v3_pcie";
+ };
+
+ vcc3v3_sys: vcc3v3-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcc5v0_host: vcc5v0-host-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio1 0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&host_vbus_drv>;
+ regulator-name = "vcc5v0_host";
+ regulator-always-on;
+ };
+
+ vcc5v0_sys: vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vcc_phy: vcc-phy-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_phy";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_log: vdd-log {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 25000 1>;
+ regulator-name = "vdd_log";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ /* for rockchip boot on */
+ rockchip,pwm_id= <2>;
+ rockchip,pwm_voltage = <1000000>;
+ };
+
+ vccadc_ref: vccadc-ref {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc1v8_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ wireless-wlan {
+ compatible = "wlan-platdata";
+ rockchip,grf = <&grf>;
+ wifi_chip_type = "ap6354";
+ sdio_vref = <1800>;
+ WIFI,host_wake_irq = <&gpio0 3 GPIO_ACTIVE_HIGH>; /* GPIO0_a3 */
+ status = "okay";
+ };
+
+ wireless-bluetooth {
+ compatible = "bluetooth-platdata";
+ //wifi-bt-power-toggle;
+ uart_rts_gpios = <&gpio2 19 GPIO_ACTIVE_LOW>; /* GPIO2_C3 */
+ pinctrl-names = "default", "rts_gpio";
+ pinctrl-0 = <&uart0_rts>;
+ pinctrl-1 = <&uart0_gpios>;
+ //BT,power_gpio = <&gpio3 19 GPIO_ACTIVE_HIGH>; /* GPIOx_xx */
+ BT,reset_gpio = <&gpio0 9 GPIO_ACTIVE_HIGH>; /* GPIO0_B1 */
+ BT,wake_gpio = <&gpio2 26 GPIO_ACTIVE_HIGH>; /* GPIO2_D2 */
+ BT,wake_host_irq = <&gpio0 4 GPIO_ACTIVE_HIGH>; /* GPIO0_A4 */
+ status = "okay";
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_l>;
+};
+
+&cpu_b0 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&cpu_b1 {
+ cpu-supply = <&vdd_cpu_b>;
+};
+
+&emmc_phy {
+ status = "okay";
+};
+
+&gmac {
+ assigned-clocks = <&cru SCLK_RMII_SRC>;
+ assigned-clock-parents = <&clkin_gmac>;
+ clock_in_out = "input";
+ phy-supply = <&vcc_phy>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ snps,reset-gpio = <&gpio3 15 GPIO_ACTIVE_LOW>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 50000>;
+ tx_delay = <0x28>;
+ rx_delay = <0x11>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <168>;
+ i2c-scl-falling-time-ns = <4>;
+ clock-frequency = <400000>;
+
+ vdd_cpu_b: syr827@40 {
+ compatible = "silergy,syr827";
+ reg = <0x40>;
+ vin-supply = <&vcc5v0_sys>;
+ regulator-compatible = "fan53555-reg";
+ regulator-name = "vdd_cpu_b";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ vsel-gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
+ fcs,suspend-voltage-selector = <0>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-state = <3>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: syr828@41 {
+ compatible = "silergy,syr828";
+ reg = <0x41>;
+ vin-supply = <&vcc5v0_sys>;
+ regulator-compatible = "fan53555-reg";
+ regulator-name = "vdd_gpu";
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <1500000>;
+ regulator-ramp-delay = <1000>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-state = <3>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int_l>;
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+ vcc10-supply = <&vcc3v3_sys>;
+ vcc11-supply = <&vcc3v3_sys>;
+ vcc12-supply = <&vcc3v3_sys>;
+ vddio-supply = <&vcc1v8_pmu>;
+
+ regulators {
+ vdd_center: DCDC_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-name = "vdd_center";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_cpu_l: DCDC_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+ regulator-name = "vdd_cpu_l";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc_ddr";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_1v8";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc1v8_dvp: LDO_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8_dvp";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v0_tp: LDO_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc3v0_tp";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc1v8_pmu: LDO_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc1v8_pmu";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc_sd: LDO_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_sd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcca3v0_codec: LDO_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcca3v0_codec";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v5: LDO_REG6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-name = "vcc_1v5";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1500000>;
+ };
+ };
+
+ vcca1v8_codec: LDO_REG7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcca1v8_codec";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v0: LDO_REG8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-name = "vcc_3v0";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3000000>;
+ };
+ };
+
+ vcc3v3_s3: SWITCH_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc3v3_s3";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_s0: SWITCH_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc3v3_s0";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <300>;
+ i2c-scl-falling-time-ns = <15>;
+
+ gsl3673: gsl3673@40 {
+ compatible = "GSL,GSL3673";
+ reg = <0x40>;
+ screen_max_x = <1536>;
+ screen_max_y = <2048>;
+ irq_gpio_number = <&gpio1 20 IRQ_TYPE_LEVEL_LOW>;
+ rst_gpio_number = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+ };
+
+ rt5640: rt5640@1c {
+ #sound-dai-cells = <0>;
+ compatible = "realtek,rt5640";
+ reg = <0x1c>;
+ clocks = <&cru SCLK_I2S_8CH_OUT>;
+ clock-names = "mclk";
+ realtek,in1-differential;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rt5640_hpcon>;
+ hp-con-gpio = <&gpio4 21 GPIO_ACTIVE_HIGH>;
+ //hp-det-gpio = <&gpio4 28 GPIO_ACTIVE_LOW>;
+ io-channels = <&saradc 4>;
+ hp-det-adc-value = <500>;
+ };
+};
+
+&i2c3 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <450>;
+ i2c-scl-falling-time-ns = <15>;
+};
+
+&i2c4 {
+ status = "okay";
+ i2c-scl-rising-time-ns = <600>;
+ i2c-scl-falling-time-ns = <20>;
+
+ fusb0: fusb30x@22 {
+ compatible = "fairchild,fusb302";
+ reg = <0x22>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&fusb0_int>;
+ int-n-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ vbus-5v-gpios = <&gpio2 0 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+
+ mpu6500@68 {
+ status = "okay";
+ compatible = "invensense,mpu6500";
+ reg = <0x68>;
+ irq-gpio = <&gpio1 22 IRQ_TYPE_EDGE_RISING>;
+ mpu-int_config = <0x10>;
+ mpu-level_shifter = <0>;
+ mpu-orientation = <0 1 0 1 0 0 0 0 1>;
+ orientation-x= <1>;
+ orientation-y= <0>;
+ orientation-z= <0>;
+ mpu-debug = <1>;
+ };
+};
+
+&i2s0 {
+ status = "okay";
+ rockchip,i2s-broken-burst-len;
+ rockchip,playback-channels = <8>;
+ rockchip,capture-channels = <8>;
+ #sound-dai-cells = <0>;
+};
+
+&i2s1 {
+ status = "okay";
+ rockchip,i2s-broken-burst-len;
+ rockchip,playback-channels = <2>;
+ rockchip,capture-channels = <2>;
+ #sound-dai-cells = <0>;
+};
+
+&i2s2 {
+ #sound-dai-cells = <0>;
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ bt656-supply = <&vcc1v8_dvp>; /* bt656_gpio2ab_ms */
+ audio-supply = <&vcca1v8_codec>; /* audio_gpio3d4a_ms */
+ sdmmc-supply = <&vcc_sd>; /* sdmmc_gpio4b_ms */
+ gpio1830-supply = <&vcc_3v0>; /* gpio1833_gpio4cd_ms */
+};
+
+&pcie_phy {
+ status = "okay";
+};
+
+&pcie0 {
+ ep-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
+ num-lanes = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie_clkreqn>;
+ status = "okay";
+};
+
+&pmu_io_domains {
+ status = "okay";
+ pmu1830-supply = <&vcc_3v0>;
+};
+
+&pinctrl {
+ buttons {
+ pwrbtn: pwrbtn {
+ rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ lcd-panel {
+ lcd_panel_reset: lcd-panel-reset {
+ rockchip,pins = <4 30 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ pcie {
+ pcie_drv: pcie-drv {
+ rockchip,pins =
+ <1 17 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ pcie_3g_drv: pcie-3g-drv {
+ rockchip,pins =
+ <0 2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ pmic {
+ vsel1_gpio: vsel1-gpio {
+ rockchip,pins =
+ <1 18 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+
+ vsel2_gpio: vsel2-gpio {
+ rockchip,pins =
+ <1 14 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ sdio-pwrseq {
+ wifi_enable_h: wifi-enable-h {
+ rockchip,pins =
+ <0 10 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wireless-bluetooth {
+ uart0_gpios: uart0-gpios {
+ rockchip,pins =
+ <2 19 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ rt5640 {
+ rt5640_hpcon: rt5640-hpcon {
+ rockchip,pins = <4 21 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int_l: pmic-int-l {
+ rockchip,pins =
+ <1 21 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ usb2 {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins =
+ <1 0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ fusb30x {
+ fusb0_int: fusb0-int {
+ rockchip,pins = <1 2 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vccadc_ref>;
+};
+
+&sdhci {
+ bus-width = <8>;
+ keep-power-in-suspend;
+ mmc-hs400-1_8v;
+ mmc-hs400-enhanced-strobe;
+ non-removable;
+ status = "okay";
+ supports-emmc;
+};
+
+&tsadc {
+ /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-mode = <1>;
+ /* tshut polarity 0:LOW 1:HIGH */
+ rockchip,hw-tshut-polarity = <1>;
+ status = "okay";
+};
+
+&u2phy0 {
+ status = "okay";
+ extcon = <&fusb0>;
+
+ u2phy0_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy0_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&u2phy1 {
+ status = "okay";
+
+ u2phy1_otg: otg-port {
+ status = "okay";
+ };
+
+ u2phy1_host: host-port {
+ phy-supply = <&vcc5v0_host>;
+ status = "okay";
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_xfer &uart0_cts>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH V2 1/2] mtd: move code reading DT specified part probes to the core
From: Boris Brezillon @ 2017-03-31 9:56 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, Rob Herring, Mark Rutland, Frank Rowand,
Linus Walleij, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331093013.29123-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 31 Mar 2017 11:30:12 +0200
Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Handling (creating) partitions for flash devices requires using a proper
> driver that will read partition table (out of somewhere). We can't
> simply try all existing drivers one by one, so MTD subsystem allows
> drivers to specify a list of applicable part probes.
>
> So far physmap_of was the only driver with support for linux,part-probe
> DT property. Other ones had list or probes hardcoded which wasn't making
> them really flexible. It prevented using common flash drivers on
> platforms that required some specific partition table access.
>
> This commit moves support for mentioned DT property to the MTD core
> file. Thanks to calling it on device parse registration (as suggested by
> Boris) all drivers gain support for it for free.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> ---
> drivers/mtd/maps/physmap_of.c | 36 +-----------------------------------
> drivers/mtd/mtdcore.c | 34 ++++++++++++++++++++++++++++++++++
Maybe you should split the patch:
1/ add core infrastructure
2/ remove open-coded version in drivers/mtd/maps/physmap_of.c
BTW, not sure the intermediate "mtd: physmap_of: use OF helpers
for reading strings" patch is really useful, since you move to the
common infrastructure here.
By following my suggestion you get rid of the dependency you have
between this series and patch "mtd: physmap_of: use OF helpers for
reading strings".
> 2 files changed, 35 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
> index 62fa6836f218..49dbb7235848 100644
> --- a/drivers/mtd/maps/physmap_of.c
> +++ b/drivers/mtd/maps/physmap_of.c
> @@ -114,37 +114,9 @@ static struct mtd_info *obsolete_probe(struct platform_device *dev,
> static const char * const part_probe_types_def[] = {
> "cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
>
> -static const char * const *of_get_probes(struct device_node *dp)
> -{
> - const char **res;
> - int count;
> -
> - count = of_property_count_strings(dp, "linux,part-probe");
> - if (count < 0)
> - return part_probe_types_def;
> -
> - res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
> - if (!res)
> - return NULL;
> -
> - count = of_property_read_string_array(dp, "linux,part-probe", res,
> - count);
> - if (count < 0)
> - return NULL;
> -
> - return res;
> -}
> -
> -static void of_free_probes(const char * const *probes)
> -{
> - if (probes != part_probe_types_def)
> - kfree(probes);
> -}
> -
> static const struct of_device_id of_flash_match[];
> static int of_flash_probe(struct platform_device *dev)
> {
> - const char * const *part_probe_types;
> const struct of_device_id *match;
> struct device_node *dp = dev->dev.of_node;
> struct resource res;
> @@ -310,14 +282,8 @@ static int of_flash_probe(struct platform_device *dev)
>
> info->cmtd->dev.parent = &dev->dev;
> mtd_set_of_node(info->cmtd, dp);
> - part_probe_types = of_get_probes(dp);
> - if (!part_probe_types) {
> - err = -ENOMEM;
> - goto err_out;
> - }
> - mtd_device_parse_register(info->cmtd, part_probe_types, NULL,
> + mtd_device_parse_register(info->cmtd, part_probe_types_def, NULL,
> NULL, 0);
> - of_free_probes(part_probe_types);
>
> kfree(mtd_list);
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 66a9dedd1062..a7ab0a24ba1e 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -664,6 +664,32 @@ static void mtd_set_dev_defaults(struct mtd_info *mtd)
> }
> }
>
> +static const char * const *mtd_of_get_probes(struct device_node *np)
> +{
> + const char **res;
> + int count;
> +
> + count = of_property_count_strings(np, "linux,part-probe");
> + if (count < 0)
> + return NULL;
> +
> + res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
> + if (!res)
> + return NULL;
> +
> + count = of_property_read_string_array(np, "linux,part-probe", res,
> + count);
> + if (count < 0)
> + return NULL;
> +
> + return res;
> +}
> +
> +static inline void mtd_of_free_probes(const char * const *probes)
> +{
> + kfree(probes);
> +}
> +
> /**
> * mtd_device_parse_register - parse partitions and register an MTD device.
> *
> @@ -698,11 +724,16 @@ int mtd_device_parse_register(struct mtd_info *mtd, const char * const *types,
> const struct mtd_partition *parts,
> int nr_parts)
> {
> + const char * const *part_probe_types;
> struct mtd_partitions parsed;
> int ret;
>
> mtd_set_dev_defaults(mtd);
>
> + part_probe_types = mtd_of_get_probes(mtd_get_of_node(mtd));
> + if (!part_probe_types)
> + part_probe_types = types;
> +
> memset(&parsed, 0, sizeof(parsed));
>
> ret = parse_mtd_partitions(mtd, types, &parsed, parser_data);
> @@ -720,6 +751,9 @@ int mtd_device_parse_register(struct mtd_info *mtd, const char * const *types,
> memset(&parsed, 0, sizeof(parsed));
> }
>
> + if (part_probe_types != types)
> + mtd_of_free_probes(part_probe_types);
> +
> ret = mtd_add_device_partitions(mtd, &parsed);
> if (ret)
> goto out;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: jacopo @ 2017-03-31 9:52 UTC (permalink / raw)
To: Rob Herring
Cc: Jacopo Mondi, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw,
chris.brandt-zM6kxYcvzFBBDgjK7y7TUQ,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170330223903.yafbhrdulrnv2pfz@rob-hp-laptop>
Hi Rob,
thanks for the ack
On Thu, Mar 30, 2017 at 05:39:03PM -0500, Rob Herring wrote:
> On Fri, Mar 24, 2017 at 04:22:09PM +0100, Jacopo Mondi wrote:
> > Add device tree bindings documentation for Renesas RZ/A1 gpio and pin
> > controller.
> >
> > Signed-off-by: Jacopo Mondi <jacopo+renesas-AW8dsiIh9cEdnm+yROfE0A@public.gmane.org>
> > ---
> > .../bindings/pinctrl/renesas,rza1-pinctrl.txt | 143 +++++++++++++++++++++
> > 1 file changed, 143 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pinctrl/renesas,rza1-pinctrl.txt
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Just an heads-up: in v4 dt bindings will change considerably to meet a
format more close to standard pin controller bindings.
I cannot take you ack here and apply to next iteration as it will
require you or other dt guardians to have a look at it again. Sorry
about this.
Thanks
j
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/7] UDC: Rename amd5536udc driver file based on IP
From: Felipe Balbi @ 2017-03-31 9:49 UTC (permalink / raw)
To: Raviteja Garimella, Rob Herring, Mark Rutland, Greg Kroah-Hartman
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490698929-10915-3-git-send-email-raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 953 bytes --]
Hi,
Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> writes:
> This patch renames the amd5536udc.c that has the core driver
> functionality of Synopsys UDC to snps_udc_core.c
>
> The symbols exported here can be used by any UDC driver that uses
> the same Synopsys IP.
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
unfortunately, this patch doesn't apply:
Applying: UDC: Rename amd5536udc driver file based on IP
error: corrupt patch at line 235
Patch failed at 0001 UDC: Rename amd5536udc driver file based on IP
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
Can you rebase on testing/next and resend?
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH] mtd: use dev_of_node helper in mtd_get_of_node
From: Boris Brezillon @ 2017-03-31 9:49 UTC (permalink / raw)
To: Rafał Miłecki
Cc: David Woodhouse, Brian Norris, Marek Vasut, Richard Weinberger,
Cyrille Pitchen, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331091148.19816-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 31 Mar 2017 11:11:48 +0200
Rafał Miłecki <zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> This allows better compile-time optimizations with CONFIG_OF disabled.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Not sure we care about such micro-optimizations, but it shouldn't hurst
so,
Acked-by: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
> include/linux/mtd/mtd.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index eebdc63cf6af..f8db5b2e4028 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -393,7 +393,7 @@ static inline void mtd_set_of_node(struct mtd_info *mtd,
>
> static inline struct device_node *mtd_get_of_node(struct mtd_info *mtd)
> {
> - return mtd->dev.of_node;
> + return dev_of_node(&mtd->dev);
> }
>
> static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 14/37] mtd: nand: denali: support "nand-ecc-strength" DT property
From: Boris Brezillon @ 2017-03-31 9:46 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Enrico Jorns, Artem Bityutskiy, Dinh Nguyen,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, devicetree, Linux Kernel Mailing List,
Brian Norris, Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland
In-Reply-To: <CAK7LNARUKwMHd79ALDx_SDY9XKcHPY96xTAOMQx6XarFgwb-AA@mail.gmail.com>
On Fri, 31 Mar 2017 14:06:32 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Boris,
>
>
> 2017-03-30 23:02 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
> > On Thu, 30 Mar 2017 15:46:00 +0900
> > Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> >
> >> Historically, this driver tried to choose as big ECC strength as
> >> possible, but it would be reasonable to allow DT to set a particular
> >> ECC strength with "nand-ecc-strength" property. This is useful
> >> when a particular ECC setting is hard-coded by firmware (or hard-
> >> wired by boot ROM).
> >>
> >> If no ECC strength is specified in DT, "nand-ecc-maximize" is implied
> >> since this was the original behavior.
> >
> > You said there is currently no DT users,
>
> Right. No DT users ever in upstream.
>
>
> > so how about changing the
> > "fallback to ECC maximization" behavior for DT users, and instead of
> > maximizing the ECC strength take the NAND requirements into account
> > (chip->ecc_strength_ds).
>
> This is difficult to judge in some cases.
>
> As I said before, 4/512 and 8/1024 are not equivalent.
>
> If chip's requirement chip->ecc_step_ds matches
> to the ecc->size supported by the controller,
> this is easy.
>
>
> If a chip requests 1024B, then the controller can only support 512B chunk
> (or vice versa), it is difficult to simply compare
> ecc strength.
You can try something like that when no explicit ecc.strength and
ecc.size has been set in the DT and when ECC_MAXIMIZE was not passed.
static int
denali_get_closest_ecc_strength(struct denali_nand_info *denali,
int strength)
{
/*
* Whatever you need to select a strength that is greater than
* or equal to strength.
*/
return X;
}
static int denali_try_to_match_ecc_req(struct denali_nand_info *denali)
{
struct nand_chip *chip = &denali->nand;
struct mtd_info *mtd = nand_to_mtd(chip);
int max_ecc_bytes = mtd->oobsize - denali->bbtskipbytes;
int ecc_steps, ecc_strength, ecc_bytes;
int ecc_size = chip->ecc_step_ds;
int ecc_strength = chip->ecc_strength_ds;
/*
* No information provided by the NAND chip, let the core
* maximize the strength.
*/
if (!ecc_size || !ecc_strength)
return -ENOTSUPP;
if (ecc_size > 512)
ecc_size = 1024;
else
ecc_size = 512;
/* Adjust ECC step size based on hardware support. */
if (ecc_size == 1024 &&
!(denali->caps & DENALI_CAP_ECC_SIZE_1024))
ecc_size = 512;
else if(ecc_size == 512 &&
!(denali->caps & DENALI_CAP_ECC_SIZE_512))
ecc_size = 1024;
if (ecc_size < chip->ecc_size_ds) {
/*
* When the selected size if smaller than the expected
* one we try to use the same strength but on 512 blocks
* so that we can still fix the same number of errors
* even if they are concentrated in the first 512bytes
* of a 1024bytes portion.
*/
ecc_strength = chip->ecc_strength_ds;
ecc_strength = denali_get_closest_ecc_strength(denali,
ecc_strength);
} else {
/* Always prefer 1024bytes ECC blocks when possible. */
if (ecc_size != 1024 &&
(denali->caps & DENALI_CAP_ECC_SIZE_1024) &&
mtd->writesize > 1024)
ecc_size = 1024;
/*
* Adjust the strength based on the selected ECC step
* size.
*/
ecc_strength = DIV_ROUND_UP(ecc_size,
chip->ecc_step_ds) *
chip->ecc_strength_ds;
}
ecc_bytes = denali_calc_ecc_bytes(ecc_size,
ecc_strength);
ecc_bytes *= mtd->writesize / ecc_size;
/*
* If we don't have enough space, let the core maximize
* the strength.
*/
if (ecc_bytes > max_ecc_bytes)
return -ENOTSUPP;
chip->ecc.strength = ecc_strength;
chip->ecc.size = ecc_size;
return 0;
}
>
> Is it a bad thing if we use too strong ECC strength?
>
> The disadvantage I see is we will have less OOB-free bytes,
> but this will not be fatal, I guess.
Not a bad thing in general, but I'd prefer to leave the choice to the
user. If one doesn't need the extra-safety brought by ECC strength
maximization and wants to have more OOB bytes it's better to follow
NAND requirements.
^ permalink raw reply
* Re: [PATCH v6 2/2] arm64: dts: move from ARCH_VULCAN to ARCH_THUNDER2
From: Arnd Bergmann @ 2017-03-31 9:44 UTC (permalink / raw)
To: Jayachandran C
Cc: arm-soc, Linux ARM, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Florian Fainelli, Matthias Brugger
In-Reply-To: <1489495634-2920-3-git-send-email-jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Tue, Mar 14, 2017 at 1:47 PM, Jayachandran C
<jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> Move and update device tree files as part of transition from Broadcom
> Vulcan to Cavium ThunderX2.
>
> The changes are to:
> * rename dts/broadcom/vulcan.dtsi to cavium/thunder2-99xx.dtsi,
> update cpu cores to be "cavium,thunder2", and update SoC to be
> "cavium,thunderx2-cn9900"
> * move SoC dts/broadcom/vulcan-eval.dtsi to cavium/thunder2-99xx.dtsi
> and update board name string
> * Update dts/broadcom/Makefile not to build vulcan dtbs
> * Update dts/cavium/Makefile to build thunder2 dtbs
>
> No changes to the dts contents except the updated "compatible" and
> "model" properties.
>
> Signed-off-by: Jayachandran C <jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied to next/dt64.
The contents are fine, but I'd recommend using 'git format-patch -M'
when creating a submission for easier review, in case you do another
patch with a rename in the future.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 1/3] dt-bindings: Add arm64 ARCH_THUNDER2 platform documentation
From: Arnd Bergmann @ 2017-03-31 9:40 UTC (permalink / raw)
To: Jayachandran C
Cc: arm-soc, Linux ARM, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Florian Fainelli, Matthias Brugger
In-Reply-To: <1489608662-4434-2-git-send-email-jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
On Wed, Mar 15, 2017 at 9:11 PM, Jayachandran C
<jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org> wrote:
> Add documentation for Cavium's ThunderX2 CN99XX ARM64 processor. This
> SoC will use "cavium,thunderx2-cn9900" as the compatible property.
>
> Also add a documentation entry for the "cavium,thunder2" cpu core
> present in these SoCs.
>
> Signed-off-by: Jayachandran C <jnair-M3mlKVOIwJVv6pq1l3V1OdBPR1lH4CV8@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Applied on next/dt64, thanks!
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 2/2] dt-bindings: mtd: document linux,part-probe property
From: Rafał Miłecki @ 2017-03-31 9:30 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170331093013.29123-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Support for this property has been introduced in 2010 with commit
9d5da3a9b849 ("mtd: extend physmap_of to let the device tree specify the
parition probe") but it was never documented. Fix this by adding a
proper description and example.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
Documentation/devicetree/bindings/mtd/common.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt
index fc068b923d7a..1ada70e718b2 100644
--- a/Documentation/devicetree/bindings/mtd/common.txt
+++ b/Documentation/devicetree/bindings/mtd/common.txt
@@ -6,10 +6,17 @@ Optional properties:
controller based name) in order to ease flash device identification
and/or describe what they are used for.
+- linux,part-probe: if present, this property should contain a list of strings
+ with partition probes to be used for the flash device. A role of partition
+ probe (parser) is to read/construct partition table and register found
+ partitions. Getting partition table may be platform or device specific so
+ various devices may use various Linux drivers for this purpose.
+
Example:
flash@0 {
label = "System-firmware";
+ linux,part-probe = "cmdlinepart", "ofpart";
/* flash type specific properties */
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 1/2] mtd: move code reading DT specified part probes to the core
From: Rafał Miłecki @ 2017-03-31 9:30 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
In-Reply-To: <20170330215332.32699-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Handling (creating) partitions for flash devices requires using a proper
driver that will read partition table (out of somewhere). We can't
simply try all existing drivers one by one, so MTD subsystem allows
drivers to specify a list of applicable part probes.
So far physmap_of was the only driver with support for linux,part-probe
DT property. Other ones had list or probes hardcoded which wasn't making
them really flexible. It prevented using common flash drivers on
platforms that required some specific partition table access.
This commit moves support for mentioned DT property to the MTD core
file. Thanks to calling it on device parse registration (as suggested by
Boris) all drivers gain support for it for free.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
drivers/mtd/maps/physmap_of.c | 36 +-----------------------------------
drivers/mtd/mtdcore.c | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 35 deletions(-)
diff --git a/drivers/mtd/maps/physmap_of.c b/drivers/mtd/maps/physmap_of.c
index 62fa6836f218..49dbb7235848 100644
--- a/drivers/mtd/maps/physmap_of.c
+++ b/drivers/mtd/maps/physmap_of.c
@@ -114,37 +114,9 @@ static struct mtd_info *obsolete_probe(struct platform_device *dev,
static const char * const part_probe_types_def[] = {
"cmdlinepart", "RedBoot", "ofpart", "ofoldpart", NULL };
-static const char * const *of_get_probes(struct device_node *dp)
-{
- const char **res;
- int count;
-
- count = of_property_count_strings(dp, "linux,part-probe");
- if (count < 0)
- return part_probe_types_def;
-
- res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
- if (!res)
- return NULL;
-
- count = of_property_read_string_array(dp, "linux,part-probe", res,
- count);
- if (count < 0)
- return NULL;
-
- return res;
-}
-
-static void of_free_probes(const char * const *probes)
-{
- if (probes != part_probe_types_def)
- kfree(probes);
-}
-
static const struct of_device_id of_flash_match[];
static int of_flash_probe(struct platform_device *dev)
{
- const char * const *part_probe_types;
const struct of_device_id *match;
struct device_node *dp = dev->dev.of_node;
struct resource res;
@@ -310,14 +282,8 @@ static int of_flash_probe(struct platform_device *dev)
info->cmtd->dev.parent = &dev->dev;
mtd_set_of_node(info->cmtd, dp);
- part_probe_types = of_get_probes(dp);
- if (!part_probe_types) {
- err = -ENOMEM;
- goto err_out;
- }
- mtd_device_parse_register(info->cmtd, part_probe_types, NULL,
+ mtd_device_parse_register(info->cmtd, part_probe_types_def, NULL,
NULL, 0);
- of_free_probes(part_probe_types);
kfree(mtd_list);
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 66a9dedd1062..a7ab0a24ba1e 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -664,6 +664,32 @@ static void mtd_set_dev_defaults(struct mtd_info *mtd)
}
}
+static const char * const *mtd_of_get_probes(struct device_node *np)
+{
+ const char **res;
+ int count;
+
+ count = of_property_count_strings(np, "linux,part-probe");
+ if (count < 0)
+ return NULL;
+
+ res = kzalloc((count + 1) * sizeof(*res), GFP_KERNEL);
+ if (!res)
+ return NULL;
+
+ count = of_property_read_string_array(np, "linux,part-probe", res,
+ count);
+ if (count < 0)
+ return NULL;
+
+ return res;
+}
+
+static inline void mtd_of_free_probes(const char * const *probes)
+{
+ kfree(probes);
+}
+
/**
* mtd_device_parse_register - parse partitions and register an MTD device.
*
@@ -698,11 +724,16 @@ int mtd_device_parse_register(struct mtd_info *mtd, const char * const *types,
const struct mtd_partition *parts,
int nr_parts)
{
+ const char * const *part_probe_types;
struct mtd_partitions parsed;
int ret;
mtd_set_dev_defaults(mtd);
+ part_probe_types = mtd_of_get_probes(mtd_get_of_node(mtd));
+ if (!part_probe_types)
+ part_probe_types = types;
+
memset(&parsed, 0, sizeof(parsed));
ret = parse_mtd_partitions(mtd, types, &parsed, parser_data);
@@ -720,6 +751,9 @@ int mtd_device_parse_register(struct mtd_info *mtd, const char * const *types,
memset(&parsed, 0, sizeof(parsed));
}
+ if (part_probe_types != types)
+ mtd_of_free_probes(part_probe_types);
+
ret = mtd_add_device_partitions(mtd, &parsed);
if (ret)
goto out;
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Jacek Anaszewski @ 2017-03-31 9:28 UTC (permalink / raw)
To: Pavel Machek, Bjorn Andersson
Cc: Rob Herring, Richard Purdie, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170330074309.GA28533@amd>
Hi Bjorn and Pavel,
On 03/30/2017 09:43 AM, Pavel Machek wrote:
> Hi!
>
>>>> There is a binding for ti,lp55xx, but there's nothing I can reuse from
>>>> that binding...because it's completely different hardware.
>>>
>>> Agreed, if you drop the pattern stuff from the binding, at least for now.
>>
>> I do not have a strong preference to expose these knobs in devicetree
>> and I do fear that finding some common "pattern" bindings that suits
>> everyone will be very difficult.
>>
>> So I'll drop them from the binding for now.
>
> Ok.
>
>>> If you want driver merged quickly, I believe the best way would be to
>>> leave out pattern support for now. We can merge the basic driver
>>> easily to 4.12.
>>>
>>
>> I'm not that much in a hurry and would rather see that we resolve any
>> outstanding issues with the implementation of the pattern handling.
>
> Ok, good.
>
>> But regardless of this we still have the problem that the typical
>> Qualcomm PMIC has 8 LPG-blocks and any triple could be driving a
>> RGB-LED. So we would have to create some sort of in-driver-wrapper
>> around any three instances exposing them as a single LED to the user.
>
> Yes, I believe we should do the wrapping. In N900 case,
>
>> I rather expose the individual channels and make sure that when we
>> trigger a blink operation or enable a pattern (i.e. the two operations
>> that do require synchronization) we will perform that synchronization
>> under the hood.
>
> First, we need a way to tell userspace which LEDs are synchronized,
> because otherwise it will be confusing.
There is one year old discussion [0] about the possible approaches
to RGB sub-LEDs synchronization problem and patterns in general.
My last message with API design proposal has been left unanswered.
Probably we continue that discussion here.
Generally Bjorn's drivers touch two yet to be addressed issues:
- RGB LED support
- Generic support for patterns
It is likely that both issues can be solved by utilizing trigger
mechanism. The possible solution to the problem Bjorn tried to
address with /sys/class/leds/<led>/pattern comma separated list
could be a trigger with adjustable number of pattern intervals.
The trigger once activated would create a directory with the
number of files corresponding to the number of requested intervals,
and then user could write an interval value by writing it to the
corresponding file. Somehow related approach has been implemented
for USB port LED trigger:
0f247626cbbf ('usb: core: Introduce a USB port LED trigger")
In both RGB and pattern approaches we should assess
if it is acceptable to provide a pattern for trigger name,
e.g. blink-pattern-{num_intervals}.
If so, then "echo transition-pattern-15" would create a directory
e.g. transition_intervals with files interval_0 to interval_14,
that could be adjusted by userspace.
> Second, there are more issues than just patterns with the RGB
> LED. Most important is ability to set particular colors. You want to
> set the RGB LED to "white", but that does not mean you can set
> red=green=blue=1.0. You want color to look the same on LCD and on the
> LED, which means coefficients for white and some kind of function for
> brightness-to-PWM conversion.
Shouldn't we leave that entirely to the userspace? Can we come up
with coefficients that will guarantee the same result on all existing
LCD devices?
>>> Incremental patches sound like a good idea, yes.
>>>
>>> I'd say that testing with actual RGB LED is not a requirement... as
>>> long as we design reasonable interface where the synchronizaction will
>>> be easy.
>>>
>>
>> As this relates to the board layout (which LPG-channels are hooked to a
>> RGB) I think it makes sense to expose a mechanism in devicetree to
>> indicate which channels should have their pattern/blink synchronized.
>>
>> We should be able to extend the LUT (the hardware that actually
>> implements the pattern-walker logic) with a DT-property like:
>>
>> qcom,synchronize-group-0 = <1, 2, 3>;
>> qcom,synchronize-group-1 = <5, 6, 7>;
>>
>> And whenever we configure a pattern involving one of the affected LEDs
>> from a group we start all of them.
>
> Yes we need some kind of grouping.
>
> Additional complexity in the N900 case... groups can actually be
> configured at run time. Original Maemo used that ability to group 6
> keyboard backlight leds, and then run pattern on them. OTOH... I don't
> think we _need_ to support that functionality.
>
> Best regards,
> Pavel
>
[0] https://lkml.org/lkml/2016/4/18/179
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drm: rcar-du: Document the vsps property in the DT bindings
From: Geert Uytterhoeven @ 2017-03-31 9:21 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Laurent Pinchart, Sergei Shtylyov,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
DRI Development, Linux-Renesas
In-Reply-To: <8105647.ANSr0hWnZy@avalon>
Hi Laurent,
On Fri, Mar 31, 2017 at 11:19 AM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
>> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
>> > The property is used by the driver but is missing from the DT bindings.
>> > Document it.
>> >
>> > Reported-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
>> > Signed-off-by: Laurent Pinchart
>> > <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> > ---
>> > Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
>> > 1 file changed, 5 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
>> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
>> > 1a02f099a0ff..cf34893a1b53 100644
>> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
>> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
>> >
>> > @@ -36,6 +36,11 @@ Required Properties:
>> > When supplied they must be named "dclkin.x" with "x" being the
>> > input
>> > clock numerical index.
>> >
>> > +Optional Properties:
>> > +
>> > + - vsps: A list of phandles to the VSP nodes that handle the memory
>> > + interfaces for the DU channels (Gen3 only).
>>
>> ", one per channel"?
>>
>> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
>
> How about making it mandatory on Gen2 as well ? The VSPs are there, even if
> the driver doesn't use them, it makes sense to describe the connection. Of
Fine for me, as this is hardware description.
> course the driver will treat the property as optional for backward
> compatibility.
OK.
Disclaimer: I didn't follow the discussion about using or not using the vsps
on Gen2 that closely, and don't remember the outcome.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] drm: rcar-du: Document the vsps property in the DT bindings
From: Laurent Pinchart @ 2017-03-31 9:19 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Laurent Pinchart, Sergei Shtylyov, devicetree@vger.kernel.org,
DRI Development, Linux-Renesas
In-Reply-To: <CAMuHMdUiDzGt6bz96D-5yRLF-HiZfpQTTxKP5Y4+j-9HiF1LLQ@mail.gmail.com>
Hi Geert,
On Monday 27 Mar 2017 13:05:48 Geert Uytterhoeven wrote:
> On Mon, Mar 27, 2017 at 11:56 AM, Laurent Pinchart wrote:
> > The property is used by the driver but is missing from the DT bindings.
> > Document it.
> >
> > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > Signed-off-by: Laurent Pinchart
> > <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> >
> > Documentation/devicetree/bindings/display/renesas,du.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt
> > b/Documentation/devicetree/bindings/display/renesas,du.txt index
> > 1a02f099a0ff..cf34893a1b53 100644
> > --- a/Documentation/devicetree/bindings/display/renesas,du.txt
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt
> >
> > @@ -36,6 +36,11 @@ Required Properties:
> > When supplied they must be named "dclkin.x" with "x" being the
> > input
> > clock numerical index.
> >
> > +Optional Properties:
> > +
> > + - vsps: A list of phandles to the VSP nodes that handle the memory
> > + interfaces for the DU channels (Gen3 only).
>
> ", one per channel"?
>
> Required for Gen3, optional for Gen2? (cfr. Sergei's patches).
How about making it mandatory on Gen2 as well ? The VSPs are there, even if
the driver doesn't use them, it makes sense to describe the connection. Of
course the driver will treat the property as optional for backward
compatibility.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] mtd: use dev_of_node helper in mtd_get_of_node
From: Rafał Miłecki @ 2017-03-31 9:11 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger
Cc: Cyrille Pitchen, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rafał Miłecki
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This allows better compile-time optimizations with CONFIG_OF disabled.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
include/linux/mtd/mtd.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index eebdc63cf6af..f8db5b2e4028 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -393,7 +393,7 @@ static inline void mtd_set_of_node(struct mtd_info *mtd,
static inline struct device_node *mtd_get_of_node(struct mtd_info *mtd)
{
- return mtd->dev.of_node;
+ return dev_of_node(&mtd->dev);
}
static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [Patch v3 02/11] [media] s5p-mfc: Adding initial support for MFC v10.10
From: Smitha T Murthy @ 2017-03-31 9:06 UTC (permalink / raw)
To: linux-arm-kernel, linux-media, linux-kernel
Cc: kyungmin.park, kamil, jtp.park, a.hajda, mchehab, pankaj.dubey,
krzk, m.szyprowski, s.nawrocki, Smitha T Murthy, Rob Herring,
devicetree
In-Reply-To: <1490951200-32070-1-git-send-email-smitha.t@samsung.com>
Adding the support for MFC v10.10, with new register file and
necessary hw control, decoder, encoder and structural changes.
CC: Rob Herring <robh+dt@kernel.org>
CC: devicetree@vger.kernel.org
Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/media/s5p-mfc.txt | 1 +
drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 36 ++++++++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc.c | 30 ++++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 9 +++++-
drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 4 +++
drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 32 ++++++++-----------
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 16 ++++------
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 9 ++++--
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 2 ++
9 files changed, 106 insertions(+), 33 deletions(-)
create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2c90128..b83727b 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -13,6 +13,7 @@ Required properties:
(c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
(d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
(e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
+ (f) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC
- reg : Physical base address of the IP registers and length of memory
mapped region.
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
new file mode 100644
index 0000000..1ca09d6
--- /dev/null
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
@@ -0,0 +1,36 @@
+/*
+ * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
+ *
+ * Copyright (c) 2017 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _REGS_MFC_V10_H
+#define _REGS_MFC_V10_H
+
+#include <linux/sizes.h>
+#include "regs-mfc-v8.h"
+
+/* MFCv10 register definitions*/
+#define S5P_FIMV_MFC_CLOCK_OFF_V10 0x7120
+#define S5P_FIMV_MFC_STATE_V10 0x7124
+
+/* MFCv10 Context buffer sizes */
+#define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)
+#define MFC_H264_DEC_CTX_BUF_SIZE_V10 (2 * SZ_1M)
+#define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)
+#define MFC_H264_ENC_CTX_BUF_SIZE_V10 (100 * SZ_1K)
+#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)
+
+/* MFCv10 variant defines */
+#define MAX_FW_SIZE_V10 (SZ_1M)
+#define MAX_CPB_SIZE_V10 (3 * SZ_1M)
+#define MFC_VERSION_V10 0xA0
+#define MFC_NUM_PORTS_V10 1
+
+#endif /*_REGS_MFC_V10_H*/
+
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index c6f0754..443ff7e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1547,6 +1547,33 @@ static struct s5p_mfc_variant mfc_drvdata_v8_5433 = {
.num_clocks = 3,
};
+static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
+ .dev_ctx = MFC_CTX_BUF_SIZE_V10,
+ .h264_dec_ctx = MFC_H264_DEC_CTX_BUF_SIZE_V10,
+ .other_dec_ctx = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
+ .h264_enc_ctx = MFC_H264_ENC_CTX_BUF_SIZE_V10,
+ .other_enc_ctx = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
+};
+
+static struct s5p_mfc_buf_size buf_size_v10 = {
+ .fw = MAX_FW_SIZE_V10,
+ .cpb = MAX_CPB_SIZE_V10,
+ .priv = &mfc_buf_size_v10,
+};
+
+static struct s5p_mfc_buf_align mfc_buf_align_v10 = {
+ .base = 0,
+};
+
+static struct s5p_mfc_variant mfc_drvdata_v10 = {
+ .version = MFC_VERSION_V10,
+ .version_bit = MFC_V10_BIT,
+ .port_num = MFC_NUM_PORTS_V10,
+ .buf_size = &buf_size_v10,
+ .buf_align = &mfc_buf_align_v10,
+ .fw_name[0] = "s5p-mfc-v10.fw",
+};
+
static const struct of_device_id exynos_mfc_match[] = {
{
.compatible = "samsung,mfc-v5",
@@ -1563,6 +1590,9 @@ static const struct of_device_id exynos_mfc_match[] = {
}, {
.compatible = "samsung,exynos5433-mfc",
.data = &mfc_drvdata_v8_5433,
+ }, {
+ .compatible = "samsung,mfc-v10",
+ .data = &mfc_drvdata_v10,
},
{},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index b45d18c..3a4ca55 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -23,7 +23,7 @@
#include <media/v4l2-ioctl.h>
#include <media/videobuf2-v4l2.h>
#include "regs-mfc.h"
-#include "regs-mfc-v8.h"
+#include "regs-mfc-v10.h"
#define S5P_MFC_NAME "s5p-mfc"
@@ -723,11 +723,18 @@ void s5p_mfc_cleanup_queue(struct list_head *lh, struct vb2_queue *vq);
#define IS_MFCV6_PLUS(dev) (dev->variant->version >= 0x60 ? 1 : 0)
#define IS_MFCV7_PLUS(dev) (dev->variant->version >= 0x70 ? 1 : 0)
#define IS_MFCV8_PLUS(dev) (dev->variant->version >= 0x80 ? 1 : 0)
+#define IS_MFCV10(dev) (dev->variant->version >= 0xA0 ? 1 : 0)
#define MFC_V5_BIT BIT(0)
#define MFC_V6_BIT BIT(1)
#define MFC_V7_BIT BIT(2)
#define MFC_V8_BIT BIT(3)
+#define MFC_V10_BIT BIT(5)
+#define MFC_V5PLUS_BITS (MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT | \
+ MFC_V8_BIT | MFC_V10_BIT)
+#define MFC_V6PLUS_BITS (MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT | \
+ MFC_V10_BIT)
+#define MFC_V7PLUS_BITS (MFC_V7_BIT | MFC_V8_BIT | MFC_V10_BIT)
#endif /* S5P_MFC_COMMON_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index 484af6b..0ded23c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -267,6 +267,10 @@ int s5p_mfc_init_hw(struct s5p_mfc_dev *dev)
}
else
mfc_write(dev, 0x3ff, S5P_FIMV_SW_RESET);
+
+ if (IS_MFCV10(dev))
+ mfc_write(dev, 0x0, S5P_FIMV_MFC_CLOCK_OFF_V10);
+
mfc_debug(2, "Will now wait for completion of firmware transfer\n");
if (s5p_mfc_wait_for_done_dev(dev, S5P_MFC_R2H_CMD_FW_STATUS_RET)) {
mfc_err("Failed to load firmware\n");
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index 0ec2928..db6d9fa 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -54,7 +54,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "4:2:0 2 Planes Y/CrCb",
@@ -62,7 +62,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "H264 Encoded Stream",
@@ -70,8 +70,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "H264/MVC Encoded Stream",
@@ -79,7 +78,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_MVC_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "H263 Encoded Stream",
@@ -87,8 +86,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H263_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG1 Encoded Stream",
@@ -96,8 +94,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG2_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG2 Encoded Stream",
@@ -105,8 +102,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG2_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG4 Encoded Stream",
@@ -114,8 +110,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG4_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "XviD Encoded Stream",
@@ -123,8 +118,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG4_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VC1 Encoded Stream",
@@ -132,8 +126,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VC1_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VC1 RCV Encoded Stream",
@@ -141,8 +134,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VC1RCV_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VP8 Encoded Stream",
@@ -150,7 +142,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VP8_DEC,
.type = MFC_FMT_DEC,
.num_planes = 1,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index e39d9e0..e81b359 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -57,8 +57,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "4:2:0 2 Planes Y/CrCb",
@@ -66,7 +65,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V6PLUS_BITS,
},
{
.name = "H264 Encoded Stream",
@@ -74,8 +73,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H264_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "MPEG4 Encoded Stream",
@@ -83,8 +81,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_MPEG4_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "H263 Encoded Stream",
@@ -92,8 +89,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_H263_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V5PLUS_BITS,
},
{
.name = "VP8 Encoded Stream",
@@ -101,7 +97,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_VP8_ENC,
.type = MFC_FMT_ENC,
.num_planes = 1,
- .versions = MFC_V7_BIT | MFC_V8_BIT,
+ .versions = MFC_V7PLUS_BITS,
},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 7682b0e..9dc106e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -358,6 +358,7 @@ static int calc_plane(int width, int height)
static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
{
+ struct s5p_mfc_dev *dev = ctx->dev;
ctx->buf_width = ALIGN(ctx->img_width, S5P_FIMV_NV12MT_HALIGN_V6);
ctx->buf_height = ALIGN(ctx->img_height, S5P_FIMV_NV12MT_VALIGN_V6);
mfc_debug(2, "SEQ Done: Movie dimensions %dx%d,\n"
@@ -374,8 +375,12 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct s5p_mfc_ctx *ctx)
if (ctx->codec_mode == S5P_MFC_CODEC_H264_DEC ||
ctx->codec_mode == S5P_MFC_CODEC_H264_MVC_DEC) {
- ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
- ctx->img_height);
+ if (IS_MFCV10(dev))
+ ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V10(ctx->img_width,
+ ctx->img_height);
+ else
+ ctx->mv_size = S5P_MFC_DEC_MV_SIZE_V6(ctx->img_width,
+ ctx->img_height);
ctx->mv_size = ALIGN(ctx->mv_size, 16);
} else {
ctx->mv_size = 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
index 8055848..021b8db 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h
@@ -24,6 +24,8 @@
#define MB_HEIGHT(y_size) DIV_ROUND_UP(y_size, 16)
#define S5P_MFC_DEC_MV_SIZE_V6(x, y) (MB_WIDTH(x) * \
(((MB_HEIGHT(y)+1)/2)*2) * 64 + 128)
+#define S5P_MFC_DEC_MV_SIZE_V10(x, y) (MB_WIDTH(x) * \
+ (((MB_HEIGHT(y)+1)/2)*2) * 64 + 512)
/* Definition */
#define ENC_MULTI_SLICE_MB_MAX ((1 << 30) - 1)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v5 4/9] coresight: refactor with function of_coresight_get_cpu
From: Suzuki K Poulose @ 2017-03-31 9:05 UTC (permalink / raw)
To: Leo Yan, Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Michael Turquette, Stephen Boyd, Mathieu Poirier, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk, mike.leach,
sudeep.ho
In-Reply-To: <1490466197-29163-5-git-send-email-leo.yan@linaro.org>
On 25/03/17 18:23, Leo Yan wrote:
> This is refactor to add function of_coresight_get_cpu(), so it's used to
> retrieve CPU id for coresight component. Finally can use it as a common
> function for multiple places.
>
> Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> - if (found)
> - break;
> - }
> - of_node_put(dn);
> -
> - /* Affinity to CPU0 if no cpu nodes are found */
> - pdata->cpu = found ? cpu : 0;
> + pdata->cpu = of_coresight_get_cpu(node);
>
> return pdata;
> }
> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
> index 2a5982c..bf96678 100644
> --- a/include/linux/coresight.h
> +++ b/include/linux/coresight.h
> @@ -263,9 +263,11 @@ static inline int coresight_timeout(void __iomem *addr, u32 offset,
> #endif
>
> #ifdef CONFIG_OF
> +extern int of_coresight_get_cpu(struct device_node *node);
> extern struct coresight_platform_data *of_get_coresight_platform_data(
> struct device *dev, struct device_node *node);
> #else
> +static inline int of_coresight_get_cpu(struct device_node *node) { return 0; }
> static inline struct coresight_platform_data *of_get_coresight_platform_data(
> struct device *dev, struct device_node *node) { return NULL; }
> #endif
>
^ permalink raw reply
* Re: [PATCH v5 1/9] coresight: bindings for CPU debug module
From: Suzuki K Poulose @ 2017-03-31 9:04 UTC (permalink / raw)
To: Leo Yan, Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Michael Turquette, Stephen Boyd, Mathieu Poirier, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk, mike.leach,
sudeep.ho
In-Reply-To: <1490466197-29163-2-git-send-email-leo.yan@linaro.org>
On 25/03/17 18:23, Leo Yan wrote:
> According to ARMv8 architecture reference manual (ARM DDI 0487A.k)
> Chapter 'Part H: External debug', the CPU can integrate debug module
> and it can support self-hosted debug and external debug. Especially
> for supporting self-hosted debug, this means the program can access
> the debug module from mmio region; and usually the mmio region is
> integrated with coresight.
>
> So add document for binding debug component, includes binding to APB
> clock; and also need specify the CPU node which the debug module is
> dedicated to specific CPU.
>
> Suggested-by: Mike Leach <mike.leach@linaro.org>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* Re: [PATCH V1 1/1] mtd: mtk-nor: set controller to 4B mode with large capacity flash
From: Cyrille Pitchen @ 2017-03-31 8:56 UTC (permalink / raw)
To: Guochun Mao, Marek Vasut
Cc: Boris Brezillon, Mark Rutland, devicetree, Richard Weinberger,
Russell King, linux-kernel, Rob Herring, linux-mtd,
Matthias Brugger, linux-mediatek, Cyrille Pitchen,
David Woodhouse, linux-arm-kernel
In-Reply-To: <1490927207.7262.7.camel@mhfsdcap03>
Le 31/03/2017 à 04:26, Guochun Mao a écrit :
> Hi Cyrille, Marek,
>
> Thanks for your suggestions.
>
> On Thu, 2017-03-30 at 19:40 +0200, Cyrille Pitchen wrote:
>> Hi Guochun,
>>
>> Le 30/03/2017 à 10:23, Guochun Mao a écrit :
>>> when nor's size larger than 16MByte, nor and controller should
>>> enter 4Byte mode simultaneously.
>>>
>>> Signed-off-by: Guochun Mao <guochun.mao@mediatek.com>
>>> ---
>>> drivers/mtd/spi-nor/mtk-quadspi.c | 7 +++++++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> index e661877..05cd8a8 100644
>>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c
>>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
>>> @@ -369,6 +369,13 @@ static int mt8173_nor_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>>> /* We only handle 1 byte */
>>> ret = mt8173_nor_wr_sr(mt8173_nor, *buf);
>>> break;
>>> + case SPINOR_OP_EN4B:
>>> + /* Set nor controller to 4-byte address mode,
>>> + * and simultaneously set nor flash.
>>> + * This case should cooperate with default operation.
>>> + */
>>> + writeb(readb(mt8173_nor->base + MTK_NOR_DUAL_REG) | 0x10,
>>> + mt8173_nor->base + MTK_NOR_DUAL_REG);
>>
>> This is not good: you should check in both mt8173_nor_read() and
>> mt8173_nor_write() whether nor->addr_width is either 3 or 4.
>>
>> from include/linux/mtd/spi-nor.h:
>> * @addr_width: number of address bytes
>>
>> Besides SPI commands using an op code from 4-byte address instruction
>> set always carry a 4-byte address. They can be used directly, without
>> sending the SPINOR_OP_EN4B before. So you cannot assume that addresses
>> will be 4-byte long only if your SPI controller driver has seen a
>> SPINOR_OP_EN4B command before. This assumption is wrong.
> Nor->addr_width is assigned in spi_nor_scan in spi-nor.c, and it's not
> modified in later process.
> Does it means that we will not switch nor between 3Byte address and
> 4Byte?
> So, is it better to check nor->addr_width when do nor initialization?
>
Currently yes, nor->addr_width, nor->read_opcode, nor->read_dummy, and
nor->program_opcode are set once for all in spi_nor_scan().
However, nor->read() is likely to be called soon from spi_nor_scan()
with values of nor->addr_width, nor->read_opcode and nor->read_dummy
different from those selected when exiting spi_nor_scan().
So nor->read() / mt8173_nor_read should check nor->addr_width,
nor->read_opcode and nor->read_dummy at each call.
More precisely, I plan to use nor->read() from spi_nor_scan() to read
SFDP (Serial Flash Discoverable Parameters) data.
Whatever op code, numbers of address bytes and dummy cycles used for
(Fast) Read commands, the Read SFDP command uses fixed settings
standardized for all manufacturers and all memory parts:
- op code: 5Ah
- number of bytes for the address: 3 (even for memory > 128Mbits)
- number of dummy clock cycles: 8 clocks
https://patchwork.ozlabs.org/patch/742380/
Please have a look at the spi_nor_read_sfdp().
spi_nor_read_sfdp() is likely to be called from and only from
spi_nor_scan().
Best regards,
Cyrille
>>
>> SPI controller driver should never check SPINOR_OP_* op codes like this.
> I agree that SPI controller driver should not check SPINOR_OP_* op codes
> like what I do.
> I will correct it next version.
>
> Best Regards,
> Guochun
>>
>> Then, testing SPINOR_OP_RDSR from mt8173_nor_read_reg() or
>> SPINOR_OP_WRSR from mt8173_nor_write_reg() is not a good practice too:
>> op codes may change depending on the memory manufacturer. So testing op
>> code values like you do can work with some memories but maybe not all.
>>
>> Finally, don't use 0x10, please define a macro instead.
>>
>> Best regards,
>>
>> Cyrille
>>
>>> default:
>>> ret = mt8173_nor_do_tx_rx(mt8173_nor, opcode, buf, len, NULL, 0);
>>> if (ret)
>>>
>>
>
>
>
^ permalink raw reply
* Device Tree Binding for Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong @ 2017-03-31 8:50 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
Hi Rob,
I would like to upstream the attached device tree binding patch to the
community. This is required for the support of framebuffer drivers of
the Intel FPGA Video and Image Processing Suite intended for the
Arria10 devkit.
The device tree information includes the maximum width and height
supported by the framebuffer display. These are fixed parameters
determined by the use who the Quartus design system to program the
FPGA in the Arria10 devkit and its variants.
BR
Hean Loong
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Intel-FPGA-Video-and-Image-Processing-Suite-device-t.patch --]
[-- Type: text/x-patch; name="0001-Intel-FPGA-Video-and-Image-Processing-Suite-device-t.patch", Size: 1918 bytes --]
From 23a9e274bb517b8e232c5aa4cf9737de1644b708 Mon Sep 17 00:00:00 2001
From: Ong, Hean Loong <hean.loong.ong@intel.com>
Date: Thu, 30 Mar 2017 17:59:37 +0800
Subject: [PATCHv0] Intel FPGA Video and Image Processing Suite device tree binding
Device tree binding for Intel FPGA Video and Image
Processing Suite. The binding involved would be generated
from the Altera (Intel) Qsys system. The bindings would
set the max width, max height, buts per pixel and memory
port width. The device tree binding only supports the Intel
Arria10 devkit and its variants. Vendor name retained as
altr.
Signed-off-by: Ong, Hean Loong <hean.loong.ong@intel.com>
---
.../devicetree/bindings/gpu/altr,vip-fb2.txt | 24 ++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
diff --git a/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
new file mode 100644
index 0000000..9ba3209
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/altr,vip-fb2.txt
@@ -0,0 +1,24 @@
+Intel Video and Image Processing(VIP) Frame Buffer II bindings
+
+Supported hardware: Arria 10 and above with display port IP
+
+Required properties:
+- compatible: "altr,vip-frame-buffer-2.0"
+- reg: Physical base address and length of the framebuffer controller's
+ registers.
+- max-width: The width of the framebuffer in pixels.
+- max-height: The height of the framebuffer in pixels.
+- bits-per-symbol: only "8" is currently supported
+- mem-port-width = the bus width of the avalon master port on the frame reader
+
+Example:
+
+dp_0_frame_buf: vip@0x100000280 {
+ compatible = "altr,vip-frame-buffer-2.0";
+ reg = <0x00000001 0x00000280 0x00000040>;
+ altr,max-width = <1280>;
+ altr,max-height = <720>;
+ altr,bits-per-symbol = <8>;
+ altr,mem-port-width = <128>;
+};
+
--
1.7.1
^ permalink raw reply related
* [PATCH 3/3] ARM64: dts: meson-gx: Add SoC info register
From: Neil Armstrong @ 2017-03-31 8:47 UTC (permalink / raw)
To: khilman, carlo
Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <1490950079-10145-1-git-send-email-narmstrong@baylibre.com>
Add node for the Amlogic Meson GX SoC information register.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 886efa5..c8e42d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -357,6 +357,11 @@
#reset-cells = <1>;
};
+ chipid@220 {
+ compatible = "amlogic,meson-gx-socinfo";
+ reg = <0x0 0x00220 0x0 0x4>;
+ };
+
uart_AO: serial@4c0 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x004c0 0x0 0x14>;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: arm: amlogic: Add SoC information bindings
From: Neil Armstrong @ 2017-03-31 8:47 UTC (permalink / raw)
To: khilman, carlo
Cc: Neil Armstrong, linux-amlogic, linux-arm-kernel, linux-kernel,
devicetree
In-Reply-To: <1490950079-10145-1-git-send-email-narmstrong@baylibre.com>
Add bindings for the SoC information register of the Amlogic SoCs.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.txt | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt
index bfd5b55..b850985 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -52,3 +52,23 @@ Board compatible values:
- "amlogic,q201" (Meson gxm s912)
- "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
- "nexbox,a1" (Meson gxm s912)
+
+Amlogic Meson GX SoCs Information
+----------------------------------
+
+The Meson SoCs have a Product Register that allows to retrieve SoC type,
+package and revision information. If present, a device node for this register
+should be added.
+
+Required properties:
+ - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-socinfo".
+ - reg: Base address and length of the register block.
+
+Examples
+--------
+
+ chipid@220 {
+ compatible = "amlogic,meson-gx-socinfo";
+ reg = <0x0 0x00220 0x0 0x4>;
+ };
+
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v4 4/6] arm64: dts: rockchip: add core dtsi file for RK3328 SoCs
From: Shawn Lin @ 2017-03-31 8:27 UTC (permalink / raw)
To: cl
Cc: heiko, robh+dt, mark.rutland, zhengxing, andy.yan, jay.xu,
matthias.bgg, paweljarosz3691, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, wsa, linux-i2c, jic23, knaack.h,
lars, pmeerw, wxt, david.wu, linux-iio, akpm, dianders,
yamada.masahiro, catalin.marinas, will.deacon, afaerber, shawnguo,
khilman, arnd, fabio.estevam, zhangqing, kever.yang
In-Reply-To: <1490607650-18650-4-git-send-email-cl@rock-chips.com>
Hi Liang,
On 2017/3/27 17:40, cl@rock-chips.com wrote:
> From: Liang Chen <cl@rock-chips.com>
>
> This patch adds core dtsi file for Rockchip RK3328 SoCs.
>
> Signed-off-by: Liang Chen <cl@rock-chips.com>
> ---
----8<------
> +
> + sdmmc1 {
> + sdmmc1_clk: sdmmc1-clk {
> + rockchip,pins =
> + <1 RK_PB4 1 &pcfg_pull_none_8ma>;
> + };
> +
> + sdmmc1_cmd: sdmmc1-cmd {
> + rockchip,pins = <1 RK_PB5 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_pwren: sdmmc1-pwren {
> + rockchip,pins = <1 RK_PC2 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_wrprt: sdmmc1-wrprt {
> + rockchip,pins = <1 RK_PC4 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_dectn: sdmmc1-dectn {
> + rockchip,pins = <1 RK_PC3 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_bus1: sdmmc1-bus1 {
> + rockchip,pins = <1 RK_PB6 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_bus4: sdmmc1-bus4 {
> + rockchip,pins = <1 RK_PB4 1 &pcfg_pull_up_8ma>,
> + <1 RK_PB5 1 &pcfg_pull_up_8ma>,
I'm pretty sure this isn't correct as sdmmc1_bus1 even doesn't contain
one same pinctrl(data0) as sdmmc1_bus4. So, the first two pins should be
"1 RK_PB6" and "1 RK_PB7".....
> + <1 RK_PC0 1 &pcfg_pull_up_8ma>,
> + <1 RK_PC1 1 &pcfg_pull_up_8ma>;
> + };
> +
> + sdmmc1_gpio: sdmmc1-gpio {
> + rockchip,pins =
> + <1 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PB5 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PB6 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PB7 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC0 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_up_4ma>,
> + <1 RK_PC4 RK_FUNC_GPIO &pcfg_pull_up_4ma>;
> + };
> + };
> +
> + emmc {
> + emmc_clk: emmc-clk {
> + rockchip,pins =
> + <3 RK_PC5 2 &pcfg_pull_none_12ma>;
> + };
> +
> + emmc_cmd: emmc-cmd {
> + rockchip,pins =
> + <3 RK_PC3 2 &pcfg_pull_up_12ma>;
> + };
> +
> + emmc_pwren: emmc-pwren {
> + rockchip,pins = <3 RK_PC6 2 &pcfg_pull_none>;
> + };
> +
> + emmc_rstnout: emmc-rstnout {
> + rockchip,pins = <3 RK_PC4 2 &pcfg_pull_none>;
> + };
> +
> + emmc_bus1: emmc-bus1 {
> + rockchip,pins =
> + <0 RK_PA7 2 &pcfg_pull_up_12ma>;
> + };
> +
> + emmc_bus4: emmc-bus4 {
> + rockchip,pins =
> + <0 RK_PA7 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD4 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD5 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD6 2 &pcfg_pull_up_12ma>;
> + };
> +
> + emmc_bus8: emmc-bus8 {
> + rockchip,pins =
> + <0 RK_PA7 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD4 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD5 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD6 2 &pcfg_pull_up_12ma>,
> + <2 RK_PD7 2 &pcfg_pull_up_12ma>,
> + <3 RK_PC0 2 &pcfg_pull_up_12ma>,
> + <3 RK_PC1 2 &pcfg_pull_up_12ma>,
> + <3 RK_PC2 2 &pcfg_pull_up_12ma>;
> + };
> + };
> +
> + pwm0 {
> + pwm0_pin: pwm0-pin {
> + rockchip,pins = <2 RK_PA4 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pwm1 {
> + pwm1_pin: pwm1-pin {
> + rockchip,pins = <2 RK_PA5 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pwm2 {
> + pwm2_pin: pwm2-pin {
> + rockchip,pins = <2 RK_PA6 1 &pcfg_pull_none>;
> + };
> + };
> +
> + pwmir {
> + pwmir_pin: pwmir-pin {
> + rockchip,pins = <2 RK_PA2 1 &pcfg_pull_none>;
> + };
> + };
> +
> + gmac-1 {
> + rgmiim1_pins: rgmiim1-pins {
> + rockchip,pins =
> + /* mac_txclk */
> + <1 RK_PB4 2 &pcfg_pull_none_12ma>,
> + /* mac_rxclk */
> + <1 RK_PB5 2 &pcfg_pull_none_2ma>,
> + /* mac_mdio */
> + <1 RK_PC3 2 &pcfg_pull_none_2ma>,
> + /* mac_txen */
> + <1 RK_PD1 2 &pcfg_pull_none_12ma>,
> + /* mac_clk */
> + <1 RK_PC5 2 &pcfg_pull_none_2ma>,
> + /* mac_rxdv */
> + <1 RK_PC6 2 &pcfg_pull_none_2ma>,
> + /* mac_mdc */
> + <1 RK_PC7 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd1 */
> + <1 RK_PB2 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd0 */
> + <1 RK_PB3 2 &pcfg_pull_none_2ma>,
> + /* mac_txd1 */
> + <1 RK_PB0 2 &pcfg_pull_none_12ma>,
> + /* mac_txd0 */
> + <1 RK_PB1 2 &pcfg_pull_none_12ma>,
> + /* mac_rxd3 */
> + <1 RK_PB6 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd2 */
> + <1 RK_PB7 2 &pcfg_pull_none_2ma>,
> + /* mac_txd3 */
> + <1 RK_PC0 2 &pcfg_pull_none_12ma>,
> + /* mac_txd2 */
> + <1 RK_PC1 2 &pcfg_pull_none_12ma>,
> +
> + /* mac_txclk */
> + <0 RK_PB0 1 &pcfg_pull_none>,
> + /* mac_txen */
> + <0 RK_PB4 1 &pcfg_pull_none>,
> + /* mac_clk */
> + <0 RK_PD0 1 &pcfg_pull_none>,
> + /* mac_txd1 */
> + <0 RK_PC0 1 &pcfg_pull_none>,
> + /* mac_txd0 */
> + <0 RK_PC1 1 &pcfg_pull_none>,
> + /* mac_txd3 */
> + <0 RK_PC7 1 &pcfg_pull_none>,
> + /* mac_txd2 */
> + <0 RK_PC6 1 &pcfg_pull_none>;
> + };
> +
> + rmiim1_pins: rmiim1-pins {
> + rockchip,pins =
> + /* mac_mdio */
> + <1 RK_PC3 2 &pcfg_pull_none_2ma>,
> + /* mac_txen */
> + <1 RK_PD1 2 &pcfg_pull_none_12ma>,
> + /* mac_clk */
> + <1 RK_PC5 2 &pcfg_pull_none_2ma>,
> + /* mac_rxer */
> + <1 RK_PD0 2 &pcfg_pull_none_2ma>,
> + /* mac_rxdv */
> + <1 RK_PC6 2 &pcfg_pull_none_2ma>,
> + /* mac_mdc */
> + <1 RK_PC7 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd1 */
> + <1 RK_PB2 2 &pcfg_pull_none_2ma>,
> + /* mac_rxd0 */
> + <1 RK_PB3 2 &pcfg_pull_none_2ma>,
> + /* mac_txd1 */
> + <1 RK_PB0 2 &pcfg_pull_none_12ma>,
> + /* mac_txd0 */
> + <1 RK_PB1 2 &pcfg_pull_none_12ma>,
> +
> + /* mac_mdio */
> + <0 RK_PB3 1 &pcfg_pull_none>,
> + /* mac_txen */
> + <0 RK_PB4 1 &pcfg_pull_none>,
> + /* mac_clk */
> + <0 RK_PD0 1 &pcfg_pull_none>,
> + /* mac_mdc */
> + <0 RK_PC3 1 &pcfg_pull_none>,
> + /* mac_txd1 */
> + <0 RK_PC0 1 &pcfg_pull_none>,
> + /* mac_txd0 */
> + <0 RK_PC1 1 &pcfg_pull_none>;
> + };
> + };
> +
> + gmac2phy {
> + fephyled_speed100: fephyled-speed100 {
> + rockchip,pins = <0 RK_PD7 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_speed10: fephyled-speed10 {
> + rockchip,pins = <0 RK_PD6 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_duplex: fephyled-duplex {
> + rockchip,pins = <0 RK_PD6 2 &pcfg_pull_none>;
> + };
> +
> + fephyled_rxm0: fephyled-rxm0 {
> + rockchip,pins = <0 RK_PD5 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_txm0: fephyled-txm0 {
> + rockchip,pins = <0 RK_PD5 2 &pcfg_pull_none>;
> + };
> +
> + fephyled_linkm0: fephyled-linkm0 {
> + rockchip,pins = <0 RK_PD4 1 &pcfg_pull_none>;
> + };
> +
> + fephyled_rxm1: fephyled-rxm1 {
> + rockchip,pins = <2 RK_PD1 2 &pcfg_pull_none>;
> + };
> +
> + fephyled_txm1: fephyled-txm1 {
> + rockchip,pins = <2 RK_PD1 3 &pcfg_pull_none>;
> + };
> +
> + fephyled_linkm1: fephyled-linkm1 {
> + rockchip,pins = <2 RK_PD0 2 &pcfg_pull_none>;
> + };
> + };
> +
> + tsadc_pin {
> + tsadc_int: tsadc-int {
> + rockchip,pins = <2 RK_PB5 2 &pcfg_pull_none>;
> + };
> + tsadc_gpio: tsadc-gpio {
> + rockchip,pins =
> + <2 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + hdmi_pin {
> + hdmi_cec: hdmi-cec {
> + rockchip,pins = <0 RK_PA3 1 &pcfg_pull_none>;
> + };
> +
> + hdmi_hpd: hdmi-hpd {
> + rockchip,pins = <0 RK_PA4 1 &pcfg_pull_down>;
> + };
> + };
> +
> + cif-0 {
> + dvp_d2d9_m0:dvp-d2d9-m0 {
> + rockchip,pins =
> + /* cif_d0 */
> + <3 RK_PA4 2 &pcfg_pull_none>,
> + /* cif_d1 */
> + <3 RK_PA5 2 &pcfg_pull_none>,
> + /* cif_d2 */
> + <3 RK_PA6 2 &pcfg_pull_none>,
> + /* cif_d3 */
> + <3 RK_PA7 2 &pcfg_pull_none>,
> + /* cif_d4 */
> + <3 RK_PB0 2 &pcfg_pull_none>,
> + /* cif_d5m0 */
> + <3 RK_PB1 2 &pcfg_pull_none>,
> + /* cif_d6m0 */
> + <3 RK_PB2 2 &pcfg_pull_none>,
> + /* cif_d7m0 */
> + <3 RK_PB3 2 &pcfg_pull_none>,
> + /* cif_href */
> + <3 RK_PA1 2 &pcfg_pull_none>,
> + /* cif_vsync */
> + <3 RK_PA0 2 &pcfg_pull_none>,
> + /* cif_clkoutm0 */
> + <3 RK_PA3 2 &pcfg_pull_none>,
> + /* cif_clkin */
> + <3 RK_PA2 2 &pcfg_pull_none>;
> + };
> + };
> +
> + cif-1 {
> + dvp_d2d9_m1:dvp-d2d9-m1 {
> + rockchip,pins =
> + /* cif_d0 */
> + <3 RK_PA4 2 &pcfg_pull_none>,
> + /* cif_d1 */
> + <3 RK_PA5 2 &pcfg_pull_none>,
> + /* cif_d2 */
> + <3 RK_PA6 2 &pcfg_pull_none>,
> + /* cif_d3 */
> + <3 RK_PA7 2 &pcfg_pull_none>,
> + /* cif_d4 */
> + <3 RK_PB0 2 &pcfg_pull_none>,
> + /* cif_d5m1 */
> + <2 RK_PC0 4 &pcfg_pull_none>,
> + /* cif_d6m1 */
> + <2 RK_PC1 4 &pcfg_pull_none>,
> + /* cif_d7m1 */
> + <2 RK_PC2 4 &pcfg_pull_none>,
> + /* cif_href */
> + <3 RK_PA1 2 &pcfg_pull_none>,
> + /* cif_vsync */
> + <3 RK_PA0 2 &pcfg_pull_none>,
> + /* cif_clkoutm1 */
> + <2 RK_PB7 4 &pcfg_pull_none>,
> + /* cif_clkin */
> + <3 RK_PA2 2 &pcfg_pull_none>;
> + };
> + };
> + };
> +};
>
^ permalink raw reply
* Re: [PATCH v3 00/37] mtd: nand: denali: 2nd round of Denali NAND IP patch bomb
From: Boris Brezillon @ 2017-03-31 8:27 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Enrico Jorns, Artem Bityutskiy, Dinh Nguyen,
Marek Vasut, Graham Moore, David Woodhouse, Masami Hiramatsu,
Chuanxiao Dong, Jassi Brar, devicetree, Linux Kernel Mailing List,
Brian Norris, Richard Weinberger, Cyrille Pitchen, Rob Herring,
Mark Rutland
In-Reply-To: <CAK7LNATUyc821uQTECkkQj2SDKkbrioFfHVsttnsnc8QuT1P-A@mail.gmail.com>
On Fri, 31 Mar 2017 13:05:20 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> Hi Boris,
>
>
> 2017-03-31 1:38 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
>
> > The rest looks almost good, except for a few comments I had on patch
> > 14, 18, 25, 26 and 32.
> >
> > I'll probably apply 33 and 34 soon.
> >
>
> Thank you!
> Please note I left a minor comment on 34.
> (Accidental addition of braces.)
Yep, I noticed. Applied both after fixing the alignment and removing
unneeded braces in patch 34.
Thanks,
Boris
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox