* [PATCH 0/5] arm64: dts: hisi: add NIC, RoCE and SAS support for hip07
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
arnd-r2nGTMty4D4
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q,
liudongdong3-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA,
majun258-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
guohanjun-hv44wF8Li93QT0dZR+AlfA, linuxarm-hv44wF8Li93QT0dZR+AlfA,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q, yimin-hv44wF8Li93QT0dZR+AlfA,
chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaofei-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
huangdaode-C8/M+/jPZTeaMJb+Lgu22Q,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
This patch series adds Mbigen, NIC, RoCE and SAS nodes for the hip07
SoC and enables the NIC, RoCE and SAS on the hip07 d05 board.
Wei Xu (5):
arm64: dts: hisi: add mbigen nodes for the hip07 SoC
arm64: dts: hisi: add network related nodes for the hip07 SoC
arm64: dts: hisi: add RoCE nodes for the hip07 SoC
arm64: dts: hisi: add SAS nodes for the hip07 SoC
arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board
arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 ++
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 479 ++++++++++++++++++++++++++++
2 files changed, 503 insertions(+)
--
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
* [PATCH 1/5] arm64: dts: hisi: add mbigen nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
arnd-r2nGTMty4D4
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q,
liudongdong3-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA,
majun258-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
guohanjun-hv44wF8Li93QT0dZR+AlfA, linuxarm-hv44wF8Li93QT0dZR+AlfA,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q, yimin-hv44wF8Li93QT0dZR+AlfA,
chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaofei-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
huangdaode-C8/M+/jPZTeaMJb+Lgu22Q,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
From: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Add mbigen nodes for the hip07 SoC those will be used
for the SAS, XGE and PCIe host controllers.
Signed-off-by: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 61 ++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 5144eb1..6077def 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1014,6 +1014,34 @@
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xa0080000 0x0 0x10000>;
+ mbigen_pcie2_a: intc_pcie2_a {
+ msi-parent = <&p0_its_dsa_a 0x40087>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <10>;
+ };
+
+ mbigen_sas1: intc_sas1 {
+ msi-parent = <&p0_its_dsa_a 0x40000>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <128>;
+ };
+
+ mbigen_sas2: intc_sas2 {
+ msi-parent = <&p0_its_dsa_a 0x40040>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <128>;
+ };
+
+ mbigen_smmu_pcie: intc_smmu_pcie {
+ msi-parent = <&p0_its_dsa_a 0x40b0c>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <3>;
+ };
+
mbigen_usb: intc_usb {
msi-parent = <&p0_its_dsa_a 0x40080>;
interrupt-controller;
@@ -1022,6 +1050,39 @@
};
};
+ p0_mbigen_dsa_a: interrupt-controller@c0080000 {
+ compatible = "hisilicon,mbigen-v2";
+ reg = <0x0 0xc0080000 0x0 0x10000>;
+
+ mbigen_dsaf0: intc_dsaf0 {
+ msi-parent = <&p0_its_dsa_a 0x40800>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <409>;
+ };
+
+ mbigen_dsa_roce: intc-roce {
+ msi-parent = <&p0_its_dsa_a 0x40B1E>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <34>;
+ };
+
+ mbigen_sas0: intc-sas0 {
+ msi-parent = <&p0_its_dsa_a 0x40900>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <128>;
+ };
+
+ mbigen_smmu_dsa: intc_smmu_dsa {
+ msi-parent = <&p0_its_dsa_a 0x40b20>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ num-pins = <3>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
--
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
* [PATCH 2/5] arm64: dts: hisi: add network related nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, xuwei5, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
From: Wei Xu <xuwei5@hisilicon.com>
Add MDIO, SerDes, Port and realted HNS nodes to support the
network on the hip07 SoC.
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 208 +++++++++++++++++++++++++++++++
1 file changed, 208 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 6077def..2feb362 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1116,5 +1116,213 @@
dma-coherent;
status = "disabled";
};
+
+ peri_c_subctrl: sub_ctrl_c@60000000 {
+ compatible = "hisilicon,peri-subctrl","syscon";
+ reg = <0 0x60000000 0x0 0x10000>;
+ };
+
+ dsa_subctrl: dsa_subctrl@c0000000 {
+ compatible = "hisilicon,dsa-subctrl", "syscon";
+ reg = <0x0 0xc0000000 0x0 0x10000>;
+ };
+
+ serdes_ctrl: sds_ctrl@c2200000 {
+ compatible = "syscon";
+ reg = <0 0xc2200000 0x0 0x80000>;
+ };
+
+ mdio@603c0000 {
+ compatible = "hisilicon,hns-mdio";
+ reg = <0x0 0x603c0000 0x0 0x1000>;
+ subctrl-vbase = <&peri_c_subctrl 0x338 0xa38
+ 0x531c 0x5a1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+
+ phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ };
+ };
+
+ dsaf0: dsa@c7000000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "hisilicon,hns-dsaf-v2";
+ mode = "6port-16rss";
+ reg = <0x0 0xc5000000 0x0 0x890000
+ 0x0 0xc7000000 0x0 0x600000>;
+ reg-names = "ppe-base", "dsaf-base";
+ interrupt-parent = <&mbigen_dsaf0>;
+ subctrl-syscon = <&dsa_subctrl>;
+ reset-field-offset = <0>;
+ interrupts =
+ <576 1>, <577 1>, <578 1>, <579 1>, <580 1>,
+ <581 1>, <582 1>, <583 1>, <584 1>, <585 1>,
+ <586 1>, <587 1>, <588 1>, <589 1>, <590 1>,
+ <591 1>, <592 1>, <593 1>, <594 1>, <595 1>,
+ <596 1>, <597 1>, <598 1>, <599 1>, <600 1>,
+ <960 1>, <961 1>, <962 1>, <963 1>, <964 1>,
+ <965 1>, <966 1>, <967 1>, <968 1>, <969 1>,
+ <970 1>, <971 1>, <972 1>, <973 1>, <974 1>,
+ <975 1>, <976 1>, <977 1>, <978 1>, <979 1>,
+ <980 1>, <981 1>, <982 1>, <983 1>, <984 1>,
+ <985 1>, <986 1>, <987 1>, <988 1>, <989 1>,
+ <990 1>, <991 1>, <992 1>, <993 1>, <994 1>,
+ <995 1>, <996 1>, <997 1>, <998 1>, <999 1>,
+ <1000 1>, <1001 1>, <1002 1>, <1003 1>, <1004 1>,
+ <1005 1>, <1006 1>, <1007 1>, <1008 1>, <1009 1>,
+ <1010 1>, <1011 1>, <1012 1>, <1013 1>, <1014 1>,
+ <1015 1>, <1016 1>, <1017 1>, <1018 1>, <1019 1>,
+ <1020 1>, <1021 1>, <1022 1>, <1023 1>, <1024 1>,
+ <1025 1>, <1026 1>, <1027 1>, <1028 1>, <1029 1>,
+ <1030 1>, <1031 1>, <1032 1>, <1033 1>, <1034 1>,
+ <1035 1>, <1036 1>, <1037 1>, <1038 1>, <1039 1>,
+ <1040 1>, <1041 1>, <1042 1>, <1043 1>, <1044 1>,
+ <1045 1>, <1046 1>, <1047 1>, <1048 1>, <1049 1>,
+ <1050 1>, <1051 1>, <1052 1>, <1053 1>, <1054 1>,
+ <1055 1>, <1056 1>, <1057 1>, <1058 1>, <1059 1>,
+ <1060 1>, <1061 1>, <1062 1>, <1063 1>, <1064 1>,
+ <1065 1>, <1066 1>, <1067 1>, <1068 1>, <1069 1>,
+ <1070 1>, <1071 1>, <1072 1>, <1073 1>, <1074 1>,
+ <1075 1>, <1076 1>, <1077 1>, <1078 1>, <1079 1>,
+ <1080 1>, <1081 1>, <1082 1>, <1083 1>, <1084 1>,
+ <1085 1>, <1086 1>, <1087 1>, <1088 1>, <1089 1>,
+ <1090 1>, <1091 1>, <1092 1>, <1093 1>, <1094 1>,
+ <1095 1>, <1096 1>, <1097 1>, <1098 1>, <1099 1>,
+ <1100 1>, <1101 1>, <1102 1>, <1103 1>, <1104 1>,
+ <1105 1>, <1106 1>, <1107 1>, <1108 1>, <1109 1>,
+ <1110 1>, <1111 1>, <1112 1>, <1113 1>, <1114 1>,
+ <1115 1>, <1116 1>, <1117 1>, <1118 1>, <1119 1>,
+ <1120 1>, <1121 1>, <1122 1>, <1123 1>, <1124 1>,
+ <1125 1>, <1126 1>, <1127 1>, <1128 1>, <1129 1>,
+ <1130 1>, <1131 1>, <1132 1>, <1133 1>, <1134 1>,
+ <1135 1>, <1136 1>, <1137 1>, <1138 1>, <1139 1>,
+ <1140 1>, <1141 1>, <1142 1>, <1143 1>, <1144 1>,
+ <1145 1>, <1146 1>, <1147 1>, <1148 1>, <1149 1>,
+ <1150 1>, <1151 1>, <1152 1>, <1153 1>, <1154 1>,
+ <1155 1>, <1156 1>, <1157 1>, <1158 1>, <1159 1>,
+ <1160 1>, <1161 1>, <1162 1>, <1163 1>, <1164 1>,
+ <1165 1>, <1166 1>, <1167 1>, <1168 1>, <1169 1>,
+ <1170 1>, <1171 1>, <1172 1>, <1173 1>, <1174 1>,
+ <1175 1>, <1176 1>, <1177 1>, <1178 1>, <1179 1>,
+ <1180 1>, <1181 1>, <1182 1>, <1183 1>, <1184 1>,
+ <1185 1>, <1186 1>, <1187 1>, <1188 1>, <1189 1>,
+ <1190 1>, <1191 1>, <1192 1>, <1193 1>, <1194 1>,
+ <1195 1>, <1196 1>, <1197 1>, <1198 1>, <1199 1>,
+ <1200 1>, <1201 1>, <1202 1>, <1203 1>, <1204 1>,
+ <1205 1>, <1206 1>, <1207 1>, <1208 1>, <1209 1>,
+ <1210 1>, <1211 1>, <1212 1>, <1213 1>, <1214 1>,
+ <1215 1>, <1216 1>, <1217 1>, <1218 1>, <1219 1>,
+ <1220 1>, <1221 1>, <1222 1>, <1223 1>, <1224 1>,
+ <1225 1>, <1226 1>, <1227 1>, <1228 1>, <1229 1>,
+ <1230 1>, <1231 1>, <1232 1>, <1233 1>, <1234 1>,
+ <1235 1>, <1236 1>, <1237 1>, <1238 1>, <1239 1>,
+ <1240 1>, <1241 1>, <1242 1>, <1243 1>, <1244 1>,
+ <1245 1>, <1246 1>, <1247 1>, <1248 1>, <1249 1>,
+ <1250 1>, <1251 1>, <1252 1>, <1253 1>, <1254 1>,
+ <1255 1>, <1256 1>, <1257 1>, <1258 1>, <1259 1>,
+ <1260 1>, <1261 1>, <1262 1>, <1263 1>, <1264 1>,
+ <1265 1>, <1266 1>, <1267 1>, <1268 1>, <1269 1>,
+ <1270 1>, <1271 1>, <1272 1>, <1273 1>, <1274 1>,
+ <1275 1>, <1276 1>, <1277 1>, <1278 1>, <1279 1>,
+ <1280 1>, <1281 1>, <1282 1>, <1283 1>, <1284 1>,
+ <1285 1>, <1286 1>, <1287 1>, <1288 1>, <1289 1>,
+ <1290 1>, <1291 1>, <1292 1>, <1293 1>, <1294 1>,
+ <1295 1>, <1296 1>, <1297 1>, <1298 1>, <1299 1>,
+ <1300 1>, <1301 1>, <1302 1>, <1303 1>, <1304 1>,
+ <1305 1>, <1306 1>, <1307 1>, <1308 1>, <1309 1>,
+ <1310 1>, <1311 1>, <1312 1>, <1313 1>, <1314 1>,
+ <1315 1>, <1316 1>, <1317 1>, <1318 1>, <1319 1>,
+ <1320 1>, <1321 1>, <1322 1>, <1323 1>, <1324 1>,
+ <1325 1>, <1326 1>, <1327 1>, <1328 1>, <1329 1>,
+ <1330 1>, <1331 1>, <1332 1>, <1333 1>, <1334 1>,
+ <1335 1>, <1336 1>, <1337 1>, <1338 1>, <1339 1>,
+ <1340 1>, <1341 1>, <1342 1>, <1343 1>;
+
+ desc-num = <0x400>;
+ buf-size = <0x1000>;
+ dma-coherent;
+
+ port@0 {
+ reg = <0>;
+ serdes-syscon = <&serdes_ctrl>;
+ port-rst-offset = <0>;
+ port-mode-offset = <0>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "fiber";
+ };
+
+ port@1 {
+ reg = <1>;
+ serdes-syscon= <&serdes_ctrl>;
+ port-rst-offset = <1>;
+ port-mode-offset = <1>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "fiber";
+ };
+
+ port@4 {
+ reg = <4>;
+ phy-handle = <&phy0>;
+ serdes-syscon= <&serdes_ctrl>;
+ port-rst-offset = <4>;
+ port-mode-offset = <2>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "copper";
+ };
+
+ port@5 {
+ reg = <5>;
+ phy-handle = <&phy1>;
+ serdes-syscon= <&serdes_ctrl>;
+ port-rst-offset = <5>;
+ port-mode-offset = <3>;
+ mc-mac-mask = [ff f0 00 00 00 00];
+ media-type = "copper";
+ };
+ };
+
+ eth0: ethernet@4{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <4>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth1: ethernet@5{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <5>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth2: ethernet@0{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <0>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
+
+ eth3: ethernet@1{
+ compatible = "hisilicon,hns-nic-v2";
+ ae-handle = <&dsaf0>;
+ port-idx-in-ae = <1>;
+ local-mac-address = [00 00 00 00 00 00];
+ status = "disabled";
+ dma-coherent;
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: hisi: add RoCE nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
arnd-r2nGTMty4D4
Cc: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q,
liudongdong3-hv44wF8Li93QT0dZR+AlfA,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA,
majun258-hv44wF8Li93QT0dZR+AlfA,
wangkefeng.wang-hv44wF8Li93QT0dZR+AlfA,
guohanjun-hv44wF8Li93QT0dZR+AlfA, linuxarm-hv44wF8Li93QT0dZR+AlfA,
liguozhu-C8/M+/jPZTeaMJb+Lgu22Q, yimin-hv44wF8Li93QT0dZR+AlfA,
chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q,
tanxiaofei-hv44wF8Li93QT0dZR+AlfA,
lipeng321-hv44wF8Li93QT0dZR+AlfA,
yankejian-hv44wF8Li93QT0dZR+AlfA,
huangdaode-C8/M+/jPZTeaMJb+Lgu22Q,
charles.chenxin-hv44wF8Li93QT0dZR+AlfA,
shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
From: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
Add the infiniband node to support the RoCE function
on the hip07 SoC.
Signed-off-by: Wei Xu <xuwei5-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 81 ++++++++++++++++++++++++++++++++
1 file changed, 81 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2feb362..bc54b61 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1324,5 +1324,86 @@
status = "disabled";
dma-coherent;
};
+
+ infiniband@c4000000 {
+ compatible = "hisilicon,hns-roce-v1";
+ reg = <0x0 0xc4000000 0x0 0x100000>;
+ dma-coherent;
+ eth-handle = <ð2 ð3 0 0 ð0 ð1>;
+ dsaf-handle = <&dsaf0>;
+ node-guid = [00 9A CD 00 00 01 02 03];
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mbigen_dsa_roce>;
+ interrupts = <722 1>,
+ <723 1>,
+ <724 1>,
+ <725 1>,
+ <726 1>,
+ <727 1>,
+ <728 1>,
+ <729 1>,
+ <730 1>,
+ <731 1>,
+ <732 1>,
+ <733 1>,
+ <734 1>,
+ <735 1>,
+ <736 1>,
+ <737 1>,
+ <738 1>,
+ <739 1>,
+ <740 1>,
+ <741 1>,
+ <742 1>,
+ <743 1>,
+ <744 1>,
+ <745 1>,
+ <746 1>,
+ <747 1>,
+ <748 1>,
+ <749 1>,
+ <750 1>,
+ <751 1>,
+ <752 1>,
+ <753 1>,
+ <785 1>,
+ <754 4>;
+
+ interrupt-names = "hns-roce-comp-0",
+ "hns-roce-comp-1",
+ "hns-roce-comp-2",
+ "hns-roce-comp-3",
+ "hns-roce-comp-4",
+ "hns-roce-comp-5",
+ "hns-roce-comp-6",
+ "hns-roce-comp-7",
+ "hns-roce-comp-8",
+ "hns-roce-comp-9",
+ "hns-roce-comp-10",
+ "hns-roce-comp-11",
+ "hns-roce-comp-12",
+ "hns-roce-comp-13",
+ "hns-roce-comp-14",
+ "hns-roce-comp-15",
+ "hns-roce-comp-16",
+ "hns-roce-comp-17",
+ "hns-roce-comp-18",
+ "hns-roce-comp-19",
+ "hns-roce-comp-20",
+ "hns-roce-comp-21",
+ "hns-roce-comp-22",
+ "hns-roce-comp-23",
+ "hns-roce-comp-24",
+ "hns-roce-comp-25",
+ "hns-roce-comp-26",
+ "hns-roce-comp-27",
+ "hns-roce-comp-28",
+ "hns-roce-comp-29",
+ "hns-roce-comp-30",
+ "hns-roce-comp-31",
+ "hns-roce-async",
+ "hns-roce-common";
+ };
};
};
--
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
* [PATCH 4/5] arm64: dts: hisi: add SAS nodes for the hip07 SoC
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, xuwei5, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
From: Wei Xu <xuwei5@hisilicon.com>
Add 3 SAS host controller nodes and the dependent subctrl node
to enable the SAS and SATA function for the hip07 SoC.
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip07.dtsi | 129 +++++++++++++++++++++++++++++++
1 file changed, 129 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index bc54b61..9512f3a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1127,6 +1127,11 @@
reg = <0x0 0xc0000000 0x0 0x10000>;
};
+ pcie_subctl: pcie_subctl@a0000000 {
+ compatible = "hisilicon,pcie-sas-subctrl", "syscon";
+ reg = <0x0 0xa0000000 0x0 0x10000>;
+ };
+
serdes_ctrl: sds_ctrl@c2200000 {
compatible = "syscon";
reg = <0 0xc2200000 0x0 0x80000>;
@@ -1405,5 +1410,129 @@
"hns-roce-async",
"hns-roce-common";
};
+
+ sas0: sas@c3000000 {
+ compatible = "hisilicon,hip07-sas-v2";
+ reg = <0 0xc3000000 0 0x10000>;
+ sas-addr = [50 01 88 20 16 00 00 00];
+ hisilicon,sas-syscon = <&dsa_subctrl>;
+ ctrl-reset-reg = <0xa60>;
+ ctrl-reset-sts-reg = <0x5a30>;
+ ctrl-clock-ena-reg = <0x338>;
+ queue-count = <16>;
+ phy-count = <8>;
+ dma-coherent;
+ interrupt-parent = <&mbigen_sas0>;
+ interrupts = <64 4>,<65 4>,<66 4>,<67 4>,<68 4>,
+ <69 4>,<70 4>,<71 4>,<72 4>,<73 4>,
+ <74 4>,<75 4>,<76 4>,<77 4>,<78 4>,
+ <79 4>,<80 4>,<81 4>,<82 4>,<83 4>,
+ <84 4>,<85 4>,<86 4>,<87 4>,<88 4>,
+ <89 4>,<90 4>,<91 4>,<92 4>,<93 4>,
+ <94 4>,<95 4>,<96 4>,<97 4>,<98 4>,
+ <99 4>,<100 4>,<101 4>,<102 4>,<103 4>,
+ <104 4>,<105 4>,<106 4>,<107 4>,<108 4>,
+ <109 4>,<110 4>,<111 4>,<112 4>,<113 4>,
+ <114 4>,<115 4>,<116 4>,<117 4>,<118 4>,
+ <119 4>,<120 4>,<121 4>,<122 4>,<123 4>,
+ <124 4>,<125 4>,<126 4>,<127 4>,<128 4>,
+ <129 4>,<130 4>,<131 4>,<132 4>,<133 4>,
+ <134 4>,<135 4>,<136 4>,<137 4>,<138 4>,
+ <139 4>,<140 4>,<141 4>,<142 4>,<143 4>,
+ <144 4>,<145 4>,<146 4>,<147 4>,<148 4>,
+ <149 4>,<150 4>,<151 4>,<152 4>,<153 4>,
+ <154 4>,<155 4>,<156 4>,<157 4>,<158 4>,
+ <159 4>,<601 1>,<602 1>,<603 1>,<604 1>,
+ <605 1>,<606 1>,<607 1>,<608 1>,<609 1>,
+ <610 1>,<611 1>,<612 1>,<613 1>,<614 1>,
+ <615 1>,<616 1>,<617 1>,<618 1>,<619 1>,
+ <620 1>,<621 1>,<622 1>,<623 1>,<624 1>,
+ <625 1>,<626 1>,<627 1>,<628 1>,<629 1>,
+ <630 1>,<631 1>,<632 1>;
+ status = "disabled";
+ };
+
+ sas1: sas@a2000000 {
+ compatible = "hisilicon,hip07-sas-v2";
+ reg = <0 0xa2000000 0 0x10000>;
+ sas-addr = [50 01 88 20 16 00 00 00];
+ hisilicon,sas-syscon = <&pcie_subctl>;
+ hip06-sas-v2-quirk-amt;
+ ctrl-reset-reg = <0xa18>;
+ ctrl-reset-sts-reg = <0x5a0c>;
+ ctrl-clock-ena-reg = <0x318>;
+ queue-count = <16>;
+ phy-count = <8>;
+ dma-coherent;
+ interrupt-parent = <&mbigen_sas1>;
+ interrupts = <64 4>,<65 4>,<66 4>,<67 4>,<68 4>,
+ <69 4>,<70 4>,<71 4>,<72 4>,<73 4>,
+ <74 4>,<75 4>,<76 4>,<77 4>,<78 4>,
+ <79 4>,<80 4>,<81 4>,<82 4>,<83 4>,
+ <84 4>,<85 4>,<86 4>,<87 4>,<88 4>,
+ <89 4>,<90 4>,<91 4>,<92 4>,<93 4>,
+ <94 4>,<95 4>,<96 4>,<97 4>,<98 4>,
+ <99 4>,<100 4>,<101 4>,<102 4>,<103 4>,
+ <104 4>,<105 4>,<106 4>,<107 4>,<108 4>,
+ <109 4>,<110 4>,<111 4>,<112 4>,<113 4>,
+ <114 4>,<115 4>,<116 4>,<117 4>,<118 4>,
+ <119 4>,<120 4>,<121 4>,<122 4>,<123 4>,
+ <124 4>,<125 4>,<126 4>,<127 4>,<128 4>,
+ <129 4>,<130 4>,<131 4>,<132 4>,<133 4>,
+ <134 4>,<135 4>,<136 4>,<137 4>,<138 4>,
+ <139 4>,<140 4>,<141 4>,<142 4>,<143 4>,
+ <144 4>,<145 4>,<146 4>,<147 4>,<148 4>,
+ <149 4>,<150 4>,<151 4>,<152 4>,<153 4>,
+ <154 4>,<155 4>,<156 4>,<157 4>,<158 4>,
+ <159 4>,<576 1>,<577 1>,<578 1>,<579 1>,
+ <580 1>,<581 1>,<582 1>,<583 1>,<584 1>,
+ <585 1>,<586 1>,<587 1>,<588 1>,<589 1>,
+ <590 1>,<591 1>,<592 1>,<593 1>,<594 1>,
+ <595 1>,<596 1>,<597 1>,<598 1>,<599 1>,
+ <600 1>,<601 1>,<602 1>,<603 1>,<604 1>,
+ <605 1>,<606 1>,<607 1>;
+ status = "disabled";
+ };
+
+ sas2: sas@a3000000 {
+ compatible = "hisilicon,hip07-sas-v2";
+ reg = <0 0xa3000000 0 0x10000>;
+ sas-addr = [50 01 88 20 16 00 00 00];
+ hisilicon,sas-syscon = <&pcie_subctl>;
+ ctrl-reset-reg = <0xae0>;
+ ctrl-reset-sts-reg = <0x5a70>;
+ ctrl-clock-ena-reg = <0x3a8>;
+ queue-count = <16>;
+ phy-count = <9>;
+ dma-coherent;
+ interrupt-parent = <&mbigen_sas2>;
+ interrupts = <192 4>,<193 4>,<194 4>,<195 4>,<196 4>,
+ <197 4>,<198 4>,<199 4>,<200 4>,<201 4>,
+ <202 4>,<203 4>,<204 4>,<205 4>,<206 4>,
+ <207 4>,<208 4>,<209 4>,<210 4>,<211 4>,
+ <212 4>,<213 4>,<214 4>,<215 4>,<216 4>,
+ <217 4>,<218 4>,<219 4>,<220 4>,<221 4>,
+ <222 4>,<223 4>,<224 4>,<225 4>,<226 4>,
+ <227 4>,<228 4>,<229 4>,<230 4>,<231 4>,
+ <232 4>,<233 4>,<234 4>,<235 4>,<236 4>,
+ <237 4>,<238 4>,<239 4>,<240 4>,<241 4>,
+ <242 4>,<243 4>,<244 4>,<245 4>,<246 4>,
+ <247 4>,<248 4>,<249 4>,<250 4>,<251 4>,
+ <252 4>,<253 4>,<254 4>,<255 4>,<256 4>,
+ <257 4>,<258 4>,<259 4>,<260 4>,<261 4>,
+ <262 4>,<263 4>,<264 4>,<265 4>,<266 4>,
+ <267 4>,<268 4>,<269 4>,<270 4>,<271 4>,
+ <272 4>,<273 4>,<274 4>,<275 4>,<276 4>,
+ <277 4>,<278 4>,<279 4>,<280 4>,<281 4>,
+ <282 4>,<283 4>,<284 4>,<285 4>,<286 4>,
+ <287 4>,<608 1>,<609 1>,<610 1>,<611 1>,
+ <612 1>,<613 1>,<614 1>,<615 1>,<616 1>,
+ <617 1>,<618 1>,<619 1>,<620 1>,<621 1>,
+ <622 1>,<623 1>,<624 1>,<625 1>,<626 1>,
+ <627 1>,<628 1>,<629 1>,<630 1>,<631 1>,
+ <632 1>,<633 1>,<634 1>,<635 1>,<636 1>,
+ <637 1>,<638 1>,<639 1>;
+ status = "disabled";
+ };
};
};
--
1.9.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: hisi: enalbe the NIC and SAS for the hip07-d05 board
From: Wei.Xu @ 2017-04-07 2:07 UTC (permalink / raw)
To: robh+dt, mark.rutland, catalin.marinas, will.deacon, arnd
Cc: wangkefeng.wang, gabriele.paoloni, charles.chenxin, linuxarm,
guohanjun, yankejian, yimin, xuwei5, huangdaode, liudongdong3,
yisen.zhuang, devicetree, john.garry, tanxiaofei, lipeng321,
linux-arm-kernel, salil.mehta, chenxiang66, linux-kernel,
shameerali.kolothum.thodi, wangzhou1, liguozhu, majun258
In-Reply-To: <1491530876-109791-1-git-send-email-xuwei5@hisilicon.com>
From: Wei Xu <xuwei5@hisilicon.com>
Enalbe the NIC and SAS nodes for the hip07-d05 board
to support related functions.
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip07-d05.dts | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
index e058442..5bdca80 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip07-d05.dts
@@ -64,3 +64,27 @@
&usb_ehci {
status = "ok";
};
+
+ð0 {
+ status = "ok";
+};
+
+ð1 {
+ status = "ok";
+};
+
+ð2 {
+ status = "ok";
+};
+
+ð3 {
+ status = "ok";
+};
+
+&p0_pcie2_a {
+ status = "ok";
+};
+
+&sas1 {
+ status = "ok";
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed: add a fastread property
From: Joel Stanley @ 2017-04-07 2:10 UTC (permalink / raw)
To: Cédric Le Goater
Cc: Rob Herring, Mark Rutland, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
In-Reply-To: <1491498153-26564-1-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
On Fri, Apr 7, 2017 at 2:32 AM, Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org> wrote:
> All chips on OpenPOWER platforms support the fastread SPI command.
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
Thanks, applied.
Cheers,
Joel
> ---
> arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 ++
> arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 2 ++
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 2 ++
> 3 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-ast2500-evb.dts b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> index 8f82e8ab1875..7c90dac99822 100644
> --- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> @@ -24,6 +24,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "bmc";
> };
> };
> @@ -32,6 +33,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "pnor";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index aab1889f702f..112551766275 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -35,6 +35,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "bmc";
> };
> };
> @@ -43,6 +44,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "pnor";
> };
> };
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index e3c6358bc7d9..b82f67eb3dae 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -35,6 +35,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "bmc";
> };
> };
> @@ -43,6 +44,7 @@
> status = "okay";
> flash@0 {
> status = "okay";
> + m25p,fast-read;
> label = "pnor";
> };
> };
> --
> 2.7.4
>
--
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
* Device Tree Binding for Intel FPGA Video and Image Processing Suite
From: Ong, Hean Loong @ 2017-04-07 2:13 UTC (permalink / raw)
To: Rob Herring; +Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Hi Rob,
I am resubmitting the patch again since the last doesn't comply with
the rules of the community.
>From 23a9e274bb517b8e232c5aa4cf9737de1644b708 Mon Sep 17 00:00:00 2001
From: Ong, Hean Loong <hean.loong.ong-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
.../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
--
BR
Hean-Loong
--
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 4/4] drm: zte: add VGA driver support
From: Shawn Guo @ 2017-04-07 3:02 UTC (permalink / raw)
To: Sean Paul
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Daniel Vetter,
Baoyou Xie, Xin Zhou, Jun Nie, Shawn Guo
In-Reply-To: <20170406171251.qlzdjmzalunplbdt@art_vandelay>
On Thu, Apr 06, 2017 at 01:12:51PM -0400, Sean Paul wrote:
> On Thu, Apr 06, 2017 at 11:01:10PM +0800, Shawn Guo wrote:
> > +static int zx_vga_connector_get_modes(struct drm_connector *connector)
> > +{
> > + struct zx_vga *vga = to_zx_vga(connector);
> > + unsigned long flags;
> > + struct edid *edid;
> > + int ret;
> > +
> > + /*
> > + * Clear both detection bits to switch I2C bus from device
> > + * detecting to EDID reading.
> > + */
> > + spin_lock_irqsave(&vga->lock, flags);
> > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
> > + spin_unlock_irqrestore(&vga->lock, flags);
> > +
> > + edid = drm_get_edid(connector, &vga->ddc->adap);
> > + if (!edid)
> > + return 0;
> > +
> > + /*
> > + * As edid reading succeeds, device must be connected, so we set
> > + * up detection bit for unplug interrupt here.
> > + */
> > + spin_lock_irqsave(&vga->lock, flags);
> > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, VGA_DETECT_SEL_HAS_DEVICE);
> > + spin_unlock_irqrestore(&vga->lock, flags);
> > +
> > + drm_mode_connector_update_edid_property(connector, edid);
> > + ret = drm_add_edid_modes(connector, edid);
> > + kfree(edid);
> > +
> > + return ret;
> > +}
<snip>
> > +static irqreturn_t zx_vga_irq_handler(int irq, void *dev_id)
> > +{
> > + struct zx_vga *vga = dev_id;
> > + u32 status;
> > +
> > + status = zx_readl(vga->mmio + VGA_I2C_STATUS);
> > +
> > + /* Clear interrupt status */
> > + zx_writel_mask(vga->mmio + VGA_I2C_STATUS, VGA_CLEAR_IRQ,
> > + VGA_CLEAR_IRQ);
> > +
> > + if (status & VGA_DEVICE_CONNECTED) {
> > + /*
> > + * Since VGA_DETECT_SEL bits need to be reset for switching DDC
> > + * bus from device detection to EDID read, rather than setting
> > + * up HAS_DEVICE bit here, we need to do that in .get_modes
> > + * hook for unplug detecting after EDID read succeeds.
> > + */
> > + vga->connected = true;
> > + return IRQ_WAKE_THREAD;
> > + }
> > +
> > + if (status & VGA_DEVICE_DISCONNECTED) {
> > + spin_lock(&vga->lock);
> > + zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL,
> > + VGA_DETECT_SEL_NO_DEVICE);
> > + spin_unlock(&vga->lock);
>
> I think you still have the race here. If you get a disconnect between get_edid
> successfully finishing, and resetting the DETECT_SEL register, you will end up
> with the device being disconnected and DETECT_SEL == VGA_DETECT_SEL_HAS_DEVICE.
>
> In order to close this, you'll need to hold the lock across the edid read.
We cannot hold a spin lock across the EDID read procedure, which does
sleep.
When you suggested to have a lock for DETECT_SEL register access, I
thought we are accessing it in a read-modify-write way and thus agreed
to add a lock. However, I just found that it's not the case actually.
All the accesses to the register are single direct write.
And here is my understanding about the condition you described above.
Once DETECT_SEL register gets reset (both bits cleared), the hardware
switches DDC bus for EDID read, and hotplug detection will stop working
right away (this is how ZTE hardware works). That said, if we get a
disconnect before drm_get_edid() successfully finishes, two points:
- The irq handler will not be triggered, so it will not get a chance to
update DETECT_SEL register.
- The drm_get_edid() fails, and .get_modes returns with both detect bits
kept cleared.
I think what we can do better in this case is that we should set the
device state into disconnected, before returning from .get_modes,
something like the code below. But still, I do not see we need a lock
for that.
Shawn
static int zx_vga_connector_get_modes(struct drm_connector *connector)
{
struct zx_vga *vga = to_zx_vga(connector);
unsigned long flags;
struct edid *edid;
int ret;
/*
* Clear both detection bits to switch I2C bus from device
* detecting to EDID reading.
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, 0);
edid = drm_get_edid(connector, &vga->ddc->adap);
if (!edid) {
/*
* If EDID reading fails, we set the device state into
* disconnected.
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL,
VGA_DETECT_SEL_NO_DEVICE);
vga->connected = false;
return 0;
}
/*
* As edid reading succeeds, device must be connected, so we set
* up detection bit for unplug interrupt here.
*/
zx_writel(vga->mmio + VGA_AUTO_DETECT_SEL, VGA_DETECT_SEL_HAS_DEVICE);
drm_mode_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
return ret;
}
--
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 V10 06/12] of: device: Fix overflow of coherent_dma_mask
From: Sricharan R @ 2017-04-07 4:12 UTC (permalink / raw)
To: Frank Rowand, robin.murphy, will.deacon, joro, lorenzo.pieralisi,
iommu, linux-arm-kernel, linux-arm-msm, m.szyprowski, bhelgaas,
linux-pci, linux-acpi, tn, hanjun.guo, okaya, robh+dt, devicetree,
linux-kernel, sudeep.holla, rjw, lenb, catalin.marinas, arnd,
linux-arch, gregkh
In-Reply-To: <58E69831.6010306@gmail.com>
Hi Frank,
On 4/7/2017 1:04 AM, Frank Rowand wrote:
> On 04/06/17 04:01, Sricharan R wrote:
>> Hi Frank,
>>
>> On 4/6/2017 12:31 PM, Frank Rowand wrote:
>>> On 04/04/17 03:18, Sricharan R wrote:
>>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>>> and passed to arch_setup_dma_ops further. It overflows when
>>>> the coherent_dma_mask is set for full 64 bits 0xFFFFFFFFFFFFFFFF,
>>>> resulting in size getting passed as 0 wrongly. Fix this by
>>>> passsing in max(mask, mask + 1). Note that in this case
>>>> when the mask is set to full 64bits, we will be passing the mask
>>>> itself to arch_setup_dma_ops instead of the size. The real fix
>>>> for this should be to make arch_setup_dma_ops receive the
>>>> mask and handle it, to be done in the future.
>>>>
>>>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>>>> ---
>>>> drivers/of/device.c | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>>>> index c17c19d..c2ae6bb 100644
>>>> --- a/drivers/of/device.c
>>>> +++ b/drivers/of/device.c
>>>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>>>> if (ret < 0) {
>>>> dma_addr = offset = 0;
>>>> - size = dev->coherent_dma_mask + 1;
>>>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>>> } else {
>>>> offset = PFN_DOWN(paddr - dma_addr);
>>>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>>>>
>>>
>>> NACK.
>>>
>>> Passing an invalid size to arch_setup_dma_ops() is only part of the problem.
>>> size is also used in of_dma_configure() before calling arch_setup_dma_ops():
>>>
>>> dev->coherent_dma_mask = min(dev->coherent_dma_mask,
>>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>>> *dev->dma_mask = min((*dev->dma_mask),
>>> DMA_BIT_MASK(ilog2(dma_addr + size)));
>>>
>>> which would be incorrect for size == 0xffffffffffffffffULL when
>>> dma_addr != 0. So the proposed fix really is not papering over
>>> the base problem very well.
>>>
>>
>> Ok, but with your fix for of_dma_get_range and the above fix,
>> dma_addr will be '0' when size = 0xffffffffffffffffULL,
>> but DMA_BIT_MASK(ilog2(dma_addr + size)) would be wrong though,
>> making coherent_dma_mask to be smaller 0x7fffffffffffffffULL.
>
> Yes, that was my point. Setting size to 0x7fffffffffffffffULL
> affects several places. Another potential location (based only
> on the function header comment, not from reading the code) is
> iommu_dma_init_domain(). The header comment says:
>
> * @base and @size should be exact multiples of IOMMU page granularity to
> * avoid rounding surprises.
>
ok, this is the same problem that should get solved when arch_setup_dma_ops
is prepared to take mask instead of size. It would still work as said above
with a smaller mask than specified.
> I have not read enough context to really understand of_dma_configure(), but
> it seems there is yet another issue in how the error return case from
> of_dma_get_range() is handled (with the existing code, as well as if
> my patch gets accepted). An error return value can mean _either_
> there is no dma-ranges property _or_ "an other problem occurred". Should
> the "an other problem occurred" case be handled by defaulting size to
> a value based on dev->coherent_dma_mask (the current case) or should the
> attempt to set up the DMA configuration just fail?
The handling of return error value looks like separate item, but looks
like its correct with what is there now. (ie) when of_dma_get_range fails
either because 'dma-ranges property' populated in DT (or) because of some
erroneous DT setting, better to set the mask which the driver has specified
and ignore DT. So the above patch just corrects a mistake in that path.
Regards,
Sricharan
--
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH V5 2/2] thermal: broadcom: add Northstar thermal driver
From: Eduardo Valentin @ 2017-04-07 4:42 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Zhang Rui, Rob Herring, Mark Rutland, Stephen Warren, Lee Jones,
Eric Anholt, Florian Fainelli, Ray Jui, Scott Branden,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Rafał Miłecki, Jon Mason
In-Reply-To: <20170403154829.29780-2-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 7189 bytes --]
On Mon, Apr 03, 2017 at 05:48:29PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
>
> Northstar is a SoC family commonly used in home routers. This commit
> adds a driver for checking CPU temperature. As Northstar Plus seems to
> also have this IP block this new symbol gets ARCH_BCM_IPROC dependency.
>
> Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
If no objection, I am applying this series.
> ---
> V2: Make it iProc specific as NSP can also use this driver
> Select proper symbols in config ARCH_BCM_IPROC
> Define PVTMON register bits
> Update code selecting temperature monitor mode
> Thank you Jon!
> V3: More details in help message for BCM_NS_THERMAL
> Use slope & offset
> Drop arch code change (I'll be submitted using a proper tree)
> Thank you Eduardo!
> V4: Comment operations on PVTMON_CONTROL0 register
> ---
> drivers/thermal/Kconfig | 5 ++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/broadcom/Kconfig | 8 +++
> drivers/thermal/broadcom/Makefile | 1 +
> drivers/thermal/broadcom/ns-thermal.c | 105 ++++++++++++++++++++++++++++++++++
> 5 files changed, 120 insertions(+)
> create mode 100644 drivers/thermal/broadcom/Kconfig
> create mode 100644 drivers/thermal/broadcom/Makefile
> create mode 100644 drivers/thermal/broadcom/ns-thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 3bd24063375e..ac7301703d03 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -392,6 +392,11 @@ config MTK_THERMAL
> Enable this option if you want to have support for thermal management
> controller present in Mediatek SoCs
>
> +menu "Broadcom thermal drivers"
> +depends on ARCH_BCM || COMPILE_TEST
> +source "drivers/thermal/broadcom/Kconfig"
> +endmenu
> +
> menu "Texas Instruments thermal drivers"
> depends on ARCH_HAS_BANDGAP || COMPILE_TEST
> depends on HAS_IOMEM
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index f23cde05dac6..6b7706b9f27c 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -27,6 +27,7 @@ thermal_sys-$(CONFIG_CLOCK_THERMAL) += clock_cooling.o
> thermal_sys-$(CONFIG_DEVFREQ_THERMAL) += devfreq_cooling.o
>
> # platform thermal drivers
> +obj-y += broadcom/
> obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
> diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
> new file mode 100644
> index 000000000000..f0dea8a8e002
> --- /dev/null
> +++ b/drivers/thermal/broadcom/Kconfig
> @@ -0,0 +1,8 @@
> +config BCM_NS_THERMAL
> + tristate "Northstar thermal driver"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + help
> + Northstar is a family of SoCs that includes e.g. BCM4708, BCM47081,
> + BCM4709 and BCM47094. It contains DMU (Device Management Unit) block
> + with a thermal sensor that allows checking CPU temperature. This
> + driver provides support for it.
> diff --git a/drivers/thermal/broadcom/Makefile b/drivers/thermal/broadcom/Makefile
> new file mode 100644
> index 000000000000..059df9a0ed69
> --- /dev/null
> +++ b/drivers/thermal/broadcom/Makefile
> @@ -0,0 +1 @@
> +obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
> diff --git a/drivers/thermal/broadcom/ns-thermal.c b/drivers/thermal/broadcom/ns-thermal.c
> new file mode 100644
> index 000000000000..eab96b3572b9
> --- /dev/null
> +++ b/drivers/thermal/broadcom/ns-thermal.c
> @@ -0,0 +1,105 @@
> +/*
> + * Copyright (C) 2017 Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +#include <linux/thermal.h>
> +
> +#define PVTMON_CONTROL0 0x00
> +#define PVTMON_CONTROL0_SEL_MASK 0x0000000e
> +#define PVTMON_CONTROL0_SEL_TEMP_MONITOR 0x00000000
> +#define PVTMON_CONTROL0_SEL_TEST_MODE 0x0000000e
> +#define PVTMON_STATUS 0x08
> +
> +struct ns_thermal {
> + struct thermal_zone_device *tz;
> + void __iomem *pvtmon;
> +};
> +
> +static int ns_thermal_get_temp(void *data, int *temp)
> +{
> + struct ns_thermal *ns_thermal = data;
> + int offset = thermal_zone_get_offset(ns_thermal->tz);
> + int slope = thermal_zone_get_slope(ns_thermal->tz);
> + u32 val;
> +
> + val = readl(ns_thermal->pvtmon + PVTMON_CONTROL0);
> + if ((val & PVTMON_CONTROL0_SEL_MASK) != PVTMON_CONTROL0_SEL_TEMP_MONITOR) {
> + /* Clear current mode selection */
> + val &= ~PVTMON_CONTROL0_SEL_MASK;
> +
> + /* Set temp monitor mode (it's the default actually) */
> + val |= PVTMON_CONTROL0_SEL_TEMP_MONITOR;
> +
> + writel(val, ns_thermal->pvtmon + PVTMON_CONTROL0);
> + }
> +
> + val = readl(ns_thermal->pvtmon + PVTMON_STATUS);
> + *temp = slope * val + offset;
> +
> + return 0;
> +}
> +
> +const struct thermal_zone_of_device_ops ns_thermal_ops = {
minor correction here:
-const struct thermal_zone_of_device_ops ns_thermal_ops = {
+static const struct thermal_zone_of_device_ops ns_thermal_ops = {
but I am applying this already in my tree.
> + .get_temp = ns_thermal_get_temp,
> +};
> +
> +static int ns_thermal_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct ns_thermal *ns_thermal;
> +
> + ns_thermal = devm_kzalloc(dev, sizeof(*ns_thermal), GFP_KERNEL);
> + if (!ns_thermal)
> + return -ENOMEM;
> +
> + ns_thermal->pvtmon = of_iomap(dev_of_node(dev), 0);
> + if (WARN_ON(!ns_thermal->pvtmon))
> + return -ENOENT;
> +
> + ns_thermal->tz = devm_thermal_zone_of_sensor_register(dev, 0,
> + ns_thermal,
> + &ns_thermal_ops);
> + if (IS_ERR(ns_thermal->tz)) {
> + iounmap(ns_thermal->pvtmon);
> + return PTR_ERR(ns_thermal->tz);
> + }
> +
> + platform_set_drvdata(pdev, ns_thermal);
> +
> + return 0;
> +}
> +
> +static int ns_thermal_remove(struct platform_device *pdev)
> +{
> + struct ns_thermal *ns_thermal = platform_get_drvdata(pdev);
> +
> + iounmap(ns_thermal->pvtmon);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ns_thermal_of_match[] = {
> + { .compatible = "brcm,ns-thermal", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ns_thermal_of_match);
> +
> +static struct platform_driver ns_thermal_driver = {
> + .probe = ns_thermal_probe,
> + .remove = ns_thermal_remove,
> + .driver = {
> + .name = "ns-thermal",
> + .of_match_table = ns_thermal_of_match,
> + },
> +};
> +module_platform_driver(ns_thermal_driver);
> +
> +MODULE_DESCRIPTION("Northstar thermal driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.11.0
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH V7 0/7] da9061: DA9061 driver submission
From: Eduardo Valentin @ 2017-04-07 4:51 UTC (permalink / raw)
To: Steve Twiss
Cc: DEVICETREE, Dmitry Torokhov, Guenter Roeck, LINUX-INPUT,
LINUX-KERNEL, LINUX-PM, LINUX-WATCHDOG, Lee Jones, Liam Girdwood,
Lukasz Luba, Mark Brown, Mark Rutland, Rob Herring,
Wim Van Sebroeck, Zhang Rui, Support Opensource
In-Reply-To: <cover.1490712213.git.stwiss.opensource@diasemi.com>
[-- Attachment #1: Type: text/plain, Size: 461 bytes --]
Hey,
On Tue, Mar 28, 2017 at 03:43:33PM +0100, Steve Twiss wrote:
> From: Steve Twiss <stwiss.opensource@diasemi.com>
>
> This patch set adds support for the Dialog DA9061 Power Management IC.
> Support is made by altering the existing DA9062 device driver, where
> appropriate.
>
> Hello,
>
> Previously, there were only minor changes for v6.
> The patch v7 introduces a compile test for x86 64-bit.
>
Applied patches 2 and 7 on my tree.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] of: change fixup of dma-ranges size to error
From: Frank Rowand @ 2017-04-07 5:18 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAL_Jsq+VreUFtA8ozs0Jcz45PTc-jTT=CEKuezeU7QYviiN-Jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 04/06/17 15:41, Rob Herring wrote:
> On Thu, Apr 6, 2017 at 1:37 PM, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On 04/06/17 07:03, Rob Herring wrote:
>>> On Thu, Apr 6, 2017 at 1:18 AM, <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>> From: Frank Rowand <frank.rowand-7U/KSKJipcs@public.gmane.org>
>>>>
>>>> of_dma_get_range() has workaround code to fixup a device tree that
>>>> incorrectly specified a mask instead of a size for property
>>>> dma-ranges. That device tree was fixed a year ago in v4.6, so
>>>> the workaround is no longer needed. Leave a data validation
>>>> check in place, but no longer do the fixup. Move the check
>>>> one level deeper in the call stack so that other possible users
>>>> of dma-ranges will also be protected.
>>>>
>>>> The fix to the device tree was in
>>>> commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree").
>>>
>>> NACK.
>>> This was by design. You can't represent a size of 2^64 or 2^32.
>>
>> I agree that being unable to represent a size of 2^32 in a u32 and
>> a size of 2^64 in a u64 is the underlying issue.
>>
>> But the code to convert a mask to a size is _not_ design, it is a
>> hack that temporarily worked around a device tree that did not follow
>> the dma-ranges binding in the ePAPR.
>
> Since when is (2^64 - 1) not a size. It's a perfectly valid size in
I did not say (2^64 -1) is not a size.
I said that the existing code has a hack that converts what is perceived
to be a mask into a size. The existing code is:
@@ 110,21 @@ void of_dma_configure(struct device *dev, struct device_node *np)
size = dev->coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
/*
* Add a work around to treat the size as mask + 1 in case
* it is defined in DT as a mask.
*/
if (size & 1) {
dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
size);
size = size + 1;
}
if (!size) {
dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
return;
}
dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
}
Note the comment that says "in case it is defined in DT as a mask."
And as you stated in a review comment is 2015: "Also, we need a WARN
here so DTs get fixed."
> DT. And there's probably not a system in the world that needs access
> to that last byte. Is it completely accurate description if we
> subtract off 1? No, but it is still a valid range (so would be
> subtracting 12345).
>
>> That device tree was corrected a year ago to provide a size instead of
>> a mask.
>
> You are letting Linux implementation details influence your DT
> thinking. DT is much more flexible in that it supports a base address
> and size (and multiple of them) while Linux can only deal with a
> single address mask. If Linux dealt with base + size, then we wouldn't
No. of_dma_get_range() returns two addresses and a size from the
dma-ranges property, just as it is defined in the spec.
of_dma_configure() then interprets an odd size as meaning that the
device tree incorrectly contains a mask, and then converts that mask
to a size by adding one to it. Linux is _still_ using address and
size at this point. It does _not_ convert this size into a mask,
but instead passes size on into arch_setup_dma_ops().
The proposed patch is to quit accepting a mask as valid data in
dma-ranges.
> be having this conversation. As long as Linux only deals with masks,
> we're going to have to have some sort of work-around to deal with
> them.
>
>>> Well, technically you can for the latter, but then you have to grow
>>> #size-cells to 2 for an otherwise all 32-bit system which seems kind
>>> of pointless and wasteful. You could further restrict this to only
>>> allow ~0 and not just any case with bit 0 set.
>>>
>>> I'm pretty sure AMD is not the only system. There were 32-bit systems too.
>>
>> I examined all instances of property dma-ranges in in tree dts files in
>> Linux 4.11-rc1. There are none that incorrectly specify mask instead of
>> size.
>
> Okay, but there are ones for ranges at least. See ecx-2000.dts.
The patch does not impact the ranges property. It only impacts the
dma-ranges property.
>
>> #size-cells only changes to 2 for the dma-ranges property and the ranges
>> property when size is 2^32, so that is a very small amount of space.
>>
>> The patch does not allow for a size of 2^64. If a system requires a
>> size of 2^64 then the type of size needs to increase to be larger
>> than a u64. If you would like for the code to be defensive and
>> detect a device tree providing a size of 2^64 then I can add a
>> check to of_dma_get_range() to return -EINVAL if #size-cells > 2.
>> When that error triggers, the type of size can be changed.
>
> #size-cells > 2 is completely broken for anything but PCI. I doubt it
Yes, that is what I said. The current code does not support #size-cells > 2
for dma-ranges.
#size-cells > 2 for dma-ranges will lead to a problem in
of_dma_get_range(), which stuffs the value of the size into a u64.
Clearly, a 3 cell size will not fit into a u64.
> is easily fixed without some special casing (i.e. a different hack)
> until we have 128-bit support. I hope to retire before we need to
> support that.
>
> Rob
>
Can we get back to the basic premise of the proposed patch?
The current code in of_dma_configure() contains a hack that allows the
dma-ranges property to specify a mask instead of a size. The binding
in the specification allows a size and does not allow a mask.
The hack was added to account for one or more dts files that did not
follow the specification. In the mail list discussion of the hack
you said "Also, we need a WARN here so DTs get fixed."
The hack was first present in Linux 4.1. The only in-tree dts that
incorrectly contained a mask instead of a size in dma-ranges was
arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
That .dtsi was fixed by
commit c91cb9123cdd ("dtb: amd: Fix DMA ranges in device tree")
The fix was present in Linux 4.6, May 15, 2016.
I would like to remove the hack. I think that enough time has
elapsed to allow this change.
-Frank
--
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 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
From: kbuild test robot @ 2017-04-07 6:19 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all-JC7UmRfGjtg, linux-media-8fOc0yYH5q9zeIdxy0IIJw,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
In-Reply-To: <1491484249-11964-6-git-send-email-sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 14010 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20170406]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x016-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from drivers/media/i2c/tvp5150.c:19:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/i2c/tvp5150.c: In function 'tvp5150_parse_dt':
>> drivers/media/i2c/tvp5150.c:1377:35: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &bus_cfg);
^~~~~~~~~~~~~~~~
>> drivers/media/i2c/tvp5150.c:1377:35: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media/i2c/tvp5150.c:19:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media/i2c/tvp514x.c:41:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/i2c/tvp514x.c: In function 'tvp514x_get_pdata':
>> drivers/media/i2c/tvp514x.c:1012:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
>> drivers/media/i2c/tvp514x.c:1012:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media/i2c/tvp514x.c:41:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media/i2c/tvp7002.c:36:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/i2c/tvp7002.c: In function 'tvp7002_get_pdata':
>> drivers/media/i2c/tvp7002.c:904:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
>> drivers/media/i2c/tvp7002.c:904:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media/i2c/tvp7002.c:36:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media/v4l2-core/v4l2-fwnode.c:26:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media/v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_endpoint_parse':
>> drivers/media/v4l2-core/v4l2-fwnode.c:170:2: error: implicit declaration of function 'fwnode_graph_parse_endpoint' [-Werror=implicit-function-declaration]
fwnode_graph_parse_endpoint(fwn, &vfwn->base);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_parse_link':
>> drivers/media/v4l2-core/v4l2-fwnode.c:301:8: error: implicit declaration of function 'fwnode_get_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_parent(__fwn);
^~~~~~~~~~~~~~~~~
>> drivers/media/v4l2-core/v4l2-fwnode.c:301:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(__fwn);
^
>> drivers/media/v4l2-core/v4l2-fwnode.c:303:8: error: implicit declaration of function 'fwnode_get_next_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_next_parent(fwn);
^~~~~~~~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-fwnode.c:303:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:306:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:309:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
>> drivers/media/v4l2-core/v4l2-fwnode.c:313:8: error: implicit declaration of function 'fwnode_graph_get_remote_endpoint' [-Werror=implicit-function-declaration]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-fwnode.c:313:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:319:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:321:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:324:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media/v4l2-core/v4l2-fwnode.c:327:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tvp5150.c:19:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tvp5150.c: In function 'tvp5150_parse_dt':
drivers/media//i2c/tvp5150.c:1377:35: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(ep), &bus_cfg);
^~~~~~~~~~~~~~~~
drivers/media//i2c/tvp5150.c:1377:35: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tvp5150.c:19:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tvp514x.c:41:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tvp514x.c: In function 'tvp514x_get_pdata':
drivers/media//i2c/tvp514x.c:1012:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
drivers/media//i2c/tvp514x.c:1012:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tvp514x.c:41:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tvp7002.c:36:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tvp7002.c: In function 'tvp7002_get_pdata':
drivers/media//i2c/tvp7002.c:904:33: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
if (v4l2_fwnode_endpoint_parse(of_fwnode_handle(endpoint), &bus_cfg))
^~~~~~~~~~~~~~~~
drivers/media//i2c/tvp7002.c:904:33: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tvp7002.c:36:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//v4l2-core/v4l2-fwnode.c:26:0:
>> include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_endpoint_parse':
drivers/media//v4l2-core/v4l2-fwnode.c:170:2: error: implicit declaration of function 'fwnode_graph_parse_endpoint' [-Werror=implicit-function-declaration]
fwnode_graph_parse_endpoint(fwn, &vfwn->base);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c: In function 'v4l2_fwnode_parse_link':
drivers/media//v4l2-core/v4l2-fwnode.c:301:8: error: implicit declaration of function 'fwnode_get_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_parent(__fwn);
^~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c:301:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(__fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:303:8: error: implicit declaration of function 'fwnode_get_next_parent' [-Werror=implicit-function-declaration]
fwn = fwnode_get_next_parent(fwn);
^~~~~~~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c:303:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:306:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:309:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:313:8: error: implicit declaration of function 'fwnode_graph_get_remote_endpoint' [-Werror=implicit-function-declaration]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-fwnode.c:313:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_graph_get_remote_endpoint(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:319:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:321:6: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:324:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
drivers/media//v4l2-core/v4l2-fwnode.c:327:7: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
fwn = fwnode_get_next_parent(fwn);
^
cc1: some warnings being treated as errors
vim +/base +67 include/media/v4l2-fwnode.h
8219f9b0 Sakari Ailus 2017-04-06 61 * @bus_type: bus type
8219f9b0 Sakari Ailus 2017-04-06 62 * @bus: bus configuration data structure
8219f9b0 Sakari Ailus 2017-04-06 63 * @link_frequencies: array of supported link frequencies
8219f9b0 Sakari Ailus 2017-04-06 64 * @nr_of_link_frequencies: number of elements in link_frequenccies array
8219f9b0 Sakari Ailus 2017-04-06 65 */
8219f9b0 Sakari Ailus 2017-04-06 66 struct v4l2_fwnode_endpoint {
8219f9b0 Sakari Ailus 2017-04-06 @67 struct fwnode_endpoint base;
8219f9b0 Sakari Ailus 2017-04-06 68 /*
8219f9b0 Sakari Ailus 2017-04-06 69 * Fields below this line will be zeroed by
8219f9b0 Sakari Ailus 2017-04-06 70 * v4l2_fwnode_parse_endpoint()
:::::: The code at line 67 was first introduced by commit
:::::: 8219f9b04bb5639303351ca63b349966aecb9537 v4l: fwnode: Support generic fwnode for parsing standardised properties
:::::: TO: Sakari Ailus <sakari.ailus-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
:::::: CC: 0day robot <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24860 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/8] v4l: flash led class: Use fwnode_handle instead of device_node in init
From: kbuild test robot @ 2017-04-07 6:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-2-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3470 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x013-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers/media//v4l2-core/v4l2-flash-led-class.c: In function 'v4l2_flash_init':
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:642:4: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
^~
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:642:27: error: implicit declaration of function 'dev_fwnode' [-Werror=implicit-function-declaration]
sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
^~~~~~~~~~
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:642:25: warning: pointer/integer type mismatch in conditional expression
sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
^
>> drivers/media//v4l2-core/v4l2-flash-led-class.c:658:2: error: implicit declaration of function 'fwnode_handle_get' [-Werror=implicit-function-declaration]
fwnode_handle_get(sd->fwnode);
^~~~~~~~~~~~~~~~~
drivers/media//v4l2-core/v4l2-flash-led-class.c:658:22: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
fwnode_handle_get(sd->fwnode);
^~
drivers/media//v4l2-core/v4l2-flash-led-class.c:667:22: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
fwnode_handle_put(sd->fwnode);
^~
drivers/media//v4l2-core/v4l2-flash-led-class.c: In function 'v4l2_flash_release':
drivers/media//v4l2-core/v4l2-flash-led-class.c:687:22: error: 'struct v4l2_subdev' has no member named 'fwnode'; did you mean 'of_node'?
fwnode_handle_put(sd->fwnode);
^~
cc1: some warnings being treated as errors
vim +642 drivers/media//v4l2-core/v4l2-flash-led-class.c
636
637 sd = &v4l2_flash->sd;
638 v4l2_flash->fled_cdev = fled_cdev;
639 v4l2_flash->iled_cdev = iled_cdev;
640 v4l2_flash->ops = ops;
641 sd->dev = dev;
> 642 sd->fwnode = fwn ? fwn : dev_fwnode(led_cdev->dev);
643 v4l2_subdev_init(sd, &v4l2_flash_subdev_ops);
644 sd->internal_ops = &v4l2_flash_subdev_internal_ops;
645 sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
646 strlcpy(sd->name, config->dev_name, sizeof(sd->name));
647
648 ret = media_entity_pads_init(&sd->entity, 0, NULL);
649 if (ret < 0)
650 return ERR_PTR(ret);
651
652 sd->entity.function = MEDIA_ENT_F_FLASH;
653
654 ret = v4l2_flash_init_controls(v4l2_flash, config);
655 if (ret < 0)
656 goto err_init_controls;
657
> 658 fwnode_handle_get(sd->fwnode);
659
660 ret = v4l2_async_register_subdev(sd);
661 if (ret < 0)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34590 bytes --]
^ permalink raw reply
* Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API
From: kbuild test robot @ 2017-04-07 6:29 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-6-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3274 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on next-20170406]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x011-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from drivers/media//i2c/s5k5baf.c:33:0:
include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/s5k5baf.c: In function 's5k5baf_parse_device_node':
>> drivers/media//i2c/s5k5baf.c:1871:35: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(node_ep), &ep);
^~~~~~~~~~~~~~~~
>> drivers/media//i2c/s5k5baf.c:1871:35: warning: passing argument 1 of 'v4l2_fwnode_endpoint_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/s5k5baf.c:33:0:
include/media/v4l2-fwnode.h:95:5: note: expected 'struct fwnode_handle *' but argument is of type 'int'
int v4l2_fwnode_endpoint_parse(struct fwnode_handle *fwn,
^~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
--
In file included from drivers/media//i2c/tc358743.c:45:0:
include/media/v4l2-fwnode.h:67:25: error: field 'base' has incomplete type
struct fwnode_endpoint base;
^~~~
drivers/media//i2c/tc358743.c: In function 'tc358743_probe_of':
>> drivers/media//i2c/tc358743.c:1719:46: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
endpoint = v4l2_fwnode_endpoint_alloc_parse(of_fwnode_handle(ep));
^~~~~~~~~~~~~~~~
>> drivers/media//i2c/tc358743.c:1719:46: warning: passing argument 1 of 'v4l2_fwnode_endpoint_alloc_parse' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers/media//i2c/tc358743.c:45:0:
include/media/v4l2-fwnode.h:97:30: note: expected 'struct fwnode_handle *' but argument is of type 'int'
struct v4l2_fwnode_endpoint *v4l2_fwnode_endpoint_alloc_parse(
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/of_fwnode_handle +1871 drivers/media//i2c/s5k5baf.c
1865 if (!node_ep) {
1866 dev_err(dev, "no endpoint defined at node %s\n",
1867 node->full_name);
1868 return -EINVAL;
1869 }
1870
> 1871 ret = v4l2_fwnode_endpoint_parse(of_fwnode_handle(node_ep), &ep);
1872 of_node_put(node_ep);
1873 if (ret)
1874 return ret;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25509 bytes --]
^ permalink raw reply
* Re: [PATCH v2 4/8] v4l: async: Provide interoperability between OF and fwnode matching
From: kbuild test robot @ 2017-04-07 6:29 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-5-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x016-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers/media/v4l2-core/v4l2-async.c: In function 'match_of':
>> drivers/media/v4l2-core/v4l2-async.c:63:6: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
of_fwnode_handle(sd->of_node) : sd->fwnode,
^~~~~~~~~~~~~~~~
>> drivers/media/v4l2-core/v4l2-async.c:63:36: warning: pointer/integer type mismatch in conditional expression
of_fwnode_handle(sd->of_node) : sd->fwnode,
^
>> drivers/media/v4l2-core/v4l2-async.c:64:6: warning: passing argument 2 of 'fwnode_cmp' makes pointer from integer without a cast [-Wint-conversion]
of_fwnode_handle(asd->match.of.node));
^~~~~~~~~~~~~~~~
drivers/media/v4l2-core/v4l2-async.c:44:13: note: expected 'struct fwnode_handle *' but argument is of type 'int'
static bool fwnode_cmp(struct fwnode_handle *one,
^~~~~~~~~~
drivers/media/v4l2-core/v4l2-async.c: In function 'match_fwnode':
drivers/media/v4l2-core/v4l2-async.c:70:36: warning: pointer/integer type mismatch in conditional expression
of_fwnode_handle(sd->of_node) : sd->fwnode,
^
cc1: some warnings being treated as errors
vim +/of_fwnode_handle +63 drivers/media/v4l2-core/v4l2-async.c
57 return one == theother;
58 }
59
60 static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
61 {
62 return fwnode_cmp(sd->of_node ?
> 63 of_fwnode_handle(sd->of_node) : sd->fwnode,
> 64 of_fwnode_handle(asd->match.of.node));
65 }
66
67 static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24847 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/8] v4l: flash led class: Use fwnode_handle instead of device_node in init
From: kbuild test robot @ 2017-04-07 6:35 UTC (permalink / raw)
To: Sakari Ailus
Cc: kbuild-all, linux-media, linux-acpi, devicetree, laurent.pinchart
In-Reply-To: <1491484249-11964-2-git-send-email-sakari.ailus@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
Hi Sakari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sakari-Ailus/v4l-flash-led-class-Use-fwnode_handle-instead-of-device_node-in-init/20170407-133451
base: git://linuxtv.org/media_tree.git master
config: i386-randconfig-x014-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All error/warnings (new ones prefixed by >>):
drivers//leds/leds-max77693.c: In function 'max77693_register_led':
>> drivers//leds/leds-max77693.c:933:45: error: implicit declaration of function 'of_fwnode_handle' [-Werror=implicit-function-declaration]
sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
^~~~~~~~~~~~~~~~
>> drivers//leds/leds-max77693.c:933:45: warning: passing argument 2 of 'v4l2_flash_init' makes pointer from integer without a cast [-Wint-conversion]
In file included from drivers//leds/leds-max77693.c:23:0:
include/media/v4l2-flash-led-class.h:140:34: note: expected 'struct device_node *' but argument is of type 'int'
static inline struct v4l2_flash *v4l2_flash_init(
^~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
vim +/of_fwnode_handle +933 drivers//leds/leds-max77693.c
927 if (ret < 0)
928 return ret;
929
930 max77693_init_v4l2_flash_config(sub_led, led_cfg, &v4l2_sd_cfg);
931
932 /* Register in the V4L2 subsystem. */
> 933 sub_led->v4l2_flash = v4l2_flash_init(dev, of_fwnode_handle(sub_node),
934 fled_cdev, NULL, &v4l2_flash_ops,
935 &v4l2_sd_cfg);
936 if (IS_ERR(sub_led->v4l2_flash)) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 25664 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
From: Michael Ellerman @ 2017-04-07 6:40 UTC (permalink / raw)
To: Rob Herring, Nicholas Piggin
Cc: devicetree@vger.kernel.org, linuxppc-dev, Benjamin Herrenschmidt,
Frank Rowand
In-Reply-To: <CAL_JsqLEvjb8S-+-JEa4ALHeCWHiR1A_4ur9kd3pBRJaFYWVKw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> writes:
> On Wed, Apr 5, 2017 at 9:32 AM, Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Wed, 5 Apr 2017 08:35:06 -0500
>> Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>
>>> On Wed, Apr 5, 2017 at 7:37 AM, Nicholas Piggin <npiggin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> > Introduce primitives for FDT parsing. These will be used for powerpc
>>> > cpufeatures node scanning, which has quite complex structure but should
>>> > be processed early.
>>>
>>> Have you looked at unflattening the FDT earlier?
>>
>> Hi, thanks for taking a look. Did you mean to trim the cc list?
>
> Ugg, no. I've added everyone back.
>
>> It may be possible but I'd like to avoid it if we can. There might
>> turn out to be some errata or feature that requires early setup. And
>> the current cpu feature parsing code does it with flat dt.
>
> Well, I'd like to avoid expanding usage of flat DT parsing in the
> kernel. But you could just put this function into arch/powerpc and I'd
> never see it, but I like that even less. Mainly, I just wanted to
> raise the point.
>
> Your argument works until you need that setup in assembly code, then
> you are in the situation that you need to either handle the setup in
> bootloader/firmware or have an simple way to determine that condition.
Where Nick does this FDT parsing is literally the first C code that runs
in the kernel. The MMU is off, we don't even know how much memory we
have, or where it is.
So it's basically impossible to do the unflattening earlier. What we
could do is move the CPU feature setup *later*.
As Ben & Nick said that would be a pretty intrusive change, and
definitely not something we want to do now.
What we could probably do is split some of the flat tree parsing, so
that we discover memory, even just some of it, then unflatten, and then
do more setup using the unflattened tree.
But that will require a lot of delicate work. So we'd definitely like to
do that separately from this series.
cheers
--
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 2/5] media: Add support for CXD2880 SPI I/F
From: kbuild test robot @ 2017-04-07 6:53 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
tbird20d-Re5JQEeQqe8AvxtiuMwx3w,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w, Yasunari Takiguchi,
Masayuki Yamamoto, Hideki Nozawa, Kota Yonezawa,
Toshihiko Matsumoto, Satoshi Watanabe
In-Reply-To: <1491465339-9483-1-git-send-email-Yasunari.Takiguchi-7U/KSKJipcs@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]
Hi Yasunari,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.11-rc5 next-20170406]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yasunari-Takiguchi-sony-com/dt-bindings-media-Add-document-file-and-driver/20170407-064503
base: git://linuxtv.org/media_tree.git master
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: the linux-review/Yasunari-Takiguchi-sony-com/dt-bindings-media-Add-document-file-and-driver/20170407-064503 HEAD 9a65bc5ba5fc3ec361e835324009bf7097391121 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
>> drivers/media//spi/cxd2880-spi.c:32:21: fatal error: cxd2880.h: No such file or directory
#include "cxd2880.h"
^
compilation terminated.
vim +32 drivers/media//spi/cxd2880-spi.c
16 * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
17 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
18 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
19 * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
20 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
21 * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
22 *
23 * You should have received a copy of the GNU General Public License along
24 * with this program; if not, see <http://www.gnu.org/licenses/>.
25 */
26
27 #include <linux/spi/spi.h>
28
29 #include "dvb_demux.h"
30 #include "dmxdev.h"
31 #include "dvb_frontend.h"
> 32 #include "cxd2880.h"
33
34 #define CXD2880_MAX_FILTER_SIZE 32
35 #define BURST_WRITE_MAX 128
36 #define MAX_TRANS_PACKET 300
37
38 struct cxd2880_ts_buf_info {
39 u8 read_ready;
40 u8 almost_full;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 29524 bytes --]
^ permalink raw reply
* Re: [PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n
From: kbuild test robot @ 2017-04-07 6:58 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Florian Fainelli,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
In-Reply-To: <20170406193224.10046-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]
Hi Florian,
[auto build test ERROR on v4.9-rc8]
[also build test ERROR on next-20170406]
[cannot apply to glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/of-Make-of_match_node-an-inline-stub-for-CONFIG_OF-n/20170407-111805
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/cadence/macb.c: In function 'macb_probe':
>> drivers/net/ethernet/cadence/macb.c:2967:25: error: 'macb_dt_ids' undeclared (first use in this function)
match = of_match_node(macb_dt_ids, np);
^~~~~~~~~~~
drivers/net/ethernet/cadence/macb.c:2967:25: note: each undeclared identifier is reported only once for each function it appears in
vim +/macb_dt_ids +2967 drivers/net/ethernet/cadence/macb.c
421d9df06 Cyrille Pitchen 2015-03-07 2951 struct phy_device *phydev;
421d9df06 Cyrille Pitchen 2015-03-07 2952 struct net_device *dev;
421d9df06 Cyrille Pitchen 2015-03-07 2953 struct resource *regs;
421d9df06 Cyrille Pitchen 2015-03-07 2954 void __iomem *mem;
421d9df06 Cyrille Pitchen 2015-03-07 2955 const char *mac;
421d9df06 Cyrille Pitchen 2015-03-07 2956 struct macb *bp;
421d9df06 Cyrille Pitchen 2015-03-07 2957 int err;
421d9df06 Cyrille Pitchen 2015-03-07 2958
f2ce8a9e4 Andy Shevchenko 2015-07-24 2959 regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
f2ce8a9e4 Andy Shevchenko 2015-07-24 2960 mem = devm_ioremap_resource(&pdev->dev, regs);
f2ce8a9e4 Andy Shevchenko 2015-07-24 2961 if (IS_ERR(mem))
f2ce8a9e4 Andy Shevchenko 2015-07-24 2962 return PTR_ERR(mem);
f2ce8a9e4 Andy Shevchenko 2015-07-24 2963
c69618b3e Nicolas Ferre 2015-03-31 2964 if (np) {
c69618b3e Nicolas Ferre 2015-03-31 2965 const struct of_device_id *match;
c69618b3e Nicolas Ferre 2015-03-31 2966
c69618b3e Nicolas Ferre 2015-03-31 @2967 match = of_match_node(macb_dt_ids, np);
c69618b3e Nicolas Ferre 2015-03-31 2968 if (match && match->data) {
c69618b3e Nicolas Ferre 2015-03-31 2969 macb_config = match->data;
c69618b3e Nicolas Ferre 2015-03-31 2970 clk_init = macb_config->clk_init;
c69618b3e Nicolas Ferre 2015-03-31 2971 init = macb_config->init;
c69618b3e Nicolas Ferre 2015-03-31 2972 }
c69618b3e Nicolas Ferre 2015-03-31 2973 }
c69618b3e Nicolas Ferre 2015-03-31 2974
aead88bd0 shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org 2016-08-16 2975 err = clk_init(pdev, &pclk, &hclk, &tx_clk, &rx_clk);
:::::: The code at line 2967 was first introduced by commit
:::::: c69618b3e4f220f4990b91596d40ea3c4cdc938a net/macb: fix probe sequence to setup clocks earlier
:::::: TO: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
:::::: CC: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 28725 bytes --]
^ permalink raw reply
* Re: [PATCH v2] ARM: zynq: Add #io-channel-cells to (x)adc node for iio-hwmon
From: Michal Simek @ 2017-04-07 7:11 UTC (permalink / raw)
To: Lars-Peter Clausen, Michal Simek, Moritz Fischer
Cc: Linux Kernel Mailing List, Devicetree List, Sören Brinkmann,
linux-arm-kernel, Julia Cartwright
In-Reply-To: <7420fc7a-4a65-0ff8-adb8-f2e9815fdeba@metafoo.de>
On 20.3.2017 16:34, Lars-Peter Clausen wrote:
> On 03/20/2017 04:33 PM, Michal Simek wrote:
>> On 17.3.2017 07:46, Michal Simek wrote:
>>> On 16.3.2017 22:20, Lars-Peter Clausen wrote:
>>>> On 03/16/2017 07:06 PM, Michal Simek wrote:
>>>>> On 16.3.2017 17:51, Lars-Peter Clausen wrote:
>>>>>> On 03/16/2017 05:45 PM, Michal Simek wrote:
>>>>>>> On 16.3.2017 17:39, Moritz Fischer wrote:
>>>>>>>> On Thu, Mar 16, 2017 at 9:16 AM, Michal Simek <michal.simek@xilinx.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 8.3.2017 21:11, Moritz Fischer wrote:
>>>>>>>>>> Fix
>>>>>>>>>>
>>>>>>>>>> OF: /iio_hwmon: could not get #io-channel-cells for
>>>>>>>>>> /amba/adc@f8007100
>>>>>>>>>> OF: /iio_hwmon: could not get #io-channel-cells for
>>>>>>>>>> /amba/adc@f8007100
>>>>>>>>>> OF: /iio_hwmon: could not get #io-channel-cells for
>>>>>>>>>> /amba/adc@f8007100
>>>>>>>>>>
>>>>>>>>>> by adding the #io-channel-cells property.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Moritz Fischer <mdf@kernel.org>
>>>>>>>>>> Cc: Michal Simek <michal.simek@xilinx.com>
>>>>>>>>>> Cc: Sören Brinkmann <soren.brinkmann@xilinx.com>
>>>>>>>>>> Cc: Julia Cartwright <julia@ni.com>
>>>>>>>>>> Cc: linux-kernel@vger.kernel.org
>>>>>>>>>> Cc: devicetree@vger.kernel.org
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> Changes from v1:
>>>>>>>>>> - fix messed up commit message
>>>>>>>>>> ---
>>>>>>>>>> arch/arm/boot/dts/zynq-7000.dtsi | 1 +
>>>>>>>>>> 1 file changed, 1 insertion(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
>>>>>>>>>> index f3ac9bf..98233a8 100644
>>>>>>>>>> --- a/arch/arm/boot/dts/zynq-7000.dtsi
>>>>>>>>>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>>>>>>>>>> @@ -72,6 +72,7 @@
>>>>>>>>>> interrupts = <0 7 4>;
>>>>>>>>>> interrupt-parent = <&intc>;
>>>>>>>>>> clocks = <&clkc 12>;
>>>>>>>>>> + #io-channel-cells = <1>;
>>>>>>>>>> };
>>>>>>>>>>
>>>>>>>>>> can0: can@e0008000 {
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think it will be good to the next step too.
>>>>>>>>> It means also add iio-hwmon node too.
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>
>>>>>>>> I hadn't put it in there since dts is supposed to describe hw,
>>>>>>>> but obviously putting the actual hwmon in there makes it more useful.
>>>>>>>
>>>>>>> I had one discussion about this with Grant in past and it is common
>>>>>>> mistake. It is simplification of purpose of dts.
>>>>>>>
>>>>>>
>>>>>> If the iio-hwmon binding had gone through review it would have been rejected.
>>>>>
>>>>> Isn't it a time to deprecate it?
>>>>
>>>> Well, it's ABI now and has to stay forever. Deprecating it makes only sense
>>>> if there is a replacement, which there is not. The iio-hwmon bridge has its
>>>> usecases it's just instantiating it via devicetree which is not so nice.
>>>>
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> I can resubmit with the hwmon node in there.
>>>>>>>
>>>>>>> If you grep kernel tree you will see that others are using it too.
>>>>>>> Also there is accepted binding for that that's why I can't see big
>>>>>>> problem with it.
>>>>>>
>>>>>> Since this is an application specific binding I wouldn't put it in the
>>>>>> generic DT include file. It's a bit like adding a gpio-key binding for each
>>>>>> of the GPIOs just in case somebody wants to use it.
>>>>>
>>>>> psci is system specific too.
>>>>>
>>>>> IIRC this driver for zynq was written by ADI or with ADI help that's why
>>>>> you know much better than I what's the correct configuration.
>>>>>
>>>>> This targets PS IP which should be present in the hw all the time.
>>>>> Not sure if for all configuration but I expect at least the part of it
>>>>> is there all them time.
>>>>>
>>>>> If binding is incorrect then please remove it with removing from all
>>>>> dts/dtsi files which have this. The same is for of probe function in the
>>>>> driver itself.
>>>>> If this is not done then this is just +1 case.
>>>>>
>>>>> If you still insist that we shouldn't do it then please at least extend
>>>>> commit message and put there example how to wire it on zynq.
>>>>
>>>> There is a IIO driver for the XADC, this driver has a userspace interface
>>>> that exposes the measurements provided by the hardware. Using the hwmon
>>>> bridge will expose the same information just through a hwmon interface.
>>>>
>>>> One reason for using the iio-hwmon bridge is because you have a legacy
>>>> application that expects the a hwmon interface. But new applications that
>>>> want to access the XADC should really use the IIO interface if possible.
>>>>
>>>> In my opinion instantiating the hwmon bridge by default will only cause
>>>> confusion. There are now redundant interfaces and users will wonder what is
>>>> the difference between the two. Is it the same data, is it different data?
>>>> Which is the preferred interface? Which one is 'better'?
>>>
>>> IMHO this should be covered by documentation. One paragraph in iio-hwmon
>>> binding can have answers for this and it will be very clear what people
>>> should use.
>>
>> Any comment on this one?
>
> Send a patch? :)
>
I don't feel that I know iio enough to be good candidate to describe
this properly.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH V3 3/4] pwm: tegra: Add DT binding details to configure pin in suspends/resume
From: Jon Hunter @ 2017-04-07 7:49 UTC (permalink / raw)
To: Laxman Dewangan, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: mark.rutland-5wv7dgnIgG8, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <58E67152.1080400-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 06/04/17 17:48, Laxman Dewangan wrote:
>
> On Thursday 06 April 2017 08:56 PM, Jon Hunter wrote:
>> On 06/04/17 15:21, Laxman Dewangan wrote:
>>> In some of NVIDIA Tegra's platform, PWM controller is used to
>>> control the PWM controlled regulators. PWM signal is connected to
>>> the VID pin of the regulator where duty cycle of PWM signal decide
>>> the voltage level of the regulator output.
>>>
>>> The tristate (high impedance of PWM pin form Tegra) also define
>> s/form/from/
>> s/define/defines/
>>
>>> one of the state of PWM regulator which needs to be configure in
>>> suspend state of system.
>> It maybe clearer to say that when the system enters suspend the
>> regulator requires the pwm output to be tristated.
>
> Not necessarily that every PWM regulator interfaces needs it. It
> depends on the devices.
Yes I understand that. I am just saying the description could be a
little clearer.
> So I will say:
>
> When system enters suspend, in some of PWM regulator interface, it is
> required to to set the PWM output to be tristated.
Ok, but I think you should say why that is, because from the above
sentence alone it is not clear. Maybe you should say that some PWM
client/slave devices require the PWM output to be tristated.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH] of: Make of_match_node() an inline stub for CONFIG_OF=n
From: kbuild test robot @ 2017-04-07 7:49 UTC (permalink / raw)
Cc: kbuild-all-JC7UmRfGjtg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andrew-g2DYL2Zd6BY,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Florian Fainelli,
Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
In-Reply-To: <20170406193224.10046-1-f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]
Hi Florian,
[auto build test ERROR on v4.9-rc8]
[also build test ERROR on next-20170406]
[cannot apply to glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Florian-Fainelli/of-Make-of_match_node-an-inline-stub-for-CONFIG_OF-n/20170407-111805
config: x86_64-randconfig-ne0-04071359 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers//mfd/max8998.c: In function 'max8998_i2c_get_driver_data':
>> drivers//mfd/max8998.c:174:25: error: 'max8998_dt_match' undeclared (first use in this function)
match = of_match_node(max8998_dt_match, i2c->dev.of_node);
^~~~~~~~~~~~~~~~
drivers//mfd/max8998.c:174:25: note: each undeclared identifier is reported only once for each function it appears in
vim +/max8998_dt_match +174 drivers//mfd/max8998.c
ee999fb3 Tomasz Figa 2013-06-25 158
ee999fb3 Tomasz Figa 2013-06-25 159 pd->ono = irq_of_parse_and_map(dev->of_node, 1);
ee999fb3 Tomasz Figa 2013-06-25 160
ee999fb3 Tomasz Figa 2013-06-25 161 /*
ee999fb3 Tomasz Figa 2013-06-25 162 * ToDo: the 'wakeup' member in the platform data is more of a linux
ee999fb3 Tomasz Figa 2013-06-25 163 * specfic information. Hence, there is no binding for that yet and
ee999fb3 Tomasz Figa 2013-06-25 164 * not parsed here.
ee999fb3 Tomasz Figa 2013-06-25 165 */
ee999fb3 Tomasz Figa 2013-06-25 166 return pd;
ee999fb3 Tomasz Figa 2013-06-25 167 }
ee999fb3 Tomasz Figa 2013-06-25 168
8bace2d5 Lee Jones 2014-02-03 169 static inline unsigned long max8998_i2c_get_driver_data(struct i2c_client *i2c,
ee999fb3 Tomasz Figa 2013-06-25 170 const struct i2c_device_id *id)
ee999fb3 Tomasz Figa 2013-06-25 171 {
ee999fb3 Tomasz Figa 2013-06-25 172 if (IS_ENABLED(CONFIG_OF) && i2c->dev.of_node) {
ee999fb3 Tomasz Figa 2013-06-25 173 const struct of_device_id *match;
ee999fb3 Tomasz Figa 2013-06-25 @174 match = of_match_node(max8998_dt_match, i2c->dev.of_node);
8bace2d5 Lee Jones 2014-02-03 175 return (unsigned long)match->data;
ee999fb3 Tomasz Figa 2013-06-25 176 }
ee999fb3 Tomasz Figa 2013-06-25 177
8bace2d5 Lee Jones 2014-02-03 178 return id->driver_data;
ee999fb3 Tomasz Figa 2013-06-25 179 }
ee999fb3 Tomasz Figa 2013-06-25 180
156f2528 Kyungmin Park 2010-06-16 181 static int max8998_i2c_probe(struct i2c_client *i2c,
156f2528 Kyungmin Park 2010-06-16 182 const struct i2c_device_id *id)
:::::: The code at line 174 was first introduced by commit
:::::: ee999fb3f17faa3af6028bf7130707fe0d4157a4 mfd: max8998: Add support for Device Tree
:::::: TO: Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
:::::: CC: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24388 bytes --]
^ permalink raw reply
* Re: [PATCH V4 4/4] pwm: tegra: Add support to configure pin state in suspends/resume
From: Jon Hunter @ 2017-04-07 7:51 UTC (permalink / raw)
To: Laxman Dewangan, thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: mark.rutland-5wv7dgnIgG8, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <58E66F8F.1030802-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On 06/04/17 17:40, Laxman Dewangan wrote:
> Oops, it was actually v2.
>
> On Thursday 06 April 2017 08:47 PM, Jon Hunter wrote:
>> On 06/04/17 15:21, Laxman Dewangan wrote:
>>> In some of NVIDIA Tegra's platform, PWM controller is used to
>>> control the PWM controlled regulators. PWM signal is connected to
>>> the VID pin of the regulator where duty cycle of PWM signal decide
>>> the voltage level of the regulator output.
>>>
>>> The tristate (high impedance of PWM pin form Tegra) also define
>>> one of the state of PWM regulator which needs to be configure in
>>> suspend state of system.
>>>
>>> Add support to configure the pin state via pinctrl frameworks in
>>> suspend and active state of the system.
>>>
>>> Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>> ---
>>> Changes from v1:
>>> - Use standard pinctrl names for sleep and active state.
>>> - Use API pinctrl_pm_select_*()
>>>
>>> drivers/pwm/pwm-tegra.c | 22 ++++++++++++++++++++++
>>> 1 file changed, 22 insertions(+)
>>>
>>> diff --git a/drivers/pwm/pwm-tegra.c b/drivers/pwm/pwm-tegra.c
>>> index e9c4de5..af1bd4f 100644
>>> --- a/drivers/pwm/pwm-tegra.c
>>> +++ b/drivers/pwm/pwm-tegra.c
>>> @@ -29,6 +29,7 @@
>>> #include <linux/of_device.h>
>>> #include <linux/pwm.h>
>>> #include <linux/platform_device.h>
>>> +#include <linux/pinctrl/consumer.h>
>>> #include <linux/slab.h>
>>> #include <linux/reset.h>
>>> @@ -256,6 +257,22 @@ static int tegra_pwm_remove(struct
>>> platform_device *pdev)
>>> return pwmchip_remove(&pc->chip);
>>> }
>>> +#ifdef CONFIG_PM_SLEEP
>>> +static int tegra_pwm_suspend(struct device *dev)
>>> +{
>>> + pinctrl_pm_select_sleep_state(dev);
>> Why not return the error code here?
>
> As the pin state in suspend is optional, I dont want to return error if
> the sleep state is not available.
>
> However, it seems pinctrl take care of retuning success if there is no
> sleep state. By seeing code.
Exactly, that is what I did for i2c because pinctrl it is also optional
for i2c.
> Let me test this on different condition and it it works fine then we can
> return the return of pinctrl_pm_select_*()
>
>
> BTW, it should be OK to have pwm_tegra_resume/suspend wrapper, not
> directly use the pinctrl_pm_select_* in pm ops suspend/resume. The
> prototype matches.
I think that I would keep the wrapper.
>> By the way, do you plan to include patches to populate the bindings for
>> the pwm devices?
>
> I am planning to populate the GPU regulator which is PWM based. This
> will only populate the regulator.
Ok.
Jon
--
nvpublic
^ 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