* [PATCH 1/9] drm/msm/a6xx: rnndb updates for a6xx
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-27 15:11 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Update the register definitions for a6xx from the rnndb database.
Changes include new enums for upcoming devcoredump support, moving
the PDC and GCC_GX register definitions to their own domain and
various other register updates and additions.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 642 ++++++++++++++--------
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 26 +-
2 files changed, 416 insertions(+), 252 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index 87eab51f7000..7acc57b2c1be 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -8,17 +8,17 @@ This file was generated by the rules-ng-ng headergen tool in this git repository
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/envytools/rnndb/adreno.xml ( 501 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/freedreno_copyright.xml ( 1572 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a2xx.xml ( 36805 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_common.xml ( 13634 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a3xx.xml ( 83840 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a4xx.xml ( 112086 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a5xx.xml ( 147240 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx.xml ( 101627 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/ocmem.xml ( 1773 bytes, from 2018-07-03 19:37:13)
+- ./adreno.xml ( 501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 147240 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a6xx.xml ( 107521 bytes, from 2018-08-16 17:44:50)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-08-16 17:44:26)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
Copyright (C) 2013-2018 by the following authors:
- Rob Clark <robdclark@gmail.com> (robclark)
@@ -272,6 +272,98 @@ enum a6xx_cp_perfcounter_select {
PERF_CP_ALWAYS_COUNT = 0,
};
+enum a6xx_shader_id {
+ A6XX_TP0_TMO_DATA = 9,
+ A6XX_TP0_SMO_DATA = 10,
+ A6XX_TP0_MIPMAP_BASE_DATA = 11,
+ A6XX_TP1_TMO_DATA = 25,
+ A6XX_TP1_SMO_DATA = 26,
+ A6XX_TP1_MIPMAP_BASE_DATA = 27,
+ A6XX_SP_INST_DATA = 41,
+ A6XX_SP_LB_0_DATA = 42,
+ A6XX_SP_LB_1_DATA = 43,
+ A6XX_SP_LB_2_DATA = 44,
+ A6XX_SP_LB_3_DATA = 45,
+ A6XX_SP_LB_4_DATA = 46,
+ A6XX_SP_LB_5_DATA = 47,
+ A6XX_SP_CB_BINDLESS_DATA = 48,
+ A6XX_SP_CB_LEGACY_DATA = 49,
+ A6XX_SP_UAV_DATA = 50,
+ A6XX_SP_INST_TAG = 51,
+ A6XX_SP_CB_BINDLESS_TAG = 52,
+ A6XX_SP_TMO_UMO_TAG = 53,
+ A6XX_SP_SMO_TAG = 54,
+ A6XX_SP_STATE_DATA = 55,
+ A6XX_HLSQ_CHUNK_CVS_RAM = 73,
+ A6XX_HLSQ_CHUNK_CPS_RAM = 74,
+ A6XX_HLSQ_CHUNK_CVS_RAM_TAG = 75,
+ A6XX_HLSQ_CHUNK_CPS_RAM_TAG = 76,
+ A6XX_HLSQ_ICB_CVS_CB_BASE_TAG = 77,
+ A6XX_HLSQ_ICB_CPS_CB_BASE_TAG = 78,
+ A6XX_HLSQ_CVS_MISC_RAM = 80,
+ A6XX_HLSQ_CPS_MISC_RAM = 81,
+ A6XX_HLSQ_INST_RAM = 82,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM = 83,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM = 84,
+ A6XX_HLSQ_CVS_MISC_RAM_TAG = 85,
+ A6XX_HLSQ_CPS_MISC_RAM_TAG = 86,
+ A6XX_HLSQ_INST_RAM_TAG = 87,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM_TAG = 88,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM_TAG = 89,
+ A6XX_HLSQ_PWR_REST_RAM = 90,
+ A6XX_HLSQ_PWR_REST_TAG = 91,
+ A6XX_HLSQ_DATAPATH_META = 96,
+ A6XX_HLSQ_FRONTEND_META = 97,
+ A6XX_HLSQ_INDIRECT_META = 98,
+ A6XX_HLSQ_BACKEND_META = 99,
+};
+
+enum a6xx_debugbus_id {
+ A6XX_DBGBUS_CP = 1,
+ A6XX_DBGBUS_RBBM = 2,
+ A6XX_DBGBUS_VBIF = 3,
+ A6XX_DBGBUS_HLSQ = 4,
+ A6XX_DBGBUS_UCHE = 5,
+ A6XX_DBGBUS_DPM = 6,
+ A6XX_DBGBUS_TESS = 7,
+ A6XX_DBGBUS_PC = 8,
+ A6XX_DBGBUS_VFDP = 9,
+ A6XX_DBGBUS_VPC = 10,
+ A6XX_DBGBUS_TSE = 11,
+ A6XX_DBGBUS_RAS = 12,
+ A6XX_DBGBUS_VSC = 13,
+ A6XX_DBGBUS_COM = 14,
+ A6XX_DBGBUS_LRZ = 16,
+ A6XX_DBGBUS_A2D = 17,
+ A6XX_DBGBUS_CCUFCHE = 18,
+ A6XX_DBGBUS_GMU_CX = 19,
+ A6XX_DBGBUS_RBP = 20,
+ A6XX_DBGBUS_DCS = 21,
+ A6XX_DBGBUS_DBGC = 22,
+ A6XX_DBGBUS_CX = 23,
+ A6XX_DBGBUS_GMU_GX = 24,
+ A6XX_DBGBUS_TPFCHE = 25,
+ A6XX_DBGBUS_GBIF_GX = 26,
+ A6XX_DBGBUS_GPC = 29,
+ A6XX_DBGBUS_LARC = 30,
+ A6XX_DBGBUS_HLSQ_SPTP = 31,
+ A6XX_DBGBUS_RB_0 = 32,
+ A6XX_DBGBUS_RB_1 = 33,
+ A6XX_DBGBUS_UCHE_WRAPPER = 36,
+ A6XX_DBGBUS_CCU_0 = 40,
+ A6XX_DBGBUS_CCU_1 = 41,
+ A6XX_DBGBUS_VFD_0 = 56,
+ A6XX_DBGBUS_VFD_1 = 57,
+ A6XX_DBGBUS_VFD_2 = 58,
+ A6XX_DBGBUS_VFD_3 = 59,
+ A6XX_DBGBUS_SP_0 = 64,
+ A6XX_DBGBUS_SP_1 = 65,
+ A6XX_DBGBUS_TPL1_0 = 72,
+ A6XX_DBGBUS_TPL1_1 = 73,
+ A6XX_DBGBUS_TPL1_2 = 74,
+ A6XX_DBGBUS_TPL1_3 = 75,
+};
+
enum a6xx_tex_filter {
A6XX_TEX_NEAREST = 0,
A6XX_TEX_LINEAR = 1,
@@ -1765,12 +1857,39 @@ static inline uint32_t A6XX_UCHE_CLIENT_PF_PERFSEL(uint32_t val)
#define REG_A6XX_VBIF_VERSION 0x00003000
+#define REG_A6XX_VBIF_CLKON 0x00003001
+#define A6XX_VBIF_CLKON_FORCE_ON_TESTBUS 0x00000002
+
#define REG_A6XX_VBIF_GATE_OFF_WRREQ_EN 0x0000302a
#define REG_A6XX_VBIF_XIN_HALT_CTRL0 0x00003080
#define REG_A6XX_VBIF_XIN_HALT_CTRL1 0x00003081
+#define REG_A6XX_VBIF_TEST_BUS_OUT_CTRL 0x00003084
+
+#define REG_A6XX_VBIF_TEST_BUS1_CTRL0 0x00003085
+
+#define REG_A6XX_VBIF_TEST_BUS1_CTRL1 0x00003086
+#define A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__MASK 0x0000000f
+#define A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__SHIFT 0
+static inline uint32_t A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL(uint32_t val)
+{
+ return ((val) << A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__SHIFT) & A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__MASK;
+}
+
+#define REG_A6XX_VBIF_TEST_BUS2_CTRL0 0x00003087
+
+#define REG_A6XX_VBIF_TEST_BUS2_CTRL1 0x00003088
+#define A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__MASK 0x000001ff
+#define A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__SHIFT 0
+static inline uint32_t A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL(uint32_t val)
+{
+ return ((val) << A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__SHIFT) & A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__MASK;
+}
+
+#define REG_A6XX_VBIF_TEST_BUS_OUT 0x0000308c
+
#define REG_A6XX_VBIF_PERF_CNT_SEL0 0x000030d0
#define REG_A6XX_VBIF_PERF_CNT_SEL1 0x000030d1
@@ -1813,228 +1932,6 @@ static inline uint32_t A6XX_UCHE_CLIENT_PF_PERFSEL(uint32_t val)
#define REG_A6XX_VBIF_PERF_PWR_CNT_HIGH2 0x0000311a
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_A 0x00018400
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_B 0x00018401
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_C 0x00018402
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_D 0x00018403
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__MASK 0x000000ff
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__MASK 0x0000ff00
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__SHIFT 8
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLT 0x00018404
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK 0x0000003f
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK 0x00007000
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT 12
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK 0xf0000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT 28
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLM 0x00018405
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK 0x0f000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT 24
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_0 0x00018408
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_1 0x00018409
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_2 0x0001840a
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_3 0x0001840b
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_0 0x0001840c
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_1 0x0001840d
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_2 0x0001840e
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_3 0x0001840f
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0 0x00018410
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK 0x0000000f
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK 0x000000f0
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT 4
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK 0x00000f00
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT 8
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK 0x0000f000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT 12
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK 0x000f0000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT 16
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK 0x00f00000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT 20
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK 0x0f000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT 24
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK 0xf0000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT 28
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1 0x00018411
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK 0x0000000f
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK 0x000000f0
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT 4
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK 0x00000f00
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT 8
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK 0x0000f000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT 12
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK 0x000f0000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT 16
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK 0x00f00000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT 20
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK 0x0f000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT 24
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK 0xf0000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT 28
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF1 0x0001842f
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF2 0x00018430
-
-#define REG_A6XX_PDC_GPU_ENABLE_PDC 0x00021140
-
-#define REG_A6XX_PDC_GPU_SEQ_START_ADDR 0x00021148
-
-#define REG_A6XX_PDC_GPU_TCS0_CONTROL 0x00021540
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD_ENABLE_BANK 0x00021541
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD_WAIT_FOR_CMPL_BANK 0x00021542
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD0_MSGID 0x00021543
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD0_ADDR 0x00021544
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD0_DATA 0x00021545
-
-#define REG_A6XX_PDC_GPU_TCS1_CONTROL 0x00021572
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK 0x00021573
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK 0x00021574
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID 0x00021575
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR 0x00021576
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD0_DATA 0x00021577
-
-#define REG_A6XX_PDC_GPU_TCS2_CONTROL 0x000215a4
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD_ENABLE_BANK 0x000215a5
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD_WAIT_FOR_CMPL_BANK 0x000215a6
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD0_MSGID 0x000215a7
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD0_ADDR 0x000215a8
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD0_DATA 0x000215a9
-
-#define REG_A6XX_PDC_GPU_TCS3_CONTROL 0x000215d6
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD_ENABLE_BANK 0x000215d7
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD_WAIT_FOR_CMPL_BANK 0x000215d8
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID 0x000215d9
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR 0x000215da
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD0_DATA 0x000215db
-
-#define REG_A6XX_PDC_GPU_SEQ_MEM_0 0x000a0000
-
#define REG_A6XX_X1_WINDOW_OFFSET 0x000088d4
#define A6XX_X1_WINDOW_OFFSET_WINDOW_OFFSET_DISABLE 0x80000000
#define A6XX_X1_WINDOW_OFFSET_X__MASK 0x00007fff
@@ -2200,6 +2097,8 @@ static inline uint32_t REG_A6XX_VSC_SIZE_REG(uint32_t i0) { return 0x00000c78 +
#define REG_A6XX_UCHE_UNKNOWN_0E12 0x00000e12
+#define REG_A6XX_GRAS_UNKNOWN_8000 0x00008000
+
#define REG_A6XX_GRAS_UNKNOWN_8001 0x00008001
#define REG_A6XX_GRAS_UNKNOWN_8004 0x00008004
@@ -2344,6 +2243,8 @@ static inline uint32_t A6XX_GRAS_SU_DEPTH_BUFFER_INFO_DEPTH_FORMAT(enum a6xx_dep
#define REG_A6XX_GRAS_UNKNOWN_809B 0x0000809b
+#define REG_A6XX_GRAS_UNKNOWN_80A0 0x000080a0
+
#define REG_A6XX_GRAS_RAS_MSAA_CNTL 0x000080a2
#define A6XX_GRAS_RAS_MSAA_CNTL_SAMPLES__MASK 0x00000003
#define A6XX_GRAS_RAS_MSAA_CNTL_SAMPLES__SHIFT 0
@@ -2464,6 +2365,8 @@ static inline uint32_t A6XX_GRAS_SC_WINDOW_SCISSOR_BR_Y(uint32_t val)
#define A6XX_GRAS_LRZ_CNTL_LRZ_WRITE 0x00000002
#define A6XX_GRAS_LRZ_CNTL_GREATER 0x00000004
+#define REG_A6XX_GRAS_UNKNOWN_8101 0x00008101
+
#define REG_A6XX_GRAS_2D_BLIT_INFO 0x00008102
#define A6XX_GRAS_2D_BLIT_INFO_COLOR_FORMAT__MASK 0x000000ff
#define A6XX_GRAS_2D_BLIT_INFO_COLOR_FORMAT__SHIFT 0
@@ -2494,6 +2397,10 @@ static inline uint32_t A6XX_GRAS_LRZ_BUFFER_PITCH_ARRAY_PITCH(uint32_t val)
#define REG_A6XX_GRAS_LRZ_FAST_CLEAR_BUFFER_BASE_HI 0x00008107
+#define REG_A6XX_GRAS_UNKNOWN_8109 0x00008109
+
+#define REG_A6XX_GRAS_UNKNOWN_8110 0x00008110
+
#define REG_A6XX_GRAS_2D_BLIT_CNTL 0x00008400
#define REG_A6XX_GRAS_2D_SRC_TL_X 0x00008401
@@ -2747,6 +2654,10 @@ static inline uint32_t A6XX_RB_DITHER_CNTL_DITHER_MODE_MRT7(enum adreno_rb_dithe
#define A6XX_RB_SRGB_CNTL_SRGB_MRT6 0x00000040
#define A6XX_RB_SRGB_CNTL_SRGB_MRT7 0x00000080
+#define REG_A6XX_RB_UNKNOWN_8810 0x00008810
+
+#define REG_A6XX_RB_UNKNOWN_8811 0x00008811
+
#define REG_A6XX_RB_UNKNOWN_8818 0x00008818
#define REG_A6XX_RB_UNKNOWN_8819 0x00008819
@@ -3177,14 +3088,14 @@ static inline uint32_t A6XX_RB_BLIT_DST_ARRAY_PITCH(uint32_t val)
#define REG_A6XX_RB_BLIT_INFO 0x000088e3
#define A6XX_RB_BLIT_INFO_UNK0 0x00000001
-#define A6XX_RB_BLIT_INFO_FAST_CLEAR 0x00000002
+#define A6XX_RB_BLIT_INFO_GMEM 0x00000002
#define A6XX_RB_BLIT_INFO_INTEGER 0x00000004
-#define A6XX_RB_BLIT_INFO_UNK3 0x00000008
-#define A6XX_RB_BLIT_INFO_MASK__MASK 0x000000f0
-#define A6XX_RB_BLIT_INFO_MASK__SHIFT 4
-static inline uint32_t A6XX_RB_BLIT_INFO_MASK(uint32_t val)
+#define A6XX_RB_BLIT_INFO_DEPTH 0x00000008
+#define A6XX_RB_BLIT_INFO_CLEAR_MASK__MASK 0x000000f0
+#define A6XX_RB_BLIT_INFO_CLEAR_MASK__SHIFT 4
+static inline uint32_t A6XX_RB_BLIT_INFO_CLEAR_MASK(uint32_t val)
{
- return ((val) << A6XX_RB_BLIT_INFO_MASK__SHIFT) & A6XX_RB_BLIT_INFO_MASK__MASK;
+ return ((val) << A6XX_RB_BLIT_INFO_CLEAR_MASK__SHIFT) & A6XX_RB_BLIT_INFO_CLEAR_MASK__MASK;
}
#define REG_A6XX_RB_UNKNOWN_88F0 0x000088f0
@@ -3274,12 +3185,16 @@ static inline uint32_t A6XX_RB_2D_DST_SIZE_PITCH(uint32_t val)
#define REG_A6XX_RB_UNKNOWN_8E01 0x00008e01
+#define REG_A6XX_RB_UNKNOWN_8E04 0x00008e04
+
#define REG_A6XX_RB_CCU_CNTL 0x00008e07
#define REG_A6XX_VPC_UNKNOWN_9101 0x00009101
#define REG_A6XX_VPC_GS_SIV_CNTL 0x00009104
+#define REG_A6XX_VPC_UNKNOWN_9107 0x00009107
+
#define REG_A6XX_VPC_UNKNOWN_9108 0x00009108
static inline uint32_t REG_A6XX_VPC_VARYING_INTERP(uint32_t i0) { return 0x00009200 + 0x1*i0; }
@@ -3385,6 +3300,8 @@ static inline uint32_t A6XX_VPC_CNTL_0_NUMNONPOSVAR(uint32_t val)
#define A6XX_VPC_SO_BUF_CNTL_BUF3 0x00000200
#define A6XX_VPC_SO_BUF_CNTL_ENABLE 0x00008000
+#define REG_A6XX_VPC_UNKNOWN_9306 0x00009306
+
#define REG_A6XX_VPC_UNKNOWN_9600 0x00009600
#define REG_A6XX_VPC_UNKNOWN_9602 0x00009602
@@ -3397,8 +3314,14 @@ static inline uint32_t A6XX_VPC_CNTL_0_NUMNONPOSVAR(uint32_t val)
#define REG_A6XX_PC_UNKNOWN_9805 0x00009805
+#define REG_A6XX_PC_UNKNOWN_9806 0x00009806
+
+#define REG_A6XX_PC_UNKNOWN_9980 0x00009980
+
#define REG_A6XX_PC_UNKNOWN_9981 0x00009981
+#define REG_A6XX_PC_UNKNOWN_9990 0x00009990
+
#define REG_A6XX_PC_PRIMITIVE_CNTL_0 0x00009b00
#define A6XX_PC_PRIMITIVE_CNTL_0_PRIMITIVE_RESTART 0x00000001
#define A6XX_PC_PRIMITIVE_CNTL_0_PROVOKING_VTX_LAST 0x00000002
@@ -3410,6 +3333,7 @@ static inline uint32_t A6XX_PC_PRIMITIVE_CNTL_1_STRIDE_IN_VPC(uint32_t val)
{
return ((val) << A6XX_PC_PRIMITIVE_CNTL_1_STRIDE_IN_VPC__SHIFT) & A6XX_PC_PRIMITIVE_CNTL_1_STRIDE_IN_VPC__MASK;
}
+#define A6XX_PC_PRIMITIVE_CNTL_1_PSIZE 0x00000100
#define REG_A6XX_PC_UNKNOWN_9B06 0x00009b06
@@ -3488,6 +3412,8 @@ static inline uint32_t A6XX_VFD_CONTROL_3_REGID_TESSY(uint32_t val)
#define REG_A6XX_VFD_UNKNOWN_A008 0x0000a008
+#define REG_A6XX_VFD_UNKNOWN_A009 0x0000a009
+
#define REG_A6XX_VFD_INDEX_OFFSET 0x0000a00e
#define REG_A6XX_VFD_INSTANCE_START_OFFSET 0x0000a00f
@@ -3640,6 +3566,8 @@ static inline uint32_t A6XX_SP_VS_CTRL_REG0_THREADSIZE(enum a3xx_threadsize val)
#define A6XX_SP_VS_CTRL_REG0_PIXLODENABLE 0x04000000
#define A6XX_SP_VS_CTRL_REG0_MERGEDREGS 0x80000000
+#define REG_A6XX_SP_UNKNOWN_A81B 0x0000a81b
+
#define REG_A6XX_SP_VS_OBJ_START_LO 0x0000a81c
#define REG_A6XX_SP_VS_OBJ_START_HI 0x0000a81d
@@ -3884,6 +3812,8 @@ static inline uint32_t A6XX_SP_FS_CTRL_REG0_THREADSIZE(enum a3xx_threadsize val)
#define A6XX_SP_FS_CTRL_REG0_PIXLODENABLE 0x04000000
#define A6XX_SP_FS_CTRL_REG0_MERGEDREGS 0x80000000
+#define REG_A6XX_SP_UNKNOWN_A982 0x0000a982
+
#define REG_A6XX_SP_FS_OBJ_START_LO 0x0000a983
#define REG_A6XX_SP_FS_OBJ_START_HI 0x0000a984
@@ -3981,6 +3911,8 @@ static inline uint32_t A6XX_SP_FS_MRT_REG_COLOR_FORMAT(enum a6xx_color_fmt val)
#define A6XX_SP_FS_MRT_REG_COLOR_UINT 0x00000200
#define A6XX_SP_FS_MRT_REG_COLOR_SRGB 0x00000400
+#define REG_A6XX_SP_UNKNOWN_A99E 0x0000a99e
+
#define REG_A6XX_SP_FS_TEX_COUNT 0x0000a9a7
#define REG_A6XX_SP_UNKNOWN_A9A8 0x0000a9a8
@@ -4066,14 +3998,20 @@ static inline uint32_t A6XX_SP_FS_CONFIG_NSAMP(uint32_t val)
#define REG_A6XX_SP_FS_INSTRLEN 0x0000ab05
+#define REG_A6XX_SP_UNKNOWN_AB20 0x0000ab20
+
#define REG_A6XX_SP_UNKNOWN_AE00 0x0000ae00
+#define REG_A6XX_SP_UNKNOWN_AE03 0x0000ae03
+
#define REG_A6XX_SP_UNKNOWN_AE04 0x0000ae04
#define REG_A6XX_SP_UNKNOWN_AE0F 0x0000ae0f
#define REG_A6XX_SP_UNKNOWN_B182 0x0000b182
+#define REG_A6XX_SP_UNKNOWN_B183 0x0000b183
+
#define REG_A6XX_SP_TP_RAS_MSAA_CNTL 0x0000b300
#define A6XX_SP_TP_RAS_MSAA_CNTL_SAMPLES__MASK 0x00000003
#define A6XX_SP_TP_RAS_MSAA_CNTL_SAMPLES__SHIFT 0
@@ -4097,6 +4035,8 @@ static inline uint32_t A6XX_SP_TP_DEST_MSAA_CNTL_SAMPLES(enum a3xx_msaa_samples
#define REG_A6XX_SP_TP_UNKNOWN_B304 0x0000b304
+#define REG_A6XX_SP_TP_UNKNOWN_B309 0x0000b309
+
#define REG_A6XX_SP_PS_2D_SRC_INFO 0x0000b4c0
#define A6XX_SP_PS_2D_SRC_INFO_COLOR_FORMAT__MASK 0x000000ff
#define A6XX_SP_PS_2D_SRC_INFO_COLOR_FORMAT__SHIFT 0
@@ -4162,6 +4102,8 @@ static inline uint32_t A6XX_HLSQ_GS_CNTL_CONSTLEN(uint32_t val)
return ((val >> 2) << A6XX_HLSQ_GS_CNTL_CONSTLEN__SHIFT) & A6XX_HLSQ_GS_CNTL_CONSTLEN__MASK;
}
+#define REG_A6XX_HLSQ_UNKNOWN_B980 0x0000b980
+
#define REG_A6XX_HLSQ_CONTROL_1_REG 0x0000b982
#define REG_A6XX_HLSQ_CONTROL_2_REG 0x0000b983
@@ -4558,5 +4500,227 @@ static inline uint32_t A6XX_TEX_CONST_8_BASE_HI(uint32_t val)
#define REG_A6XX_TEX_CONST_15 0x0000000f
+#define REG_A6XX_PDC_GPU_ENABLE_PDC 0x00001140
+
+#define REG_A6XX_PDC_GPU_SEQ_START_ADDR 0x00001148
+
+#define REG_A6XX_PDC_GPU_TCS0_CONTROL 0x00001540
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD_ENABLE_BANK 0x00001541
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD_WAIT_FOR_CMPL_BANK 0x00001542
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD0_MSGID 0x00001543
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD0_ADDR 0x00001544
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD0_DATA 0x00001545
+
+#define REG_A6XX_PDC_GPU_TCS1_CONTROL 0x00001572
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK 0x00001573
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK 0x00001574
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID 0x00001575
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR 0x00001576
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD0_DATA 0x00001577
+
+#define REG_A6XX_PDC_GPU_TCS2_CONTROL 0x000015a4
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD_ENABLE_BANK 0x000015a5
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD_WAIT_FOR_CMPL_BANK 0x000015a6
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD0_MSGID 0x000015a7
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD0_ADDR 0x000015a8
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD0_DATA 0x000015a9
+
+#define REG_A6XX_PDC_GPU_TCS3_CONTROL 0x000015d6
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD_ENABLE_BANK 0x000015d7
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD_WAIT_FOR_CMPL_BANK 0x000015d8
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID 0x000015d9
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR 0x000015da
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD0_DATA 0x000015db
+
+#define REG_A6XX_PDC_GPU_SEQ_MEM_0 0x00000000
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_A 0x00000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__MASK 0x000000ff
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__MASK 0x0000ff00
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__SHIFT 8
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_B 0x00000001
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_C 0x00000002
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_D 0x00000003
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLT 0x00000004
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK 0x0000003f
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK 0x00007000
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT 12
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK 0xf0000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT 28
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLM 0x00000005
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK 0x0f000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT 24
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_0 0x00000008
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_1 0x00000009
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_2 0x0000000a
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_3 0x0000000b
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_0 0x0000000c
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_1 0x0000000d
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_2 0x0000000e
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_3 0x0000000f
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0 0x00000010
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK 0x0000000f
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK 0x000000f0
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT 4
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK 0x00000f00
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT 8
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK 0x0000f000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT 12
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK 0x000f0000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT 16
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK 0x00f00000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT 20
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK 0x0f000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT 24
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK 0xf0000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT 28
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1 0x00000011
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK 0x0000000f
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK 0x000000f0
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT 4
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK 0x00000f00
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT 8
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK 0x0000f000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT 12
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK 0x000f0000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT 16
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK 0x00f00000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT 20
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK 0x0f000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT 24
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK 0xf0000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT 28
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF1 0x0000002f
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF2 0x00000030
+
#endif /* A6XX_XML */
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
index ef68098d2adc..83ffccef2506 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
@@ -8,17 +8,17 @@ This file was generated by the rules-ng-ng headergen tool in this git repository
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/envytools/rnndb/adreno.xml ( 501 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/freedreno_copyright.xml ( 1572 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a2xx.xml ( 36805 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_common.xml ( 13634 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a3xx.xml ( 83840 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a4xx.xml ( 112086 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a5xx.xml ( 147240 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx.xml ( 101627 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/ocmem.xml ( 1773 bytes, from 2018-07-03 19:37:13)
+- ./adreno.xml ( 501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 147240 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a6xx.xml ( 107570 bytes, from 2018-08-16 17:32:18)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-08-16 17:35:55)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
Copyright (C) 2013-2018 by the following authors:
- Rob Clark <robdclark@gmail.com> (robclark)
@@ -167,8 +167,8 @@ static inline uint32_t A6XX_GMU_PWR_COL_INTER_FRAME_CTRL_MIN_PASS_LENGTH(uint32_
#define REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS 0x000050d0
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWERING_OFF 0x00000001
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWERING_ON 0x00000002
-#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_ON 0x00000004
-#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF 0x00000008
+#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF 0x00000004
+#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_ON 0x00000008
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SP_CLOCK_OFF 0x00000010
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GMU_UP_POWER_STATE 0x00000020
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_GDSC_POWER_OFF 0x00000040
--
2.18.0
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH 1/9] drm/msm/a6xx: rnndb updates for a6xx
@ 2018-08-27 15:11 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: linux-arm-kernel
Update the register definitions for a6xx from the rnndb database.
Changes include new enums for upcoming devcoredump support, moving
the PDC and GCC_GX register definitions to their own domain and
various other register updates and additions.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 642 ++++++++++++++--------
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 26 +-
2 files changed, 416 insertions(+), 252 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index 87eab51f7000..7acc57b2c1be 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -8,17 +8,17 @@ This file was generated by the rules-ng-ng headergen tool in this git repository
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/envytools/rnndb/adreno.xml ( 501 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/freedreno_copyright.xml ( 1572 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a2xx.xml ( 36805 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_common.xml ( 13634 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a3xx.xml ( 83840 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a4xx.xml ( 112086 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a5xx.xml ( 147240 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx.xml ( 101627 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/ocmem.xml ( 1773 bytes, from 2018-07-03 19:37:13)
+- ./adreno.xml ( 501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 147240 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a6xx.xml ( 107521 bytes, from 2018-08-16 17:44:50)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-08-16 17:44:26)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
Copyright (C) 2013-2018 by the following authors:
- Rob Clark <robdclark@gmail.com> (robclark)
@@ -272,6 +272,98 @@ enum a6xx_cp_perfcounter_select {
PERF_CP_ALWAYS_COUNT = 0,
};
+enum a6xx_shader_id {
+ A6XX_TP0_TMO_DATA = 9,
+ A6XX_TP0_SMO_DATA = 10,
+ A6XX_TP0_MIPMAP_BASE_DATA = 11,
+ A6XX_TP1_TMO_DATA = 25,
+ A6XX_TP1_SMO_DATA = 26,
+ A6XX_TP1_MIPMAP_BASE_DATA = 27,
+ A6XX_SP_INST_DATA = 41,
+ A6XX_SP_LB_0_DATA = 42,
+ A6XX_SP_LB_1_DATA = 43,
+ A6XX_SP_LB_2_DATA = 44,
+ A6XX_SP_LB_3_DATA = 45,
+ A6XX_SP_LB_4_DATA = 46,
+ A6XX_SP_LB_5_DATA = 47,
+ A6XX_SP_CB_BINDLESS_DATA = 48,
+ A6XX_SP_CB_LEGACY_DATA = 49,
+ A6XX_SP_UAV_DATA = 50,
+ A6XX_SP_INST_TAG = 51,
+ A6XX_SP_CB_BINDLESS_TAG = 52,
+ A6XX_SP_TMO_UMO_TAG = 53,
+ A6XX_SP_SMO_TAG = 54,
+ A6XX_SP_STATE_DATA = 55,
+ A6XX_HLSQ_CHUNK_CVS_RAM = 73,
+ A6XX_HLSQ_CHUNK_CPS_RAM = 74,
+ A6XX_HLSQ_CHUNK_CVS_RAM_TAG = 75,
+ A6XX_HLSQ_CHUNK_CPS_RAM_TAG = 76,
+ A6XX_HLSQ_ICB_CVS_CB_BASE_TAG = 77,
+ A6XX_HLSQ_ICB_CPS_CB_BASE_TAG = 78,
+ A6XX_HLSQ_CVS_MISC_RAM = 80,
+ A6XX_HLSQ_CPS_MISC_RAM = 81,
+ A6XX_HLSQ_INST_RAM = 82,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM = 83,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM = 84,
+ A6XX_HLSQ_CVS_MISC_RAM_TAG = 85,
+ A6XX_HLSQ_CPS_MISC_RAM_TAG = 86,
+ A6XX_HLSQ_INST_RAM_TAG = 87,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM_TAG = 88,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM_TAG = 89,
+ A6XX_HLSQ_PWR_REST_RAM = 90,
+ A6XX_HLSQ_PWR_REST_TAG = 91,
+ A6XX_HLSQ_DATAPATH_META = 96,
+ A6XX_HLSQ_FRONTEND_META = 97,
+ A6XX_HLSQ_INDIRECT_META = 98,
+ A6XX_HLSQ_BACKEND_META = 99,
+};
+
+enum a6xx_debugbus_id {
+ A6XX_DBGBUS_CP = 1,
+ A6XX_DBGBUS_RBBM = 2,
+ A6XX_DBGBUS_VBIF = 3,
+ A6XX_DBGBUS_HLSQ = 4,
+ A6XX_DBGBUS_UCHE = 5,
+ A6XX_DBGBUS_DPM = 6,
+ A6XX_DBGBUS_TESS = 7,
+ A6XX_DBGBUS_PC = 8,
+ A6XX_DBGBUS_VFDP = 9,
+ A6XX_DBGBUS_VPC = 10,
+ A6XX_DBGBUS_TSE = 11,
+ A6XX_DBGBUS_RAS = 12,
+ A6XX_DBGBUS_VSC = 13,
+ A6XX_DBGBUS_COM = 14,
+ A6XX_DBGBUS_LRZ = 16,
+ A6XX_DBGBUS_A2D = 17,
+ A6XX_DBGBUS_CCUFCHE = 18,
+ A6XX_DBGBUS_GMU_CX = 19,
+ A6XX_DBGBUS_RBP = 20,
+ A6XX_DBGBUS_DCS = 21,
+ A6XX_DBGBUS_DBGC = 22,
+ A6XX_DBGBUS_CX = 23,
+ A6XX_DBGBUS_GMU_GX = 24,
+ A6XX_DBGBUS_TPFCHE = 25,
+ A6XX_DBGBUS_GBIF_GX = 26,
+ A6XX_DBGBUS_GPC = 29,
+ A6XX_DBGBUS_LARC = 30,
+ A6XX_DBGBUS_HLSQ_SPTP = 31,
+ A6XX_DBGBUS_RB_0 = 32,
+ A6XX_DBGBUS_RB_1 = 33,
+ A6XX_DBGBUS_UCHE_WRAPPER = 36,
+ A6XX_DBGBUS_CCU_0 = 40,
+ A6XX_DBGBUS_CCU_1 = 41,
+ A6XX_DBGBUS_VFD_0 = 56,
+ A6XX_DBGBUS_VFD_1 = 57,
+ A6XX_DBGBUS_VFD_2 = 58,
+ A6XX_DBGBUS_VFD_3 = 59,
+ A6XX_DBGBUS_SP_0 = 64,
+ A6XX_DBGBUS_SP_1 = 65,
+ A6XX_DBGBUS_TPL1_0 = 72,
+ A6XX_DBGBUS_TPL1_1 = 73,
+ A6XX_DBGBUS_TPL1_2 = 74,
+ A6XX_DBGBUS_TPL1_3 = 75,
+};
+
enum a6xx_tex_filter {
A6XX_TEX_NEAREST = 0,
A6XX_TEX_LINEAR = 1,
@@ -1765,12 +1857,39 @@ static inline uint32_t A6XX_UCHE_CLIENT_PF_PERFSEL(uint32_t val)
#define REG_A6XX_VBIF_VERSION 0x00003000
+#define REG_A6XX_VBIF_CLKON 0x00003001
+#define A6XX_VBIF_CLKON_FORCE_ON_TESTBUS 0x00000002
+
#define REG_A6XX_VBIF_GATE_OFF_WRREQ_EN 0x0000302a
#define REG_A6XX_VBIF_XIN_HALT_CTRL0 0x00003080
#define REG_A6XX_VBIF_XIN_HALT_CTRL1 0x00003081
+#define REG_A6XX_VBIF_TEST_BUS_OUT_CTRL 0x00003084
+
+#define REG_A6XX_VBIF_TEST_BUS1_CTRL0 0x00003085
+
+#define REG_A6XX_VBIF_TEST_BUS1_CTRL1 0x00003086
+#define A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__MASK 0x0000000f
+#define A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__SHIFT 0
+static inline uint32_t A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL(uint32_t val)
+{
+ return ((val) << A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__SHIFT) & A6XX_VBIF_TEST_BUS1_CTRL1_DATA_SEL__MASK;
+}
+
+#define REG_A6XX_VBIF_TEST_BUS2_CTRL0 0x00003087
+
+#define REG_A6XX_VBIF_TEST_BUS2_CTRL1 0x00003088
+#define A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__MASK 0x000001ff
+#define A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__SHIFT 0
+static inline uint32_t A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL(uint32_t val)
+{
+ return ((val) << A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__SHIFT) & A6XX_VBIF_TEST_BUS2_CTRL1_DATA_SEL__MASK;
+}
+
+#define REG_A6XX_VBIF_TEST_BUS_OUT 0x0000308c
+
#define REG_A6XX_VBIF_PERF_CNT_SEL0 0x000030d0
#define REG_A6XX_VBIF_PERF_CNT_SEL1 0x000030d1
@@ -1813,228 +1932,6 @@ static inline uint32_t A6XX_UCHE_CLIENT_PF_PERFSEL(uint32_t val)
#define REG_A6XX_VBIF_PERF_PWR_CNT_HIGH2 0x0000311a
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_A 0x00018400
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_B 0x00018401
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_C 0x00018402
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_D 0x00018403
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__MASK 0x000000ff
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_INDEX__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__MASK 0x0000ff00
-#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__SHIFT 8
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_D_PING_BLK_SEL__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLT 0x00018404
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK 0x0000003f
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK 0x00007000
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT 12
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK 0xf0000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT 28
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLM 0x00018405
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK 0x0f000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT 24
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_0 0x00018408
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_1 0x00018409
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_2 0x0001840a
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_3 0x0001840b
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_0 0x0001840c
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_1 0x0001840d
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_2 0x0001840e
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_3 0x0001840f
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0 0x00018410
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK 0x0000000f
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK 0x000000f0
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT 4
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK 0x00000f00
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT 8
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK 0x0000f000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT 12
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK 0x000f0000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT 16
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK 0x00f00000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT 20
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK 0x0f000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT 24
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK 0xf0000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT 28
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1 0x00018411
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK 0x0000000f
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT 0
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK 0x000000f0
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT 4
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK 0x00000f00
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT 8
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK 0x0000f000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT 12
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK 0x000f0000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT 16
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK 0x00f00000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT 20
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK 0x0f000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT 24
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK;
-}
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK 0xf0000000
-#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT 28
-static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15(uint32_t val)
-{
- return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK;
-}
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF1 0x0001842f
-
-#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF2 0x00018430
-
-#define REG_A6XX_PDC_GPU_ENABLE_PDC 0x00021140
-
-#define REG_A6XX_PDC_GPU_SEQ_START_ADDR 0x00021148
-
-#define REG_A6XX_PDC_GPU_TCS0_CONTROL 0x00021540
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD_ENABLE_BANK 0x00021541
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD_WAIT_FOR_CMPL_BANK 0x00021542
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD0_MSGID 0x00021543
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD0_ADDR 0x00021544
-
-#define REG_A6XX_PDC_GPU_TCS0_CMD0_DATA 0x00021545
-
-#define REG_A6XX_PDC_GPU_TCS1_CONTROL 0x00021572
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK 0x00021573
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK 0x00021574
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID 0x00021575
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR 0x00021576
-
-#define REG_A6XX_PDC_GPU_TCS1_CMD0_DATA 0x00021577
-
-#define REG_A6XX_PDC_GPU_TCS2_CONTROL 0x000215a4
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD_ENABLE_BANK 0x000215a5
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD_WAIT_FOR_CMPL_BANK 0x000215a6
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD0_MSGID 0x000215a7
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD0_ADDR 0x000215a8
-
-#define REG_A6XX_PDC_GPU_TCS2_CMD0_DATA 0x000215a9
-
-#define REG_A6XX_PDC_GPU_TCS3_CONTROL 0x000215d6
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD_ENABLE_BANK 0x000215d7
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD_WAIT_FOR_CMPL_BANK 0x000215d8
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID 0x000215d9
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR 0x000215da
-
-#define REG_A6XX_PDC_GPU_TCS3_CMD0_DATA 0x000215db
-
-#define REG_A6XX_PDC_GPU_SEQ_MEM_0 0x000a0000
-
#define REG_A6XX_X1_WINDOW_OFFSET 0x000088d4
#define A6XX_X1_WINDOW_OFFSET_WINDOW_OFFSET_DISABLE 0x80000000
#define A6XX_X1_WINDOW_OFFSET_X__MASK 0x00007fff
@@ -2200,6 +2097,8 @@ static inline uint32_t REG_A6XX_VSC_SIZE_REG(uint32_t i0) { return 0x00000c78 +
#define REG_A6XX_UCHE_UNKNOWN_0E12 0x00000e12
+#define REG_A6XX_GRAS_UNKNOWN_8000 0x00008000
+
#define REG_A6XX_GRAS_UNKNOWN_8001 0x00008001
#define REG_A6XX_GRAS_UNKNOWN_8004 0x00008004
@@ -2344,6 +2243,8 @@ static inline uint32_t A6XX_GRAS_SU_DEPTH_BUFFER_INFO_DEPTH_FORMAT(enum a6xx_dep
#define REG_A6XX_GRAS_UNKNOWN_809B 0x0000809b
+#define REG_A6XX_GRAS_UNKNOWN_80A0 0x000080a0
+
#define REG_A6XX_GRAS_RAS_MSAA_CNTL 0x000080a2
#define A6XX_GRAS_RAS_MSAA_CNTL_SAMPLES__MASK 0x00000003
#define A6XX_GRAS_RAS_MSAA_CNTL_SAMPLES__SHIFT 0
@@ -2464,6 +2365,8 @@ static inline uint32_t A6XX_GRAS_SC_WINDOW_SCISSOR_BR_Y(uint32_t val)
#define A6XX_GRAS_LRZ_CNTL_LRZ_WRITE 0x00000002
#define A6XX_GRAS_LRZ_CNTL_GREATER 0x00000004
+#define REG_A6XX_GRAS_UNKNOWN_8101 0x00008101
+
#define REG_A6XX_GRAS_2D_BLIT_INFO 0x00008102
#define A6XX_GRAS_2D_BLIT_INFO_COLOR_FORMAT__MASK 0x000000ff
#define A6XX_GRAS_2D_BLIT_INFO_COLOR_FORMAT__SHIFT 0
@@ -2494,6 +2397,10 @@ static inline uint32_t A6XX_GRAS_LRZ_BUFFER_PITCH_ARRAY_PITCH(uint32_t val)
#define REG_A6XX_GRAS_LRZ_FAST_CLEAR_BUFFER_BASE_HI 0x00008107
+#define REG_A6XX_GRAS_UNKNOWN_8109 0x00008109
+
+#define REG_A6XX_GRAS_UNKNOWN_8110 0x00008110
+
#define REG_A6XX_GRAS_2D_BLIT_CNTL 0x00008400
#define REG_A6XX_GRAS_2D_SRC_TL_X 0x00008401
@@ -2747,6 +2654,10 @@ static inline uint32_t A6XX_RB_DITHER_CNTL_DITHER_MODE_MRT7(enum adreno_rb_dithe
#define A6XX_RB_SRGB_CNTL_SRGB_MRT6 0x00000040
#define A6XX_RB_SRGB_CNTL_SRGB_MRT7 0x00000080
+#define REG_A6XX_RB_UNKNOWN_8810 0x00008810
+
+#define REG_A6XX_RB_UNKNOWN_8811 0x00008811
+
#define REG_A6XX_RB_UNKNOWN_8818 0x00008818
#define REG_A6XX_RB_UNKNOWN_8819 0x00008819
@@ -3177,14 +3088,14 @@ static inline uint32_t A6XX_RB_BLIT_DST_ARRAY_PITCH(uint32_t val)
#define REG_A6XX_RB_BLIT_INFO 0x000088e3
#define A6XX_RB_BLIT_INFO_UNK0 0x00000001
-#define A6XX_RB_BLIT_INFO_FAST_CLEAR 0x00000002
+#define A6XX_RB_BLIT_INFO_GMEM 0x00000002
#define A6XX_RB_BLIT_INFO_INTEGER 0x00000004
-#define A6XX_RB_BLIT_INFO_UNK3 0x00000008
-#define A6XX_RB_BLIT_INFO_MASK__MASK 0x000000f0
-#define A6XX_RB_BLIT_INFO_MASK__SHIFT 4
-static inline uint32_t A6XX_RB_BLIT_INFO_MASK(uint32_t val)
+#define A6XX_RB_BLIT_INFO_DEPTH 0x00000008
+#define A6XX_RB_BLIT_INFO_CLEAR_MASK__MASK 0x000000f0
+#define A6XX_RB_BLIT_INFO_CLEAR_MASK__SHIFT 4
+static inline uint32_t A6XX_RB_BLIT_INFO_CLEAR_MASK(uint32_t val)
{
- return ((val) << A6XX_RB_BLIT_INFO_MASK__SHIFT) & A6XX_RB_BLIT_INFO_MASK__MASK;
+ return ((val) << A6XX_RB_BLIT_INFO_CLEAR_MASK__SHIFT) & A6XX_RB_BLIT_INFO_CLEAR_MASK__MASK;
}
#define REG_A6XX_RB_UNKNOWN_88F0 0x000088f0
@@ -3274,12 +3185,16 @@ static inline uint32_t A6XX_RB_2D_DST_SIZE_PITCH(uint32_t val)
#define REG_A6XX_RB_UNKNOWN_8E01 0x00008e01
+#define REG_A6XX_RB_UNKNOWN_8E04 0x00008e04
+
#define REG_A6XX_RB_CCU_CNTL 0x00008e07
#define REG_A6XX_VPC_UNKNOWN_9101 0x00009101
#define REG_A6XX_VPC_GS_SIV_CNTL 0x00009104
+#define REG_A6XX_VPC_UNKNOWN_9107 0x00009107
+
#define REG_A6XX_VPC_UNKNOWN_9108 0x00009108
static inline uint32_t REG_A6XX_VPC_VARYING_INTERP(uint32_t i0) { return 0x00009200 + 0x1*i0; }
@@ -3385,6 +3300,8 @@ static inline uint32_t A6XX_VPC_CNTL_0_NUMNONPOSVAR(uint32_t val)
#define A6XX_VPC_SO_BUF_CNTL_BUF3 0x00000200
#define A6XX_VPC_SO_BUF_CNTL_ENABLE 0x00008000
+#define REG_A6XX_VPC_UNKNOWN_9306 0x00009306
+
#define REG_A6XX_VPC_UNKNOWN_9600 0x00009600
#define REG_A6XX_VPC_UNKNOWN_9602 0x00009602
@@ -3397,8 +3314,14 @@ static inline uint32_t A6XX_VPC_CNTL_0_NUMNONPOSVAR(uint32_t val)
#define REG_A6XX_PC_UNKNOWN_9805 0x00009805
+#define REG_A6XX_PC_UNKNOWN_9806 0x00009806
+
+#define REG_A6XX_PC_UNKNOWN_9980 0x00009980
+
#define REG_A6XX_PC_UNKNOWN_9981 0x00009981
+#define REG_A6XX_PC_UNKNOWN_9990 0x00009990
+
#define REG_A6XX_PC_PRIMITIVE_CNTL_0 0x00009b00
#define A6XX_PC_PRIMITIVE_CNTL_0_PRIMITIVE_RESTART 0x00000001
#define A6XX_PC_PRIMITIVE_CNTL_0_PROVOKING_VTX_LAST 0x00000002
@@ -3410,6 +3333,7 @@ static inline uint32_t A6XX_PC_PRIMITIVE_CNTL_1_STRIDE_IN_VPC(uint32_t val)
{
return ((val) << A6XX_PC_PRIMITIVE_CNTL_1_STRIDE_IN_VPC__SHIFT) & A6XX_PC_PRIMITIVE_CNTL_1_STRIDE_IN_VPC__MASK;
}
+#define A6XX_PC_PRIMITIVE_CNTL_1_PSIZE 0x00000100
#define REG_A6XX_PC_UNKNOWN_9B06 0x00009b06
@@ -3488,6 +3412,8 @@ static inline uint32_t A6XX_VFD_CONTROL_3_REGID_TESSY(uint32_t val)
#define REG_A6XX_VFD_UNKNOWN_A008 0x0000a008
+#define REG_A6XX_VFD_UNKNOWN_A009 0x0000a009
+
#define REG_A6XX_VFD_INDEX_OFFSET 0x0000a00e
#define REG_A6XX_VFD_INSTANCE_START_OFFSET 0x0000a00f
@@ -3640,6 +3566,8 @@ static inline uint32_t A6XX_SP_VS_CTRL_REG0_THREADSIZE(enum a3xx_threadsize val)
#define A6XX_SP_VS_CTRL_REG0_PIXLODENABLE 0x04000000
#define A6XX_SP_VS_CTRL_REG0_MERGEDREGS 0x80000000
+#define REG_A6XX_SP_UNKNOWN_A81B 0x0000a81b
+
#define REG_A6XX_SP_VS_OBJ_START_LO 0x0000a81c
#define REG_A6XX_SP_VS_OBJ_START_HI 0x0000a81d
@@ -3884,6 +3812,8 @@ static inline uint32_t A6XX_SP_FS_CTRL_REG0_THREADSIZE(enum a3xx_threadsize val)
#define A6XX_SP_FS_CTRL_REG0_PIXLODENABLE 0x04000000
#define A6XX_SP_FS_CTRL_REG0_MERGEDREGS 0x80000000
+#define REG_A6XX_SP_UNKNOWN_A982 0x0000a982
+
#define REG_A6XX_SP_FS_OBJ_START_LO 0x0000a983
#define REG_A6XX_SP_FS_OBJ_START_HI 0x0000a984
@@ -3981,6 +3911,8 @@ static inline uint32_t A6XX_SP_FS_MRT_REG_COLOR_FORMAT(enum a6xx_color_fmt val)
#define A6XX_SP_FS_MRT_REG_COLOR_UINT 0x00000200
#define A6XX_SP_FS_MRT_REG_COLOR_SRGB 0x00000400
+#define REG_A6XX_SP_UNKNOWN_A99E 0x0000a99e
+
#define REG_A6XX_SP_FS_TEX_COUNT 0x0000a9a7
#define REG_A6XX_SP_UNKNOWN_A9A8 0x0000a9a8
@@ -4066,14 +3998,20 @@ static inline uint32_t A6XX_SP_FS_CONFIG_NSAMP(uint32_t val)
#define REG_A6XX_SP_FS_INSTRLEN 0x0000ab05
+#define REG_A6XX_SP_UNKNOWN_AB20 0x0000ab20
+
#define REG_A6XX_SP_UNKNOWN_AE00 0x0000ae00
+#define REG_A6XX_SP_UNKNOWN_AE03 0x0000ae03
+
#define REG_A6XX_SP_UNKNOWN_AE04 0x0000ae04
#define REG_A6XX_SP_UNKNOWN_AE0F 0x0000ae0f
#define REG_A6XX_SP_UNKNOWN_B182 0x0000b182
+#define REG_A6XX_SP_UNKNOWN_B183 0x0000b183
+
#define REG_A6XX_SP_TP_RAS_MSAA_CNTL 0x0000b300
#define A6XX_SP_TP_RAS_MSAA_CNTL_SAMPLES__MASK 0x00000003
#define A6XX_SP_TP_RAS_MSAA_CNTL_SAMPLES__SHIFT 0
@@ -4097,6 +4035,8 @@ static inline uint32_t A6XX_SP_TP_DEST_MSAA_CNTL_SAMPLES(enum a3xx_msaa_samples
#define REG_A6XX_SP_TP_UNKNOWN_B304 0x0000b304
+#define REG_A6XX_SP_TP_UNKNOWN_B309 0x0000b309
+
#define REG_A6XX_SP_PS_2D_SRC_INFO 0x0000b4c0
#define A6XX_SP_PS_2D_SRC_INFO_COLOR_FORMAT__MASK 0x000000ff
#define A6XX_SP_PS_2D_SRC_INFO_COLOR_FORMAT__SHIFT 0
@@ -4162,6 +4102,8 @@ static inline uint32_t A6XX_HLSQ_GS_CNTL_CONSTLEN(uint32_t val)
return ((val >> 2) << A6XX_HLSQ_GS_CNTL_CONSTLEN__SHIFT) & A6XX_HLSQ_GS_CNTL_CONSTLEN__MASK;
}
+#define REG_A6XX_HLSQ_UNKNOWN_B980 0x0000b980
+
#define REG_A6XX_HLSQ_CONTROL_1_REG 0x0000b982
#define REG_A6XX_HLSQ_CONTROL_2_REG 0x0000b983
@@ -4558,5 +4500,227 @@ static inline uint32_t A6XX_TEX_CONST_8_BASE_HI(uint32_t val)
#define REG_A6XX_TEX_CONST_15 0x0000000f
+#define REG_A6XX_PDC_GPU_ENABLE_PDC 0x00001140
+
+#define REG_A6XX_PDC_GPU_SEQ_START_ADDR 0x00001148
+
+#define REG_A6XX_PDC_GPU_TCS0_CONTROL 0x00001540
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD_ENABLE_BANK 0x00001541
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD_WAIT_FOR_CMPL_BANK 0x00001542
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD0_MSGID 0x00001543
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD0_ADDR 0x00001544
+
+#define REG_A6XX_PDC_GPU_TCS0_CMD0_DATA 0x00001545
+
+#define REG_A6XX_PDC_GPU_TCS1_CONTROL 0x00001572
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK 0x00001573
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK 0x00001574
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID 0x00001575
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR 0x00001576
+
+#define REG_A6XX_PDC_GPU_TCS1_CMD0_DATA 0x00001577
+
+#define REG_A6XX_PDC_GPU_TCS2_CONTROL 0x000015a4
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD_ENABLE_BANK 0x000015a5
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD_WAIT_FOR_CMPL_BANK 0x000015a6
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD0_MSGID 0x000015a7
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD0_ADDR 0x000015a8
+
+#define REG_A6XX_PDC_GPU_TCS2_CMD0_DATA 0x000015a9
+
+#define REG_A6XX_PDC_GPU_TCS3_CONTROL 0x000015d6
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD_ENABLE_BANK 0x000015d7
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD_WAIT_FOR_CMPL_BANK 0x000015d8
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID 0x000015d9
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR 0x000015da
+
+#define REG_A6XX_PDC_GPU_TCS3_CMD0_DATA 0x000015db
+
+#define REG_A6XX_PDC_GPU_SEQ_MEM_0 0x00000000
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_A 0x00000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__MASK 0x000000ff
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_INDEX__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__MASK 0x0000ff00
+#define A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__SHIFT 8
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_SEL_A_PING_BLK_SEL__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_B 0x00000001
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_C 0x00000002
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_SEL_D 0x00000003
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLT 0x00000004
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK 0x0000003f
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_TRACEEN__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK 0x00007000
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT 12
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_GRANU__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK 0xf0000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT 28
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLT_SEGT__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_CNTLM 0x00000005
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK 0x0f000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT 24
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_CNTLM_ENABLE__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_0 0x00000008
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_1 0x00000009
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_2 0x0000000a
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_IVTL_3 0x0000000b
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_0 0x0000000c
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_1 0x0000000d
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_2 0x0000000e
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_MASKL_3 0x0000000f
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0 0x00000010
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK 0x0000000f
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL0__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK 0x000000f0
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT 4
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL1__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK 0x00000f00
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT 8
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL2__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK 0x0000f000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT 12
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL3__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK 0x000f0000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT 16
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL4__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK 0x00f00000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT 20
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL5__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK 0x0f000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT 24
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL6__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK 0xf0000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT 28
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_0_BYTEL7__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1 0x00000011
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK 0x0000000f
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT 0
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL8__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK 0x000000f0
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT 4
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL9__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK 0x00000f00
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT 8
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL10__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK 0x0000f000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT 12
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL11__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK 0x000f0000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT 16
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL12__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK 0x00f00000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT 20
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL13__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK 0x0f000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT 24
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL14__MASK;
+}
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK 0xf0000000
+#define A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT 28
+static inline uint32_t A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15(uint32_t val)
+{
+ return ((val) << A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__SHIFT) & A6XX_CX_DBGC_CFG_DBGBUS_BYTEL_1_BYTEL15__MASK;
+}
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF1 0x0000002f
+
+#define REG_A6XX_CX_DBGC_CFG_DBGBUS_TRACE_BUF2 0x00000030
+
#endif /* A6XX_XML */
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
index ef68098d2adc..83ffccef2506 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h
@@ -8,17 +8,17 @@ This file was generated by the rules-ng-ng headergen tool in this git repository
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/envytools/rnndb/adreno.xml ( 501 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/freedreno_copyright.xml ( 1572 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a2xx.xml ( 36805 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_common.xml ( 13634 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a3xx.xml ( 83840 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a4xx.xml ( 112086 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a5xx.xml ( 147240 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx.xml ( 101627 bytes, from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/ocmem.xml ( 1773 bytes, from 2018-07-03 19:37:13)
+- ./adreno.xml ( 501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml ( 42393 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 147240 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a6xx.xml ( 107570 bytes, from 2018-08-16 17:32:18)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-08-16 17:35:55)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
Copyright (C) 2013-2018 by the following authors:
- Rob Clark <robdclark@gmail.com> (robclark)
@@ -167,8 +167,8 @@ static inline uint32_t A6XX_GMU_PWR_COL_INTER_FRAME_CTRL_MIN_PASS_LENGTH(uint32_
#define REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS 0x000050d0
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWERING_OFF 0x00000001
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWERING_ON 0x00000002
-#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_ON 0x00000004
-#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF 0x00000008
+#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF 0x00000004
+#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_ON 0x00000008
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SP_CLOCK_OFF 0x00000010
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GMU_UP_POWER_STATE 0x00000020
#define A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_GDSC_POWER_OFF 0x00000040
--
2.18.0
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 3/9] drm/msm/a6xx: Rename gmu phandle to qcom, gmu
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-27 15:11 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
From the review for the DT bindings for the GPU/GMU it
was suggested that the phandle for the GMU be
'qcom,gmu' instead of just 'gmu' but that never actually
got changed in the code.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c629f742a1d1..9a14cb3d5027 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -799,7 +799,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
}
/* Check if there is a GMU phandle and set it up */
- node = of_parse_phandle(pdev->dev.of_node, "gmu", 0);
+ node = of_parse_phandle(pdev->dev.of_node, "qcom,gmu", 0);
/* FIXME: How do we gracefully handle this? */
BUG_ON(!node);
--
2.18.0
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 3/9] drm/msm/a6xx: Rename gmu phandle to qcom,gmu
@ 2018-08-27 15:11 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: linux-arm-kernel
>From the review for the DT bindings for the GPU/GMU it
was suggested that the phandle for the GMU be
'qcom,gmu' instead of just 'gmu' but that never actually
got changed in the code.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index c629f742a1d1..9a14cb3d5027 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -799,7 +799,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
}
/* Check if there is a GMU phandle and set it up */
- node = of_parse_phandle(pdev->dev.of_node, "gmu", 0);
+ node = of_parse_phandle(pdev->dev.of_node, "qcom,gmu", 0);
/* FIXME: How do we gracefully handle this? */
BUG_ON(!node);
--
2.18.0
^ permalink raw reply related [flat|nested] 72+ messages in thread
* [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-27 15:11 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add the nodes to describe the Adreno GPU and GMU devices.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
1 file changed, 121 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb3c995..10db0ceb3699 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -192,6 +192,59 @@
method = "smc";
};
+gpu_opp_table: adreno-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ opp-710000000 {
+ opp-hz = /bits/ 64 <710000000>;
+ qcom,level = <416>;
+ };
+
+ opp-675000000 {
+ opp-hz = /bits/ 64 <675000000>;
+ qcom,level = <384>;
+ };
+
+ opp-596000000 {
+ opp-hz = /bits/ 64 <596000000>;
+ qcom,level = <320>;
+ };
+
+ opp-520000000 {
+ opp-hz = /bits/ 64 <520000000>;
+ qcom,level = <256>;
+ };
+
+ opp-414000000 {
+ opp-hz = /bits/ 64 <414000000>;
+ qcom,level = <192>;
+ };
+
+ opp-342000000 {
+ opp-hz = /bits/ 64 <342000000>;
+ qcom,level = <128>;
+ };
+
+ opp-257000000 {
+ opp-hz = /bits/ 64 <257000000>;
+ qcom,level = <64>;
+ };
+ };
+
+ gmu_opp_table: adreno-gmu-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ qcom,level = <128>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ qcom,level = <48>;
+ };
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -323,5 +376,73 @@
status = "disabled";
};
};
+
+ adreno_smmu: adreno-smmu@5040000 {
+ compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+ reg = <0x5040000 0x10000>;
+ #iommu-cells = <1>;
+ #global-interrupts = <2>;
+ interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 364 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 365 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 366 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 367 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 368 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 369 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 370 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 371 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gcc GCC_GPU_CFG_AHB_CLK>;
+ clock-names = "bus", "iface";
+
+ power-domains = <&gpucc GPU_CX_GDSC>;
+ };
+
+ gpu@5000000 {
+ compatible = "qcom,adreno-630.2", "qcom,adreno";
+ #stream-id-cells = <16>;
+
+ reg = <0x5000000 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ /*
+ * Look ma, no clocks! The GPU clocks and power are
+ * controlled entirely by the GMU
+ */
+
+ interrupts = <0 300 0>;
+ interrupt-names = "kgsl_3d0_irq";
+
+ iommus = <&adreno_smmu 0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ qcom,gmu = <&gmu>;
+ };
+
+ gmu: gmu@506a000 {
+ compatible="qcom,adreno-gmu";
+
+ reg = <0x506a000 0x30000>,
+ <0xb280000 0x10000>,
+ <0xb480000 0x10000>;
+ reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = <&gpucc GPU_CX_GDSC>;
+ iommus = <&adreno_smmu 5>;
+
+ operating-points-v2 = <&gmu_opp_table>;
+ };
};
};
--
2.18.0
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-08-27 15:11 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: linux-arm-kernel
Add the nodes to describe the Adreno GPU and GMU devices.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
1 file changed, 121 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index cdaabeb3c995..10db0ceb3699 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -192,6 +192,59 @@
method = "smc";
};
+gpu_opp_table: adreno-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ opp-710000000 {
+ opp-hz = /bits/ 64 <710000000>;
+ qcom,level = <416>;
+ };
+
+ opp-675000000 {
+ opp-hz = /bits/ 64 <675000000>;
+ qcom,level = <384>;
+ };
+
+ opp-596000000 {
+ opp-hz = /bits/ 64 <596000000>;
+ qcom,level = <320>;
+ };
+
+ opp-520000000 {
+ opp-hz = /bits/ 64 <520000000>;
+ qcom,level = <256>;
+ };
+
+ opp-414000000 {
+ opp-hz = /bits/ 64 <414000000>;
+ qcom,level = <192>;
+ };
+
+ opp-342000000 {
+ opp-hz = /bits/ 64 <342000000>;
+ qcom,level = <128>;
+ };
+
+ opp-257000000 {
+ opp-hz = /bits/ 64 <257000000>;
+ qcom,level = <64>;
+ };
+ };
+
+ gmu_opp_table: adreno-gmu-opp-table {
+ compatible = "operating-points-v2-qcom-level";
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ qcom,level = <128>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ qcom,level = <48>;
+ };
+ };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -323,5 +376,73 @@
status = "disabled";
};
};
+
+ adreno_smmu: adreno-smmu at 5040000 {
+ compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
+ reg = <0x5040000 0x10000>;
+ #iommu-cells = <1>;
+ #global-interrupts = <2>;
+ interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 364 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 365 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 366 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 367 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 368 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 369 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 370 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 371 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gcc GCC_GPU_CFG_AHB_CLK>;
+ clock-names = "bus", "iface";
+
+ power-domains = <&gpucc GPU_CX_GDSC>;
+ };
+
+ gpu at 5000000 {
+ compatible = "qcom,adreno-630.2", "qcom,adreno";
+ #stream-id-cells = <16>;
+
+ reg = <0x5000000 0x40000>;
+ reg-names = "kgsl_3d0_reg_memory";
+
+ /*
+ * Look ma, no clocks! The GPU clocks and power are
+ * controlled entirely by the GMU
+ */
+
+ interrupts = <0 300 0>;
+ interrupt-names = "kgsl_3d0_irq";
+
+ iommus = <&adreno_smmu 0>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+
+ qcom,gmu = <&gmu>;
+ };
+
+ gmu: gmu at 506a000 {
+ compatible="qcom,adreno-gmu";
+
+ reg = <0x506a000 0x30000>,
+ <0xb280000 0x10000>,
+ <0xb480000 0x10000>;
+ reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "hfi", "gmu";
+
+ clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>;
+ clock-names = "gmu", "cxo", "axi", "memnoc";
+
+ power-domains = <&gpucc GPU_CX_GDSC>;
+ iommus = <&adreno_smmu 5>;
+
+ operating-points-v2 = <&gmu_opp_table>;
+ };
};
};
--
2.18.0
^ permalink raw reply related [flat|nested] 72+ messages in thread[parent not found: <20180827151112.25211-6-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-28 10:30 ` Vivek Gautam
-1 siblings, 0 replies; 72+ messages in thread
From: Vivek Gautam @ 2018-08-28 10:30 UTC (permalink / raw)
To: Jordan Crouse
Cc: nm-l0cyMroinI0,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux PM, sboyd-DgEjT+Ai2ygdnm+yROfE0A, linux-arm-msm, dri-devel,
Bjorn Andersson, vireshk-DgEjT+Ai2ygdnm+yROfE0A, freedreno,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A, Linux ARM
Hi Jordan,
On Mon, Aug 27, 2018 at 8:42 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
>
> Add the nodes to describe the Adreno GPU and GMU devices.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> 1 file changed, 121 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..10db0ceb3699 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -192,6 +192,59 @@
> method = "smc";
> };
>
> +gpu_opp_table: adreno-opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + opp-710000000 {
> + opp-hz = /bits/ 64 <710000000>;
> + qcom,level = <416>;
> + };
> +
> + opp-675000000 {
> + opp-hz = /bits/ 64 <675000000>;
> + qcom,level = <384>;
> + };
> +
> + opp-596000000 {
> + opp-hz = /bits/ 64 <596000000>;
> + qcom,level = <320>;
> + };
> +
> + opp-520000000 {
> + opp-hz = /bits/ 64 <520000000>;
> + qcom,level = <256>;
> + };
> +
> + opp-414000000 {
> + opp-hz = /bits/ 64 <414000000>;
> + qcom,level = <192>;
> + };
> +
> + opp-342000000 {
> + opp-hz = /bits/ 64 <342000000>;
> + qcom,level = <128>;
> + };
> +
> + opp-257000000 {
> + opp-hz = /bits/ 64 <257000000>;
> + qcom,level = <64>;
> + };
> + };
> +
> + gmu_opp_table: adreno-gmu-opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + opp-400000000 {
> + opp-hz = /bits/ 64 <400000000>;
> + qcom,level = <128>;
> + };
> +
> + opp-200000000 {
> + opp-hz = /bits/ 64 <200000000>;
> + qcom,level = <48>;
> + };
> + };
> +
> soc: soc {
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -323,5 +376,73 @@
> status = "disabled";
> };
> };
> +
> + adreno_smmu: adreno-smmu@5040000 {
iommu@5040000 as pointed out by Rob in [1]
> + compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> + reg = <0x5040000 0x10000>;
> + #iommu-cells = <1>;
> + #global-interrupts = <2>;
> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 364 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 365 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 366 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 367 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 368 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 369 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 370 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 371 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
> + <&gcc GCC_GPU_CFG_AHB_CLK>;
> + clock-names = "bus", "iface";
> +
> + power-domains = <&gpucc GPU_CX_GDSC>;
and for this you need to include the gpucc dt-bindings header which is coming
from Amit's gpucc driver patch.
[1] https://patchwork.kernel.org/patch/10534999/
Best regards
Vivek
[snip]
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-08-28 10:30 ` Vivek Gautam
0 siblings, 0 replies; 72+ messages in thread
From: Vivek Gautam @ 2018-08-28 10:30 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jordan,
On Mon, Aug 27, 2018 at 8:42 PM Jordan Crouse <jcrouse@codeaurora.org> wrote:
>
> Add the nodes to describe the Adreno GPU and GMU devices.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> 1 file changed, 121 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..10db0ceb3699 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -192,6 +192,59 @@
> method = "smc";
> };
>
> +gpu_opp_table: adreno-opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + opp-710000000 {
> + opp-hz = /bits/ 64 <710000000>;
> + qcom,level = <416>;
> + };
> +
> + opp-675000000 {
> + opp-hz = /bits/ 64 <675000000>;
> + qcom,level = <384>;
> + };
> +
> + opp-596000000 {
> + opp-hz = /bits/ 64 <596000000>;
> + qcom,level = <320>;
> + };
> +
> + opp-520000000 {
> + opp-hz = /bits/ 64 <520000000>;
> + qcom,level = <256>;
> + };
> +
> + opp-414000000 {
> + opp-hz = /bits/ 64 <414000000>;
> + qcom,level = <192>;
> + };
> +
> + opp-342000000 {
> + opp-hz = /bits/ 64 <342000000>;
> + qcom,level = <128>;
> + };
> +
> + opp-257000000 {
> + opp-hz = /bits/ 64 <257000000>;
> + qcom,level = <64>;
> + };
> + };
> +
> + gmu_opp_table: adreno-gmu-opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + opp-400000000 {
> + opp-hz = /bits/ 64 <400000000>;
> + qcom,level = <128>;
> + };
> +
> + opp-200000000 {
> + opp-hz = /bits/ 64 <200000000>;
> + qcom,level = <48>;
> + };
> + };
> +
> soc: soc {
> #address-cells = <1>;
> #size-cells = <1>;
> @@ -323,5 +376,73 @@
> status = "disabled";
> };
> };
> +
> + adreno_smmu: adreno-smmu at 5040000 {
iommu at 5040000 as pointed out by Rob in [1]
> + compatible = "qcom,sdm845-smmu-v2", "qcom,smmu-v2";
> + reg = <0x5040000 0x10000>;
> + #iommu-cells = <1>;
> + #global-interrupts = <2>;
> + interrupts = <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 364 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 365 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 366 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 367 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 368 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 369 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 370 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 371 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
> + <&gcc GCC_GPU_CFG_AHB_CLK>;
> + clock-names = "bus", "iface";
> +
> + power-domains = <&gpucc GPU_CX_GDSC>;
and for this you need to include the gpucc dt-bindings header which is coming
from Amit's gpucc driver patch.
[1] https://patchwork.kernel.org/patch/10534999/
Best regards
Vivek
[snip]
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-08-27 15:11 ` Jordan Crouse
@ 2018-10-10 9:46 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 9:46 UTC (permalink / raw)
To: Jordan Crouse
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 27-08-18, 09:11, Jordan Crouse wrote:
> Add the nodes to describe the Adreno GPU and GMU devices.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> 1 file changed, 121 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..10db0ceb3699 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -192,6 +192,59 @@
> method = "smc";
> };
>
> +gpu_opp_table: adreno-opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + opp-710000000 {
> + opp-hz = /bits/ 64 <710000000>;
> + qcom,level = <416>;
What is qcom,level here ? Is it different than the RPM voting thing ?
If not then you need to follow what Rajendra, Niklas are doing as
well. There needs to be a genpd which needs to carry this value and
the gpu's table will have required-opps entry to point to it.
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-10 9:46 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 9:46 UTC (permalink / raw)
To: linux-arm-kernel
On 27-08-18, 09:11, Jordan Crouse wrote:
> Add the nodes to describe the Adreno GPU and GMU devices.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> 1 file changed, 121 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..10db0ceb3699 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -192,6 +192,59 @@
> method = "smc";
> };
>
> +gpu_opp_table: adreno-opp-table {
> + compatible = "operating-points-v2-qcom-level";
> +
> + opp-710000000 {
> + opp-hz = /bits/ 64 <710000000>;
> + qcom,level = <416>;
What is qcom,level here ? Is it different than the RPM voting thing ?
If not then you need to follow what Rajendra, Niklas are doing as
well. There needs to be a genpd which needs to carry this value and
the gpu's table will have required-opps entry to point to it.
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-10 9:46 ` Viresh Kumar
@ 2018-10-10 14:29 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 14:29 UTC (permalink / raw)
To: Viresh Kumar
Cc: nm, devicetree, linux-pm, sboyd, linux-arm-msm, dri-devel,
bjorn.andersson, vireshk, freedreno, georgi.djakov,
linux-arm-kernel
On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> On 27-08-18, 09:11, Jordan Crouse wrote:
> > Add the nodes to describe the Adreno GPU and GMU devices.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> > 1 file changed, 121 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index cdaabeb3c995..10db0ceb3699 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -192,6 +192,59 @@
> > method = "smc";
> > };
> >
> > +gpu_opp_table: adreno-opp-table {
> > + compatible = "operating-points-v2-qcom-level";
> > +
> > + opp-710000000 {
> > + opp-hz = /bits/ 64 <710000000>;
> > + qcom,level = <416>;
>
> What is qcom,level here ? Is it different than the RPM voting thing ?
>
> If not then you need to follow what Rajendra, Niklas are doing as
> well. There needs to be a genpd which needs to carry this value and
> the gpu's table will have required-opps entry to point to it.
I don't think it is the same (we have some special considerations here)
but I missed the new work from the other folks and I want to review it
before I conclude one way or the other. Is there a link to the latest
and greatest that I can use to get caught up?
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-10 14:29 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 14:29 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> On 27-08-18, 09:11, Jordan Crouse wrote:
> > Add the nodes to describe the Adreno GPU and GMU devices.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> > arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> > 1 file changed, 121 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > index cdaabeb3c995..10db0ceb3699 100644
> > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > @@ -192,6 +192,59 @@
> > method = "smc";
> > };
> >
> > +gpu_opp_table: adreno-opp-table {
> > + compatible = "operating-points-v2-qcom-level";
> > +
> > + opp-710000000 {
> > + opp-hz = /bits/ 64 <710000000>;
> > + qcom,level = <416>;
>
> What is qcom,level here ? Is it different than the RPM voting thing ?
>
> If not then you need to follow what Rajendra, Niklas are doing as
> well. There needs to be a genpd which needs to carry this value and
> the gpu's table will have required-opps entry to point to it.
I don't think it is the same (we have some special considerations here)
but I missed the new work from the other folks and I want to review it
before I conclude one way or the other. Is there a link to the latest
and greatest that I can use to get caught up?
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread[parent not found: <20181010142905.GB9977-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>]
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-10 14:29 ` Jordan Crouse
@ 2018-10-10 14:31 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 14:31 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
vireshk-DgEjT+Ai2ygdnm+yROfE0A, nm-l0cyMroinI0,
sboyd-DgEjT+Ai2ygdnm+yROfE0A
Cc: niklas.cassel-QSEj5FYQhm4dnm+yROfE0A, rnayak-sgV2jX0FEOL9JmXXK+q4OQ
On 10-10-18, 08:29, Jordan Crouse wrote:
> On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> > On 27-08-18, 09:11, Jordan Crouse wrote:
> > > Add the nodes to describe the Adreno GPU and GMU devices.
> > >
> > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > ---
> > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> > > 1 file changed, 121 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index cdaabeb3c995..10db0ceb3699 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -192,6 +192,59 @@
> > > method = "smc";
> > > };
> > >
> > > +gpu_opp_table: adreno-opp-table {
> > > + compatible = "operating-points-v2-qcom-level";
> > > +
> > > + opp-710000000 {
> > > + opp-hz = /bits/ 64 <710000000>;
> > > + qcom,level = <416>;
> >
> > What is qcom,level here ? Is it different than the RPM voting thing ?
> >
> > If not then you need to follow what Rajendra, Niklas are doing as
> > well. There needs to be a genpd which needs to carry this value and
> > the gpu's table will have required-opps entry to point to it.
>
> I don't think it is the same (we have some special considerations here)
> but I missed the new work from the other folks and I want to review it
> before I conclude one way or the other. Is there a link to the latest
> and greatest that I can use to get caught up?
lkml.kernel.org/r/20180627045234.27403-1-rnayak@codeaurora.org
+Rajendra/Niklas, please review Jordan's work as well to see if the
qcom,level thing is similar to what you guys are using.
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-10 14:31 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 14:31 UTC (permalink / raw)
To: linux-arm-kernel
On 10-10-18, 08:29, Jordan Crouse wrote:
> On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> > On 27-08-18, 09:11, Jordan Crouse wrote:
> > > Add the nodes to describe the Adreno GPU and GMU devices.
> > >
> > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > ---
> > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> > > 1 file changed, 121 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > index cdaabeb3c995..10db0ceb3699 100644
> > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > @@ -192,6 +192,59 @@
> > > method = "smc";
> > > };
> > >
> > > +gpu_opp_table: adreno-opp-table {
> > > + compatible = "operating-points-v2-qcom-level";
> > > +
> > > + opp-710000000 {
> > > + opp-hz = /bits/ 64 <710000000>;
> > > + qcom,level = <416>;
> >
> > What is qcom,level here ? Is it different than the RPM voting thing ?
> >
> > If not then you need to follow what Rajendra, Niklas are doing as
> > well. There needs to be a genpd which needs to carry this value and
> > the gpu's table will have required-opps entry to point to it.
>
> I don't think it is the same (we have some special considerations here)
> but I missed the new work from the other folks and I want to review it
> before I conclude one way or the other. Is there a link to the latest
> and greatest that I can use to get caught up?
lkml.kernel.org/r/20180627045234.27403-1-rnayak at codeaurora.org
+Rajendra/Niklas, please review Jordan's work as well to see if the
qcom,level thing is similar to what you guys are using.
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-10 14:31 ` Viresh Kumar
@ 2018-10-10 14:48 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 14:48 UTC (permalink / raw)
To: Viresh Kumar
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, linux-pm-u79uwXL29TY76Z2rM5mHXA,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Oct 10, 2018 at 08:01:49PM +0530, Viresh Kumar wrote:
> On 10-10-18, 08:29, Jordan Crouse wrote:
> > On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> > > On 27-08-18, 09:11, Jordan Crouse wrote:
> > > > Add the nodes to describe the Adreno GPU and GMU devices.
> > > >
> > > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> > > > 1 file changed, 121 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > index cdaabeb3c995..10db0ceb3699 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > @@ -192,6 +192,59 @@
> > > > method = "smc";
> > > > };
> > > >
> > > > +gpu_opp_table: adreno-opp-table {
> > > > + compatible = "operating-points-v2-qcom-level";
> > > > +
> > > > + opp-710000000 {
> > > > + opp-hz = /bits/ 64 <710000000>;
> > > > + qcom,level = <416>;
> > >
> > > What is qcom,level here ? Is it different than the RPM voting thing ?
> > >
> > > If not then you need to follow what Rajendra, Niklas are doing as
> > > well. There needs to be a genpd which needs to carry this value and
> > > the gpu's table will have required-opps entry to point to it.
> >
> > I don't think it is the same (we have some special considerations here)
> > but I missed the new work from the other folks and I want to review it
> > before I conclude one way or the other. Is there a link to the latest
> > and greatest that I can use to get caught up?
>
> lkml.kernel.org/r/20180627045234.27403-1-rnayak@codeaurora.org
>
> +Rajendra/Niklas, please review Jordan's work as well to see if the
> qcom,level thing is similar to what you guys are using.
qcom,level comes straight from:
https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak@codeaurora.org/
But in this case instead of using the CPU to program the RPMh we are passing
the value to a microprocessor (the GMU) and that will do the vote on our behalf
(Technically we use the value to look up the vote in the cmd-db database and
pass that to the GMU)
This is why the qcom,level was added in the first place so we could at least
share the nomenclature with the rpmhd if not the implementation.
Jordan
> --
> viresh
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-10 14:48 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 14:48 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 10, 2018 at 08:01:49PM +0530, Viresh Kumar wrote:
> On 10-10-18, 08:29, Jordan Crouse wrote:
> > On Wed, Oct 10, 2018 at 03:16:28PM +0530, Viresh Kumar wrote:
> > > On 27-08-18, 09:11, Jordan Crouse wrote:
> > > > Add the nodes to describe the Adreno GPU and GMU devices.
> > > >
> > > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/sdm845.dtsi | 121 +++++++++++++++++++++++++++
> > > > 1 file changed, 121 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > index cdaabeb3c995..10db0ceb3699 100644
> > > > --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> > > > @@ -192,6 +192,59 @@
> > > > method = "smc";
> > > > };
> > > >
> > > > +gpu_opp_table: adreno-opp-table {
> > > > + compatible = "operating-points-v2-qcom-level";
> > > > +
> > > > + opp-710000000 {
> > > > + opp-hz = /bits/ 64 <710000000>;
> > > > + qcom,level = <416>;
> > >
> > > What is qcom,level here ? Is it different than the RPM voting thing ?
> > >
> > > If not then you need to follow what Rajendra, Niklas are doing as
> > > well. There needs to be a genpd which needs to carry this value and
> > > the gpu's table will have required-opps entry to point to it.
> >
> > I don't think it is the same (we have some special considerations here)
> > but I missed the new work from the other folks and I want to review it
> > before I conclude one way or the other. Is there a link to the latest
> > and greatest that I can use to get caught up?
>
> lkml.kernel.org/r/20180627045234.27403-1-rnayak at codeaurora.org
>
> +Rajendra/Niklas, please review Jordan's work as well to see if the
> qcom,level thing is similar to what you guys are using.
qcom,level comes straight from:
https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak at codeaurora.org/
But in this case instead of using the CPU to program the RPMh we are passing
the value to a microprocessor (the GMU) and that will do the vote on our behalf
(Technically we use the value to look up the vote in the cmd-db database and
pass that to the GMU)
This is why the qcom,level was added in the first place so we could at least
share the nomenclature with the rpmhd if not the implementation.
Jordan
> --
> viresh
> _______________________________________________
> Freedreno mailing list
> Freedreno at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread[parent not found: <20181010144856.GC9977-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>]
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-10 14:48 ` [Freedreno] " Jordan Crouse
@ 2018-10-10 14:51 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 14:51 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
vireshk-DgEjT+Ai2ygdnm+yROfE0A, nm-l0cyMroinI0,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ
On 10-10-18, 08:48, Jordan Crouse wrote:
> qcom,level comes straight from:
>
> https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak@codeaurora.org/
>
> But in this case instead of using the CPU to program the RPMh we are passing
> the value to a microprocessor (the GMU) and that will do the vote on our behalf
> (Technically we use the value to look up the vote in the cmd-db database and
> pass that to the GMU)
>
> This is why the qcom,level was added in the first place so we could at least
> share the nomenclature with the rpmhd if not the implementation.
How you actually pass the vote to the underlying hardware, RPMh or
GMU, is irrelevant to the whole thing. What is important is how we
describe that in DT and how we represent the whole thing.
We have chosen genpd + OPP to do this and same should be used by you
as well. Another benefit is that the genpd core will do vote
aggregation for you here.
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-10 14:51 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 14:51 UTC (permalink / raw)
To: linux-arm-kernel
On 10-10-18, 08:48, Jordan Crouse wrote:
> qcom,level comes straight from:
>
> https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak at codeaurora.org/
>
> But in this case instead of using the CPU to program the RPMh we are passing
> the value to a microprocessor (the GMU) and that will do the vote on our behalf
> (Technically we use the value to look up the vote in the cmd-db database and
> pass that to the GMU)
>
> This is why the qcom,level was added in the first place so we could at least
> share the nomenclature with the rpmhd if not the implementation.
How you actually pass the vote to the underlying hardware, RPMh or
GMU, is irrelevant to the whole thing. What is important is how we
describe that in DT and how we represent the whole thing.
We have chosen genpd + OPP to do this and same should be used by you
as well. Another benefit is that the genpd core will do vote
aggregation for you here.
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-10 14:51 ` [Freedreno] " Viresh Kumar
@ 2018-10-10 15:10 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 15:10 UTC (permalink / raw)
To: Viresh Kumar
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, linux-pm-u79uwXL29TY76Z2rM5mHXA,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> On 10-10-18, 08:48, Jordan Crouse wrote:
> > qcom,level comes straight from:
> >
> > https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak@codeaurora.org/
> >
> > But in this case instead of using the CPU to program the RPMh we are passing
> > the value to a microprocessor (the GMU) and that will do the vote on our behalf
> > (Technically we use the value to look up the vote in the cmd-db database and
> > pass that to the GMU)
> >
> > This is why the qcom,level was added in the first place so we could at least
> > share the nomenclature with the rpmhd if not the implementation.
>
> How you actually pass the vote to the underlying hardware, RPMh or
> GMU, is irrelevant to the whole thing. What is important is how we
> describe that in DT and how we represent the whole thing.
>
> We have chosen genpd + OPP to do this and same should be used by you
> as well. Another benefit is that the genpd core will do vote
> aggregation for you here.
I'm not sure what you are suggesting? The vote is represented in DT exactly as
described in the bindings.
Jordan
> --
> viresh
> _______________________________________________
> Freedreno mailing list
> Freedreno@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-10 15:10 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 15:10 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> On 10-10-18, 08:48, Jordan Crouse wrote:
> > qcom,level comes straight from:
> >
> > https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak at codeaurora.org/
> >
> > But in this case instead of using the CPU to program the RPMh we are passing
> > the value to a microprocessor (the GMU) and that will do the vote on our behalf
> > (Technically we use the value to look up the vote in the cmd-db database and
> > pass that to the GMU)
> >
> > This is why the qcom,level was added in the first place so we could at least
> > share the nomenclature with the rpmhd if not the implementation.
>
> How you actually pass the vote to the underlying hardware, RPMh or
> GMU, is irrelevant to the whole thing. What is important is how we
> describe that in DT and how we represent the whole thing.
>
> We have chosen genpd + OPP to do this and same should be used by you
> as well. Another benefit is that the genpd core will do vote
> aggregation for you here.
I'm not sure what you are suggesting? The vote is represented in DT exactly as
described in the bindings.
Jordan
> --
> viresh
> _______________________________________________
> Freedreno mailing list
> Freedreno at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20181010151006.GD9977-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>]
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-10 15:10 ` [Freedreno] " Jordan Crouse
@ 2018-10-11 5:02 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-11 5:02 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
vireshk-DgEjT+Ai2ygdnm+yROfE0A, nm-l0cyMroinI0,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ
On 10-10-18, 09:10, Jordan Crouse wrote:
> On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> > On 10-10-18, 08:48, Jordan Crouse wrote:
> > > qcom,level comes straight from:
> > >
> > > https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak@codeaurora.org/
> > >
> > > But in this case instead of using the CPU to program the RPMh we are passing
> > > the value to a microprocessor (the GMU) and that will do the vote on our behalf
> > > (Technically we use the value to look up the vote in the cmd-db database and
> > > pass that to the GMU)
> > >
> > > This is why the qcom,level was added in the first place so we could at least
> > > share the nomenclature with the rpmhd if not the implementation.
> >
> > How you actually pass the vote to the underlying hardware, RPMh or
> > GMU, is irrelevant to the whole thing. What is important is how we
> > describe that in DT and how we represent the whole thing.
> >
> > We have chosen genpd + OPP to do this and same should be used by you
> > as well. Another benefit is that the genpd core will do vote
> > aggregation for you here.
>
> I'm not sure what you are suggesting? The vote is represented in DT exactly as
> described in the bindings.
Look at how Rajendra has done it to see the difference.
https://lore.kernel.org/lkml/20180627045234.27403-3-rnayak@codeaurora.org/
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-11 5:02 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-11 5:02 UTC (permalink / raw)
To: linux-arm-kernel
On 10-10-18, 09:10, Jordan Crouse wrote:
> On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> > On 10-10-18, 08:48, Jordan Crouse wrote:
> > > qcom,level comes straight from:
> > >
> > > https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak at codeaurora.org/
> > >
> > > But in this case instead of using the CPU to program the RPMh we are passing
> > > the value to a microprocessor (the GMU) and that will do the vote on our behalf
> > > (Technically we use the value to look up the vote in the cmd-db database and
> > > pass that to the GMU)
> > >
> > > This is why the qcom,level was added in the first place so we could at least
> > > share the nomenclature with the rpmhd if not the implementation.
> >
> > How you actually pass the vote to the underlying hardware, RPMh or
> > GMU, is irrelevant to the whole thing. What is important is how we
> > describe that in DT and how we represent the whole thing.
> >
> > We have chosen genpd + OPP to do this and same should be used by you
> > as well. Another benefit is that the genpd core will do vote
> > aggregation for you here.
>
> I'm not sure what you are suggesting? The vote is represented in DT exactly as
> described in the bindings.
Look at how Rajendra has done it to see the difference.
https://lore.kernel.org/lkml/20180627045234.27403-3-rnayak at codeaurora.org/
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-11 5:02 ` [Freedreno] " Viresh Kumar
@ 2018-10-11 14:54 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-11 14:54 UTC (permalink / raw)
To: Viresh Kumar
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, linux-pm-u79uwXL29TY76Z2rM5mHXA,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Thu, Oct 11, 2018 at 10:32:16AM +0530, Viresh Kumar wrote:
> On 10-10-18, 09:10, Jordan Crouse wrote:
> > On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> > > On 10-10-18, 08:48, Jordan Crouse wrote:
> > > > qcom,level comes straight from:
> > > >
> > > > https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak@codeaurora.org/
> > > >
> > > > But in this case instead of using the CPU to program the RPMh we are passing
> > > > the value to a microprocessor (the GMU) and that will do the vote on our behalf
> > > > (Technically we use the value to look up the vote in the cmd-db database and
> > > > pass that to the GMU)
> > > >
> > > > This is why the qcom,level was added in the first place so we could at least
> > > > share the nomenclature with the rpmhd if not the implementation.
> > >
> > > How you actually pass the vote to the underlying hardware, RPMh or
> > > GMU, is irrelevant to the whole thing. What is important is how we
> > > describe that in DT and how we represent the whole thing.
> > >
> > > We have chosen genpd + OPP to do this and same should be used by you
> > > as well. Another benefit is that the genpd core will do vote
> > > aggregation for you here.
> >
> > I'm not sure what you are suggesting? The vote is represented in DT exactly as
> > described in the bindings.
>
> Look at how Rajendra has done it to see the difference.
>
> https://lore.kernel.org/lkml/20180627045234.27403-3-rnayak@codeaurora.org/
The GPU domain is completely controlled by the GMU hardware and is powered
independently of the CPU. For various reasons the GMU can't come up with
the vote itself so we need to construct a vote and send it during
initialization. For this we duplicate the code that rmphd does to query the
cmd-db and build the values using qcom,level as a guide. This is necessary
copypasta as the alternative would be to add the hooks into genpd or add a
side hook into the rpmhd to get the values we need and none of that is worth
it for a few lines of walking an array.
qcom,level serves the purpose for us in this case because we can get the value
we need and construct the vote. If we move to using required-opp, thats just
another step of parsing for the driver and it establishes a relationship with
rmphd on the CPU that shouldn't exist.
I do see a good argument for using the symbolic bindings (i.e.
RPMH_REGULATOR_LEVEL_TURBO_L1) and we can do that easily but beyond that I
don't think that we need the extra parsing step.
Thanks,
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-11 14:54 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-11 14:54 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Oct 11, 2018 at 10:32:16AM +0530, Viresh Kumar wrote:
> On 10-10-18, 09:10, Jordan Crouse wrote:
> > On Wed, Oct 10, 2018 at 08:21:39PM +0530, Viresh Kumar wrote:
> > > On 10-10-18, 08:48, Jordan Crouse wrote:
> > > > qcom,level comes straight from:
> > > >
> > > > https://lore.kernel.org/lkml/20180627045234.27403-2-rnayak at codeaurora.org/
> > > >
> > > > But in this case instead of using the CPU to program the RPMh we are passing
> > > > the value to a microprocessor (the GMU) and that will do the vote on our behalf
> > > > (Technically we use the value to look up the vote in the cmd-db database and
> > > > pass that to the GMU)
> > > >
> > > > This is why the qcom,level was added in the first place so we could at least
> > > > share the nomenclature with the rpmhd if not the implementation.
> > >
> > > How you actually pass the vote to the underlying hardware, RPMh or
> > > GMU, is irrelevant to the whole thing. What is important is how we
> > > describe that in DT and how we represent the whole thing.
> > >
> > > We have chosen genpd + OPP to do this and same should be used by you
> > > as well. Another benefit is that the genpd core will do vote
> > > aggregation for you here.
> >
> > I'm not sure what you are suggesting? The vote is represented in DT exactly as
> > described in the bindings.
>
> Look at how Rajendra has done it to see the difference.
>
> https://lore.kernel.org/lkml/20180627045234.27403-3-rnayak at codeaurora.org/
The GPU domain is completely controlled by the GMU hardware and is powered
independently of the CPU. For various reasons the GMU can't come up with
the vote itself so we need to construct a vote and send it during
initialization. For this we duplicate the code that rmphd does to query the
cmd-db and build the values using qcom,level as a guide. This is necessary
copypasta as the alternative would be to add the hooks into genpd or add a
side hook into the rpmhd to get the values we need and none of that is worth
it for a few lines of walking an array.
qcom,level serves the purpose for us in this case because we can get the value
we need and construct the vote. If we move to using required-opp, thats just
another step of parsing for the driver and it establishes a relationship with
rmphd on the CPU that shouldn't exist.
I do see a good argument for using the symbolic bindings (i.e.
RPMH_REGULATOR_LEVEL_TURBO_L1) and we can do that easily but beyond that I
don't think that we need the extra parsing step.
Thanks,
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20181011145456.GG9977-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>]
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-11 14:54 ` [Freedreno] " Jordan Crouse
@ 2018-10-15 10:03 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-15 10:03 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
vireshk-DgEjT+Ai2ygdnm+yROfE0A, nm-l0cyMroinI0,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ
On 11-10-18, 08:54, Jordan Crouse wrote:
I understand what you are trying to say Jordan and I agree with those
expectations. But what I am looking for is consistency across Qcom
code using the same feature. Which enables better support for the code
going forward, etc. And if we are going to go a different way, there
must be a very good reason to do that.
But let me try to understand the hardware a bit first..
> The GPU domain is completely controlled by the GMU hardware and is powered
> independently of the CPU. For various reasons the GMU can't come up with
> the vote itself so we need to construct a vote and send it during
> initialization.
So it is the kernel which needs to send this vote on behalf of the GMU
to RPM ? Who does the vote aggregation in this case ? I thought there
has to be a single vote going from CPU side to the RPM. Isn't the GMU
vote part of that ?
> For this we duplicate the code that rmphd does to query the
> cmd-db and build the values using qcom,level as a guide. This is necessary
> copypasta as the alternative would be to add the hooks into genpd or add a
> side hook into the rpmhd to get the values we need and none of that is worth
> it for a few lines of walking an array.
Initially when I was designing this qcom,level or generically called
"performance-state" thingy, I kept the values directly in the OPP node
of the consumer (the way you have done it), but then there were
discussions which forced us to move this to the genpd level. For
example, what will you do if you also need to pass voltage/current in
addition to performance-state to the RPM? StephenB actually said we
may or may not know these values and we must support both the cases.
The opp-microvolt properties of the consumer device (GPU here) should
be used to handle the regulators which are controlled by kernel itself
and so they can't additionally handle the RPMs data. And so we created
separate OPP table for the RPM and represented that as a genpd and we
now handle the aggregation in genpd core itself on behalf of all the
consumers.
> qcom,level serves the purpose for us in this case because we can get the value
> we need and construct the vote. If we move to using required-opp, thats just
> another step of parsing for the driver and
The OPP core shall have all the infrastructure to parse these things
and we should keep all such code there to avoid duplication.
> it establishes a relationship with
> rmphd on the CPU that shouldn't exist.
Sure. I am not suggesting that the representation in software should
be different from what the hardware is, maybe I didn't understood the
hardware design well.
> I do see a good argument for using the symbolic bindings (i.e.
> RPMH_REGULATOR_LEVEL_TURBO_L1) and we can do that easily but beyond that I
> don't think that we need the extra parsing step.
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-15 10:03 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-15 10:03 UTC (permalink / raw)
To: linux-arm-kernel
On 11-10-18, 08:54, Jordan Crouse wrote:
I understand what you are trying to say Jordan and I agree with those
expectations. But what I am looking for is consistency across Qcom
code using the same feature. Which enables better support for the code
going forward, etc. And if we are going to go a different way, there
must be a very good reason to do that.
But let me try to understand the hardware a bit first..
> The GPU domain is completely controlled by the GMU hardware and is powered
> independently of the CPU. For various reasons the GMU can't come up with
> the vote itself so we need to construct a vote and send it during
> initialization.
So it is the kernel which needs to send this vote on behalf of the GMU
to RPM ? Who does the vote aggregation in this case ? I thought there
has to be a single vote going from CPU side to the RPM. Isn't the GMU
vote part of that ?
> For this we duplicate the code that rmphd does to query the
> cmd-db and build the values using qcom,level as a guide. This is necessary
> copypasta as the alternative would be to add the hooks into genpd or add a
> side hook into the rpmhd to get the values we need and none of that is worth
> it for a few lines of walking an array.
Initially when I was designing this qcom,level or generically called
"performance-state" thingy, I kept the values directly in the OPP node
of the consumer (the way you have done it), but then there were
discussions which forced us to move this to the genpd level. For
example, what will you do if you also need to pass voltage/current in
addition to performance-state to the RPM? StephenB actually said we
may or may not know these values and we must support both the cases.
The opp-microvolt properties of the consumer device (GPU here) should
be used to handle the regulators which are controlled by kernel itself
and so they can't additionally handle the RPMs data. And so we created
separate OPP table for the RPM and represented that as a genpd and we
now handle the aggregation in genpd core itself on behalf of all the
consumers.
> qcom,level serves the purpose for us in this case because we can get the value
> we need and construct the vote. If we move to using required-opp, thats just
> another step of parsing for the driver and
The OPP core shall have all the infrastructure to parse these things
and we should keep all such code there to avoid duplication.
> it establishes a relationship with
> rmphd on the CPU that shouldn't exist.
Sure. I am not suggesting that the representation in software should
be different from what the hardware is, maybe I didn't understood the
hardware design well.
> I do see a good argument for using the symbolic bindings (i.e.
> RPMH_REGULATOR_LEVEL_TURBO_L1) and we can do that easily but beyond that I
> don't think that we need the extra parsing step.
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-15 10:03 ` [Freedreno] " Viresh Kumar
@ 2018-10-15 14:34 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-15 14:34 UTC (permalink / raw)
To: Viresh Kumar
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ, linux-pm-u79uwXL29TY76Z2rM5mHXA,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Oct 15, 2018 at 03:33:27PM +0530, Viresh Kumar wrote:
> On 11-10-18, 08:54, Jordan Crouse wrote:
>
> I understand what you are trying to say Jordan and I agree with those
> expectations. But what I am looking for is consistency across Qcom
> code using the same feature. Which enables better support for the code
> going forward, etc. And if we are going to go a different way, there
> must be a very good reason to do that.
I agree that consistency is good. But the GPU is by design outside of the
control of the genpd universe so it is by design not using the same features.
It unfortunately does happen to use a similar number in an OPP binding to
construct the level mapping but since we can't read the cmd-db from the GMU
space this is a necessary evil.
> But let me try to understand the hardware a bit first..
>
> > The GPU domain is completely controlled by the GMU hardware and is powered
> > independently of the CPU. For various reasons the GMU can't come up with
> > the vote itself so we need to construct a vote and send it during
> > initialization.
>
> So it is the kernel which needs to send this vote on behalf of the GMU
> to RPM ? Who does the vote aggregation in this case ? I thought there
> has to be a single vote going from CPU side to the RPM. Isn't the GMU
> vote part of that ?
For clarity the GMU and GPU are in different domains. The GMU (which is
controlled by the CPU) is responsible for generating and sending the vote on
behalf of the GPU. From an RPMh perspective The GPU is considered to be
separate from the CPU vote.
Also, I probably confused you by saying that the kernel constructs the vote
for the GPU. It actually constructs the mapping that the GMU can use to send
the vote. This is equivalent to rpmhpd_update_level_mapping() in the rpmhpd
driver if that helps.
> > For this we duplicate the code that rmphd does to query the
> > cmd-db and build the values using qcom,level as a guide. This is necessary
> > copypasta as the alternative would be to add the hooks into genpd or add a
> > side hook into the rpmhd to get the values we need and none of that is worth
> > it for a few lines of walking an array.
>
> Initially when I was designing this qcom,level or generically called
> "performance-state" thingy, I kept the values directly in the OPP node
> of the consumer (the way you have done it), but then there were
> discussions which forced us to move this to the genpd level. For
> example, what will you do if you also need to pass voltage/current in
> addition to performance-state to the RPM? StephenB actually said we
> may or may not know these values and we must support both the cases.
I agree that genpd has many responsibilities because it has to deal with many
different devices.
The GMU / GPU is built for a single purpose and the hardware has been designed
accordingly. For the foreseeable future we will not need to know anything
beyond the level mapping to operate the GPU.
> The opp-microvolt properties of the consumer device (GPU here) should
> be used to handle the regulators which are controlled by kernel itself
> and so they can't additionally handle the RPMs data. And so we created
> separate OPP table for the RPM and represented that as a genpd and we
> now handle the aggregation in genpd core itself on behalf of all the
> consumers.
Yes and it should continue to be that way. This just happens to be a
situation where one of the consumers is out of your area of control by
design.
> > qcom,level serves the purpose for us in this case because we can get the value
> > we need and construct the vote. If we move to using required-opp, thats just
> > another step of parsing for the driver and
>
> The OPP core shall have all the infrastructure to parse these things
> and we should keep all such code there to avoid duplication.
Using required-opp to look up another opp to look up the qcom,level is
by definition additional parsing. It doesn't imply that there would be
code duplication.
> > it establishes a relationship with
> > rmphd on the CPU that shouldn't exist.
>
> Sure. I am not suggesting that the representation in software should
> be different from what the hardware is, maybe I didn't understood the
> hardware design well.
>
> > I do see a good argument for using the symbolic bindings (i.e.
> > RPMH_REGULATOR_LEVEL_TURBO_L1) and we can do that easily but beyond that I
> > don't think that we need the extra parsing step.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-15 14:34 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-15 14:34 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 15, 2018 at 03:33:27PM +0530, Viresh Kumar wrote:
> On 11-10-18, 08:54, Jordan Crouse wrote:
>
> I understand what you are trying to say Jordan and I agree with those
> expectations. But what I am looking for is consistency across Qcom
> code using the same feature. Which enables better support for the code
> going forward, etc. And if we are going to go a different way, there
> must be a very good reason to do that.
I agree that consistency is good. But the GPU is by design outside of the
control of the genpd universe so it is by design not using the same features.
It unfortunately does happen to use a similar number in an OPP binding to
construct the level mapping but since we can't read the cmd-db from the GMU
space this is a necessary evil.
> But let me try to understand the hardware a bit first..
>
> > The GPU domain is completely controlled by the GMU hardware and is powered
> > independently of the CPU. For various reasons the GMU can't come up with
> > the vote itself so we need to construct a vote and send it during
> > initialization.
>
> So it is the kernel which needs to send this vote on behalf of the GMU
> to RPM ? Who does the vote aggregation in this case ? I thought there
> has to be a single vote going from CPU side to the RPM. Isn't the GMU
> vote part of that ?
For clarity the GMU and GPU are in different domains. The GMU (which is
controlled by the CPU) is responsible for generating and sending the vote on
behalf of the GPU. From an RPMh perspective The GPU is considered to be
separate from the CPU vote.
Also, I probably confused you by saying that the kernel constructs the vote
for the GPU. It actually constructs the mapping that the GMU can use to send
the vote. This is equivalent to rpmhpd_update_level_mapping() in the rpmhpd
driver if that helps.
> > For this we duplicate the code that rmphd does to query the
> > cmd-db and build the values using qcom,level as a guide. This is necessary
> > copypasta as the alternative would be to add the hooks into genpd or add a
> > side hook into the rpmhd to get the values we need and none of that is worth
> > it for a few lines of walking an array.
>
> Initially when I was designing this qcom,level or generically called
> "performance-state" thingy, I kept the values directly in the OPP node
> of the consumer (the way you have done it), but then there were
> discussions which forced us to move this to the genpd level. For
> example, what will you do if you also need to pass voltage/current in
> addition to performance-state to the RPM? StephenB actually said we
> may or may not know these values and we must support both the cases.
I agree that genpd has many responsibilities because it has to deal with many
different devices.
The GMU / GPU is built for a single purpose and the hardware has been designed
accordingly. For the foreseeable future we will not need to know anything
beyond the level mapping to operate the GPU.
> The opp-microvolt properties of the consumer device (GPU here) should
> be used to handle the regulators which are controlled by kernel itself
> and so they can't additionally handle the RPMs data. And so we created
> separate OPP table for the RPM and represented that as a genpd and we
> now handle the aggregation in genpd core itself on behalf of all the
> consumers.
Yes and it should continue to be that way. This just happens to be a
situation where one of the consumers is out of your area of control by
design.
> > qcom,level serves the purpose for us in this case because we can get the value
> > we need and construct the vote. If we move to using required-opp, thats just
> > another step of parsing for the driver and
>
> The OPP core shall have all the infrastructure to parse these things
> and we should keep all such code there to avoid duplication.
Using required-opp to look up another opp to look up the qcom,level is
by definition additional parsing. It doesn't imply that there would be
code duplication.
> > it establishes a relationship with
> > rmphd on the CPU that shouldn't exist.
>
> Sure. I am not suggesting that the representation in software should
> be different from what the hardware is, maybe I didn't understood the
> hardware design well.
>
> > I do see a good argument for using the symbolic bindings (i.e.
> > RPMH_REGULATOR_LEVEL_TURBO_L1) and we can do that easily but beyond that I
> > don't think that we need the extra parsing step.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20181015143444.GA4751-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>]
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-15 14:34 ` [Freedreno] " Jordan Crouse
@ 2018-10-22 10:38 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-22 10:38 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
vireshk-DgEjT+Ai2ygdnm+yROfE0A, nm-l0cyMroinI0,
sboyd-DgEjT+Ai2ygdnm+yROfE0A,
niklas.cassel-QSEj5FYQhm4dnm+yROfE0A,
rnayak-sgV2jX0FEOL9JmXXK+q4OQ
On 15-10-18, 08:34, Jordan Crouse wrote:
> I agree that consistency is good. But the GPU is by design outside of the
> control of the genpd universe so it is by design not using the same features.
> It unfortunately does happen to use a similar number in an OPP binding to
> construct the level mapping but since we can't read the cmd-db from the GMU
> space this is a necessary evil.
Where do you define how to use this binding in case of GPU? I mean
some DT binding doc must have some information to avoid confusion as
all other users will have the qcom,level thing in the genpd's OPP
table which GPU will have it directly within its OPP table.
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-22 10:38 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-22 10:38 UTC (permalink / raw)
To: linux-arm-kernel
On 15-10-18, 08:34, Jordan Crouse wrote:
> I agree that consistency is good. But the GPU is by design outside of the
> control of the genpd universe so it is by design not using the same features.
> It unfortunately does happen to use a similar number in an OPP binding to
> construct the level mapping but since we can't read the cmd-db from the GMU
> space this is a necessary evil.
Where do you define how to use this binding in case of GPU? I mean
some DT binding doc must have some information to avoid confusion as
all other users will have the qcom,level thing in the genpd's OPP
table which GPU will have it directly within its OPP table.
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-22 10:38 ` [Freedreno] " Viresh Kumar
@ 2018-10-22 13:20 ` Niklas Cassel
-1 siblings, 0 replies; 72+ messages in thread
From: Niklas Cassel @ 2018-10-22 13:20 UTC (permalink / raw)
To: Viresh Kumar, Jordan Crouse
Cc: nm, devicetree, rnayak, linux-pm, sboyd, linux-arm-msm,
dri-devel, bjorn.andersson, vireshk, freedreno, georgi.djakov,
linux-arm-kernel
On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> On 15-10-18, 08:34, Jordan Crouse wrote:
> > I agree that consistency is good. But the GPU is by design outside of the
> > control of the genpd universe so it is by design not using the same features.
> > It unfortunately does happen to use a similar number in an OPP binding to
> > construct the level mapping but since we can't read the cmd-db from the GMU
> > space this is a necessary evil.
>
> Where do you define how to use this binding in case of GPU? I mean
> some DT binding doc must have some information to avoid confusion as
> all other users will have the qcom,level thing in the genpd's OPP
> table which GPU will have it directly within its OPP table.
Jordan suggested to use the RPMH_REGULATOR_LEVEL_* defines.
These are defined in include/dt-bindings/power/qcom-rpmpd.h.
This header is only referenced in
Documentation/devicetree/bindings/power/qcom,rpmpd.txt
(Which this patch series does not seem to use.)
This patch series does use
Documentation/devicetree/bindings/opp/qcom-opp.txt
but it does not reference include/dt-bindings/power/qcom-rpmpd.h.
So to further avoid confusion, perhaps it is better to create new
defines, instead of reusing the RPMH_REGULATOR_LEVEL_* defines?
Kind regards,
Niklas
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-22 13:20 ` Niklas Cassel
0 siblings, 0 replies; 72+ messages in thread
From: Niklas Cassel @ 2018-10-22 13:20 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> On 15-10-18, 08:34, Jordan Crouse wrote:
> > I agree that consistency is good. But the GPU is by design outside of the
> > control of the genpd universe so it is by design not using the same features.
> > It unfortunately does happen to use a similar number in an OPP binding to
> > construct the level mapping but since we can't read the cmd-db from the GMU
> > space this is a necessary evil.
>
> Where do you define how to use this binding in case of GPU? I mean
> some DT binding doc must have some information to avoid confusion as
> all other users will have the qcom,level thing in the genpd's OPP
> table which GPU will have it directly within its OPP table.
Jordan suggested to use the RPMH_REGULATOR_LEVEL_* defines.
These are defined in include/dt-bindings/power/qcom-rpmpd.h.
This header is only referenced in
Documentation/devicetree/bindings/power/qcom,rpmpd.txt
(Which this patch series does not seem to use.)
This patch series does use
Documentation/devicetree/bindings/opp/qcom-opp.txt
but it does not reference include/dt-bindings/power/qcom-rpmpd.h.
So to further avoid confusion, perhaps it is better to create new
defines, instead of reusing the RPMH_REGULATOR_LEVEL_* defines?
Kind regards,
Niklas
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-22 13:20 ` Niklas Cassel
@ 2018-10-22 14:37 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-22 14:37 UTC (permalink / raw)
To: Niklas Cassel
Cc: nm, devicetree, rnayak, linux-pm, sboyd, Viresh Kumar, dri-devel,
bjorn.andersson, linux-arm-msm, freedreno, georgi.djakov,
linux-arm-kernel, vireshk
On Mon, Oct 22, 2018 at 03:20:27PM +0200, Niklas Cassel wrote:
> On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> > On 15-10-18, 08:34, Jordan Crouse wrote:
> > > I agree that consistency is good. But the GPU is by design outside of the
> > > control of the genpd universe so it is by design not using the same features.
> > > It unfortunately does happen to use a similar number in an OPP binding to
> > > construct the level mapping but since we can't read the cmd-db from the GMU
> > > space this is a necessary evil.
> >
> > Where do you define how to use this binding in case of GPU? I mean
> > some DT binding doc must have some information to avoid confusion as
> > all other users will have the qcom,level thing in the genpd's OPP
> > table which GPU will have it directly within its OPP table.
>
> Jordan suggested to use the RPMH_REGULATOR_LEVEL_* defines.
> These are defined in include/dt-bindings/power/qcom-rpmpd.h.
>
> This header is only referenced in
> Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> (Which this patch series does not seem to use.)
>
> This patch series does use
> Documentation/devicetree/bindings/opp/qcom-opp.txt
> but it does not reference include/dt-bindings/power/qcom-rpmpd.h.
>
> So to further avoid confusion, perhaps it is better to create new
> defines, instead of reusing the RPMH_REGULATOR_LEVEL_* defines?
I would be fine with that. I'm also okay with using the raw values, but I
figure it would resolve Viresh's concerns if it was made clear that the
two use cases were using the same raw values. It would also help the GPU
folks visualize the expected level for each frequency entry.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-22 14:37 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-22 14:37 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 22, 2018 at 03:20:27PM +0200, Niklas Cassel wrote:
> On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> > On 15-10-18, 08:34, Jordan Crouse wrote:
> > > I agree that consistency is good. But the GPU is by design outside of the
> > > control of the genpd universe so it is by design not using the same features.
> > > It unfortunately does happen to use a similar number in an OPP binding to
> > > construct the level mapping but since we can't read the cmd-db from the GMU
> > > space this is a necessary evil.
> >
> > Where do you define how to use this binding in case of GPU? I mean
> > some DT binding doc must have some information to avoid confusion as
> > all other users will have the qcom,level thing in the genpd's OPP
> > table which GPU will have it directly within its OPP table.
>
> Jordan suggested to use the RPMH_REGULATOR_LEVEL_* defines.
> These are defined in include/dt-bindings/power/qcom-rpmpd.h.
>
> This header is only referenced in
> Documentation/devicetree/bindings/power/qcom,rpmpd.txt
> (Which this patch series does not seem to use.)
>
> This patch series does use
> Documentation/devicetree/bindings/opp/qcom-opp.txt
> but it does not reference include/dt-bindings/power/qcom-rpmpd.h.
>
> So to further avoid confusion, perhaps it is better to create new
> defines, instead of reusing the RPMH_REGULATOR_LEVEL_* defines?
I would be fine with that. I'm also okay with using the raw values, but I
figure it would resolve Viresh's concerns if it was made clear that the
two use cases were using the same raw values. It would also help the GPU
folks visualize the expected level for each frequency entry.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-10-22 10:38 ` [Freedreno] " Viresh Kumar
@ 2018-10-22 14:34 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-22 14:34 UTC (permalink / raw)
To: Viresh Kumar
Cc: nm, devicetree, rnayak, linux-pm, sboyd, linux-arm-msm,
dri-devel, bjorn.andersson, vireshk, niklas.cassel, freedreno,
georgi.djakov, linux-arm-kernel
On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> On 15-10-18, 08:34, Jordan Crouse wrote:
> > I agree that consistency is good. But the GPU is by design outside of the
> > control of the genpd universe so it is by design not using the same features.
> > It unfortunately does happen to use a similar number in an OPP binding to
> > construct the level mapping but since we can't read the cmd-db from the GMU
> > space this is a necessary evil.
>
> Where do you define how to use this binding in case of GPU? I mean
> some DT binding doc must have some information to avoid confusion as
> all other users will have the qcom,level thing in the genpd's OPP
> table which GPU will have it directly within its OPP table.
When I first made the patch I was just using existing OPP bindings for GPU
levels as the wording was generic enough to cover both cases. I would be happy
to revisit that and indicate that the OPP bindings apply to RPMh and GPU/GMU
as we've discussed in this thread.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 72+ messages in thread
* [Freedreno] [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-22 14:34 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-22 14:34 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 22, 2018 at 04:08:11PM +0530, Viresh Kumar wrote:
> On 15-10-18, 08:34, Jordan Crouse wrote:
> > I agree that consistency is good. But the GPU is by design outside of the
> > control of the genpd universe so it is by design not using the same features.
> > It unfortunately does happen to use a similar number in an OPP binding to
> > construct the level mapping but since we can't read the cmd-db from the GMU
> > space this is a necessary evil.
>
> Where do you define how to use this binding in case of GPU? I mean
> some DT binding doc must have some information to avoid confusion as
> all other users will have the qcom,level thing in the genpd's OPP
> table which GPU will have it directly within its OPP table.
When I first made the patch I was just using existing OPP bindings for GPU
levels as the wording was generic enough to cover both cases. I would be happy
to revisit that and indicate that the OPP bindings apply to RPMh and GPU/GMU
as we've discussed in this thread.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
2018-08-27 15:11 ` Jordan Crouse
@ 2018-10-17 18:28 ` Doug Anderson
-1 siblings, 0 replies; 72+ messages in thread
From: Doug Anderson @ 2018-10-17 18:28 UTC (permalink / raw)
To: jcrouse-sgV2jX0FEOL9JmXXK+q4OQ
Cc: Nishanth Menon, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, linux-arm-msm,
dri-devel, Bjorn Andersson, vireshk-DgEjT+Ai2ygdnm+yROfE0A,
freedreno, Georgi Djakov, Linux ARM
Hi,
On Mon, Aug 27, 2018 at 8:11 AM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> + gpu@5000000 {
> + compatible = "qcom,adreno-630.2", "qcom,adreno";
> + #stream-id-cells = <16>;
> +
> + reg = <0x5000000 0x40000>;
> + reg-names = "kgsl_3d0_reg_memory";
> +
> + /*
> + * Look ma, no clocks! The GPU clocks and power are
> + * controlled entirely by the GMU
> + */
> +
> + interrupts = <0 300 0>;
> + interrupt-names = "kgsl_3d0_irq";
Drive-by feedback here. The "interrupts" above should be:
interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
* GIC_SPI is 0, but GIC_SPI is more documenting.
* having 0 for the final element means 'IRQ_TYPE_NONE'. On newer
kernels commit 6ef6386ef7c1 ("irqchip/gic-v3: Loudly complain about
the use of IRQ_TYPE_NONE") will cause loud yells if you do this. This
turns out to be a bit silly because (IIUC) the flags in the device
tree are totally ignored if the driver passes in flags itself [1].
...but I guess we should do it right. I believe the code requesting
this irq is a6xx_gmu_get_irq() which requests a level high interrupt,
so we should list level high here.
[1] https://lore.kernel.org/lkml/CAD=FV=XmiOh0Mg0f4a=W0NCH8eb--OQhP2jNAv2ZMpUBOn9n6Q@mail.gmail.com/T/#u
-Doug
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 5/9] arm64: dts: sdm845: Add gpu and gmu device nodes
@ 2018-10-17 18:28 ` Doug Anderson
0 siblings, 0 replies; 72+ messages in thread
From: Doug Anderson @ 2018-10-17 18:28 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Mon, Aug 27, 2018 at 8:11 AM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> + gpu at 5000000 {
> + compatible = "qcom,adreno-630.2", "qcom,adreno";
> + #stream-id-cells = <16>;
> +
> + reg = <0x5000000 0x40000>;
> + reg-names = "kgsl_3d0_reg_memory";
> +
> + /*
> + * Look ma, no clocks! The GPU clocks and power are
> + * controlled entirely by the GMU
> + */
> +
> + interrupts = <0 300 0>;
> + interrupt-names = "kgsl_3d0_irq";
Drive-by feedback here. The "interrupts" above should be:
interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
* GIC_SPI is 0, but GIC_SPI is more documenting.
* having 0 for the final element means 'IRQ_TYPE_NONE'. On newer
kernels commit 6ef6386ef7c1 ("irqchip/gic-v3: Loudly complain about
the use of IRQ_TYPE_NONE") will cause loud yells if you do this. This
turns out to be a bit silly because (IIUC) the flags in the device
tree are totally ignored if the driver passes in flags itself [1].
...but I guess we should do it right. I believe the code requesting
this irq is a6xx_gmu_get_irq() which requests a level high interrupt,
so we should list level high here.
[1] https://lore.kernel.org/lkml/CAD=FV=XmiOh0Mg0f4a=W0NCH8eb--OQhP2jNAv2ZMpUBOn9n6Q at mail.gmail.com/T/#u
-Doug
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-27 15:11 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add the "opp-interconnect-bw" property to specify the
average and peak bandwidth for an interconnect path for
a specific operating power point. A separate bandwidth
pair can be specified for each of the interconnects
defined for the device by appending the interconnect
name to the property.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index c396c4c0af92..d714c084f36d 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -170,6 +170,11 @@ Optional properties:
functioning of the current device at the current OPP (where this property is
present).
+- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
+ and peak bandwidth in bytes per second for the interconnect path known by
+ 'name'. This should match the name(s) specified by interconnect-names in the
+ device definition.
+
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
@@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
};
};
};
+
+Example 7: opp-interconnect-bw:
+(example: leaf device with frequency and BW quotas)
+
+/ {
+ soc {
+ gpu@5000000 {
+ ...
+ interconnects = <&qnoc 26 &qnoc 512>;
+ interconnect-names = "port0";
+ ...
+ operating-points-v2 = <&gpu_opp_table>;
+ };
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp-710000000 {
+ op-hz = /bits/ 64 <710000000>;
+ /* Set peak bandwidth @ 7216000 KB/s */
+ opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
+ };
+
+ opp-210000000 {
+ op-hz = /bits/ 64 <210000000>;
+ /* Set peak bandwidth @ 1200000 KB/s */
+ opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
+ };
+ };
+};
--
2.18.0
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
@ 2018-08-27 15:11 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: linux-arm-kernel
Add the "opp-interconnect-bw" property to specify the
average and peak bandwidth for an interconnect path for
a specific operating power point. A separate bandwidth
pair can be specified for each of the interconnects
defined for the device by appending the interconnect
name to the property.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
index c396c4c0af92..d714c084f36d 100644
--- a/Documentation/devicetree/bindings/opp/opp.txt
+++ b/Documentation/devicetree/bindings/opp/opp.txt
@@ -170,6 +170,11 @@ Optional properties:
functioning of the current device at the current OPP (where this property is
present).
+- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
+ and peak bandwidth in bytes per second for the interconnect path known by
+ 'name'. This should match the name(s) specified by interconnect-names in the
+ device definition.
+
Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
/ {
@@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
};
};
};
+
+Example 7: opp-interconnect-bw:
+(example: leaf device with frequency and BW quotas)
+
+/ {
+ soc {
+ gpu at 5000000 {
+ ...
+ interconnects = <&qnoc 26 &qnoc 512>;
+ interconnect-names = "port0";
+ ...
+ operating-points-v2 = <&gpu_opp_table>;
+ };
+ };
+
+ gpu_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+
+ opp-710000000 {
+ op-hz = /bits/ 64 <710000000>;
+ /* Set peak bandwidth @ 7216000 KB/s */
+ opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
+ };
+
+ opp-210000000 {
+ op-hz = /bits/ 64 <210000000>;
+ /* Set peak bandwidth @ 1200000 KB/s */
+ opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
+ };
+ };
+};
--
2.18.0
^ permalink raw reply related [flat|nested] 72+ messages in thread* Re: [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
2018-08-27 15:11 ` Jordan Crouse
@ 2018-09-27 8:23 ` Georgi Djakov
-1 siblings, 0 replies; 72+ messages in thread
From: Georgi Djakov @ 2018-09-27 8:23 UTC (permalink / raw)
To: Jordan Crouse, linux-pm, devicetree, vireshk, Rob Herring
Cc: nm, sboyd, linux-arm-msm, dri-devel, bjorn.andersson, freedreno,
linux-arm-kernel
Hi Jordan,
Thanks for the patch!
On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> Add the "opp-interconnect-bw" property to specify the
> average and peak bandwidth for an interconnect path for
> a specific operating power point. A separate bandwidth
> pair can be specified for each of the interconnects
> defined for the device by appending the interconnect
> name to the property.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index c396c4c0af92..d714c084f36d 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -170,6 +170,11 @@ Optional properties:
> functioning of the current device at the current OPP (where this property is
> present).
>
> +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> + and peak bandwidth in bytes per second for the interconnect path known by
> + 'name'. This should match the name(s) specified by interconnect-names in the
> + device definition.
> +
> Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>
> / {
> @@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
> };
> };
> };
> +
> +Example 7: opp-interconnect-bw:
> +(example: leaf device with frequency and BW quotas)
> +
> +/ {
> + soc {
> + gpu@5000000 {
> + ...
> + interconnects = <&qnoc 26 &qnoc 512>;
> + interconnect-names = "port0";
> + ...
> + operating-points-v2 = <&gpu_opp_table>;
> + };
> + };
> +
> + gpu_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + opp-710000000 {
> + op-hz = /bits/ 64 <710000000>;
> + /* Set peak bandwidth @ 7216000 KB/s */
> + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
This seems a bit long. I would suggest the following instead.
If there is only one path:
/* average bandwidth = 0 KB/s, peak bandwidth = 7216000 KB/s */
opp-bw-KBps = <0 7216000>;
or
opp-bw-MBps = <0 7216>;
If there are multiple paths:
opp-bw-KBps-port0 = <0 7216000>;
opp-bw-KBps-port1 = <0 1000000>;
The above follows a convention similar to opp-microvolt, where at
runtime the platform can pick a <name> and a matching opp-bw-KBps-<name>
property. If the platform doesn't pick a specific <name> or <name> does
not match with any of the opp-bw-KBps-<name> properties, then
opp-bw-KBps shall be used if present.
For now supporting only KBps values seems enough to cover all present
platforms, so we can start with this and based on the requirements of
future platforms we can add MBps etc.
Thanks,
Georgi
> + };
> +
> + opp-210000000 {
> + op-hz = /bits/ 64 <210000000>;
> + /* Set peak bandwidth @ 1200000 KB/s */
> + opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
> + };
> + };
> +};
>
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
@ 2018-09-27 8:23 ` Georgi Djakov
0 siblings, 0 replies; 72+ messages in thread
From: Georgi Djakov @ 2018-09-27 8:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jordan,
Thanks for the patch!
On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> Add the "opp-interconnect-bw" property to specify the
> average and peak bandwidth for an interconnect path for
> a specific operating power point. A separate bandwidth
> pair can be specified for each of the interconnects
> defined for the device by appending the interconnect
> name to the property.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index c396c4c0af92..d714c084f36d 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -170,6 +170,11 @@ Optional properties:
> functioning of the current device at the current OPP (where this property is
> present).
>
> +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> + and peak bandwidth in bytes per second for the interconnect path known by
> + 'name'. This should match the name(s) specified by interconnect-names in the
> + device definition.
> +
> Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
>
> / {
> @@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
> };
> };
> };
> +
> +Example 7: opp-interconnect-bw:
> +(example: leaf device with frequency and BW quotas)
> +
> +/ {
> + soc {
> + gpu at 5000000 {
> + ...
> + interconnects = <&qnoc 26 &qnoc 512>;
> + interconnect-names = "port0";
> + ...
> + operating-points-v2 = <&gpu_opp_table>;
> + };
> + };
> +
> + gpu_opp_table: opp_table0 {
> + compatible = "operating-points-v2";
> +
> + opp-710000000 {
> + op-hz = /bits/ 64 <710000000>;
> + /* Set peak bandwidth @ 7216000 KB/s */
> + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
This seems a bit long. I would suggest the following instead.
If there is only one path:
/* average bandwidth = 0 KB/s, peak bandwidth = 7216000 KB/s */
opp-bw-KBps = <0 7216000>;
or
opp-bw-MBps = <0 7216>;
If there are multiple paths:
opp-bw-KBps-port0 = <0 7216000>;
opp-bw-KBps-port1 = <0 1000000>;
The above follows a convention similar to opp-microvolt, where at
runtime the platform can pick a <name> and a matching opp-bw-KBps-<name>
property. If the platform doesn't pick a specific <name> or <name> does
not match with any of the opp-bw-KBps-<name> properties, then
opp-bw-KBps shall be used if present.
For now supporting only KBps values seems enough to cover all present
platforms, so we can start with this and based on the requirements of
future platforms we can add MBps etc.
Thanks,
Georgi
> + };
> +
> + opp-210000000 {
> + op-hz = /bits/ 64 <210000000>;
> + /* Set peak bandwidth @ 1200000 KB/s */
> + opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
> + };
> + };
> +};
>
^ permalink raw reply [flat|nested] 72+ messages in thread[parent not found: <0998a374-6cb0-9218-d2e3-92f8ee9861ed-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]
* Re: [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
2018-09-27 8:23 ` Georgi Djakov
@ 2018-10-10 9:59 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 9:59 UTC (permalink / raw)
To: Georgi Djakov
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
sboyd-DgEjT+Ai2ygdnm+yROfE0A, vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Jordan Crouse,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 27-09-18, 11:23, Georgi Djakov wrote:
> On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> > Add the "opp-interconnect-bw" property to specify the
> > average and peak bandwidth for an interconnect path for
> > a specific operating power point. A separate bandwidth
> > pair can be specified for each of the interconnects
> > defined for the device by appending the interconnect
> > name to the property.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> > Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > index c396c4c0af92..d714c084f36d 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -170,6 +170,11 @@ Optional properties:
> > functioning of the current device at the current OPP (where this property is
> > present).
> >
> > +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> > + and peak bandwidth in bytes per second for the interconnect path known by
> > + 'name'. This should match the name(s) specified by interconnect-names in the
> > + device definition.
> > +
> > Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
> >
> > / {
> > @@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
> > };
> > };
> > };
> > +
> > +Example 7: opp-interconnect-bw:
> > +(example: leaf device with frequency and BW quotas)
> > +
> > +/ {
> > + soc {
> > + gpu@5000000 {
> > + ...
> > + interconnects = <&qnoc 26 &qnoc 512>;
> > + interconnect-names = "port0";
> > + ...
> > + operating-points-v2 = <&gpu_opp_table>;
> > + };
> > + };
> > +
> > + gpu_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > +
> > + opp-710000000 {
> > + op-hz = /bits/ 64 <710000000>;
> > + /* Set peak bandwidth @ 7216000 KB/s */
> > + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
>
> This seems a bit long. I would suggest the following instead.
> If there is only one path:
> /* average bandwidth = 0 KB/s, peak bandwidth = 7216000 KB/s */
> opp-bw-KBps = <0 7216000>;
> or
> opp-bw-MBps = <0 7216>;
>
> If there are multiple paths:
> opp-bw-KBps-port0 = <0 7216000>;
> opp-bw-KBps-port1 = <0 1000000>;
>
> The above follows a convention similar to opp-microvolt, where at
> runtime the platform can pick a <name> and a matching opp-bw-KBps-<name>
> property. If the platform doesn't pick a specific <name> or <name> does
> not match with any of the opp-bw-KBps-<name> properties, then
> opp-bw-KBps shall be used if present.
> For now supporting only KBps values seems enough to cover all present
> platforms, so we can start with this and based on the requirements of
> future platforms we can add MBps etc.
+1
And yes I am fine with such bindings getting introduced to the OPP
core.
I am not sure if this would fit well, but have a look at
"required-opps" property in OPP bindings and see if that can be used
instead of adding new bindings here. Again, I am not sure if that
should be done :)
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
@ 2018-10-10 9:59 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 9:59 UTC (permalink / raw)
To: linux-arm-kernel
On 27-09-18, 11:23, Georgi Djakov wrote:
> On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> > Add the "opp-interconnect-bw" property to specify the
> > average and peak bandwidth for an interconnect path for
> > a specific operating power point. A separate bandwidth
> > pair can be specified for each of the interconnects
> > defined for the device by appending the interconnect
> > name to the property.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> > Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > index c396c4c0af92..d714c084f36d 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -170,6 +170,11 @@ Optional properties:
> > functioning of the current device at the current OPP (where this property is
> > present).
> >
> > +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> > + and peak bandwidth in bytes per second for the interconnect path known by
> > + 'name'. This should match the name(s) specified by interconnect-names in the
> > + device definition.
> > +
> > Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
> >
> > / {
> > @@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
> > };
> > };
> > };
> > +
> > +Example 7: opp-interconnect-bw:
> > +(example: leaf device with frequency and BW quotas)
> > +
> > +/ {
> > + soc {
> > + gpu at 5000000 {
> > + ...
> > + interconnects = <&qnoc 26 &qnoc 512>;
> > + interconnect-names = "port0";
> > + ...
> > + operating-points-v2 = <&gpu_opp_table>;
> > + };
> > + };
> > +
> > + gpu_opp_table: opp_table0 {
> > + compatible = "operating-points-v2";
> > +
> > + opp-710000000 {
> > + op-hz = /bits/ 64 <710000000>;
> > + /* Set peak bandwidth @ 7216000 KB/s */
> > + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
>
> This seems a bit long. I would suggest the following instead.
> If there is only one path:
> /* average bandwidth = 0 KB/s, peak bandwidth = 7216000 KB/s */
> opp-bw-KBps = <0 7216000>;
> or
> opp-bw-MBps = <0 7216>;
>
> If there are multiple paths:
> opp-bw-KBps-port0 = <0 7216000>;
> opp-bw-KBps-port1 = <0 1000000>;
>
> The above follows a convention similar to opp-microvolt, where at
> runtime the platform can pick a <name> and a matching opp-bw-KBps-<name>
> property. If the platform doesn't pick a specific <name> or <name> does
> not match with any of the opp-bw-KBps-<name> properties, then
> opp-bw-KBps shall be used if present.
> For now supporting only KBps values seems enough to cover all present
> platforms, so we can start with this and based on the requirements of
> future platforms we can add MBps etc.
+1
And yes I am fine with such bindings getting introduced to the OPP
core.
I am not sure if this would fit well, but have a look at
"required-opps" property in OPP bindings and see if that can be used
instead of adding new bindings here. Again, I am not sure if that
should be done :)
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread* Re: [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
2018-10-10 9:59 ` Viresh Kumar
@ 2018-10-10 14:27 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 14:27 UTC (permalink / raw)
To: Viresh Kumar
Cc: nm-l0cyMroinI0, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
sboyd-DgEjT+Ai2ygdnm+yROfE0A, vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Georgi Djakov,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Wed, Oct 10, 2018 at 03:29:51PM +0530, Viresh Kumar wrote:
> On 27-09-18, 11:23, Georgi Djakov wrote:
> > On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> > > Add the "opp-interconnect-bw" property to specify the
> > > average and peak bandwidth for an interconnect path for
> > > a specific operating power point. A separate bandwidth
> > > pair can be specified for each of the interconnects
> > > defined for the device by appending the interconnect
> > > name to the property.
> > >
> > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > ---
> > > Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> > > 1 file changed, 36 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > > index c396c4c0af92..d714c084f36d 100644
> > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > @@ -170,6 +170,11 @@ Optional properties:
> > > functioning of the current device at the current OPP (where this property is
> > > present).
> > >
> > > +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> > > + and peak bandwidth in bytes per second for the interconnect path known by
> > > + 'name'. This should match the name(s) specified by interconnect-names in the
> > > + device definition.
> > > +
> > > Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
> > >
> > > / {
> > > @@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
> > > };
> > > };
> > > };
> > > +
> > > +Example 7: opp-interconnect-bw:
> > > +(example: leaf device with frequency and BW quotas)
> > > +
> > > +/ {
> > > + soc {
> > > + gpu@5000000 {
> > > + ...
> > > + interconnects = <&qnoc 26 &qnoc 512>;
> > > + interconnect-names = "port0";
> > > + ...
> > > + operating-points-v2 = <&gpu_opp_table>;
> > > + };
> > > + };
> > > +
> > > + gpu_opp_table: opp_table0 {
> > > + compatible = "operating-points-v2";
> > > +
> > > + opp-710000000 {
> > > + op-hz = /bits/ 64 <710000000>;
> > > + /* Set peak bandwidth @ 7216000 KB/s */
> > > + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
> >
> > This seems a bit long. I would suggest the following instead.
> > If there is only one path:
> > /* average bandwidth = 0 KB/s, peak bandwidth = 7216000 KB/s */
> > opp-bw-KBps = <0 7216000>;
> > or
> > opp-bw-MBps = <0 7216>;
> >
> > If there are multiple paths:
> > opp-bw-KBps-port0 = <0 7216000>;
> > opp-bw-KBps-port1 = <0 1000000>;
> >
> > The above follows a convention similar to opp-microvolt, where at
> > runtime the platform can pick a <name> and a matching opp-bw-KBps-<name>
> > property. If the platform doesn't pick a specific <name> or <name> does
> > not match with any of the opp-bw-KBps-<name> properties, then
> > opp-bw-KBps shall be used if present.
> > For now supporting only KBps values seems enough to cover all present
> > platforms, so we can start with this and based on the requirements of
> > future platforms we can add MBps etc.
>
> +1
>
> And yes I am fine with such bindings getting introduced to the OPP
> core.
>
> I am not sure if this would fit well, but have a look at
> "required-opps" property in OPP bindings and see if that can be used
> instead of adding new bindings here. Again, I am not sure if that
> should be done :)
I'm not convinced that required-opps would work. I'm worried that the
format is too vague if we need to use it for multiple paths and possibly
other uses too, consider this:
required-opp = <&mdp_path0_opp3, &mdp_path1_opp5, &mdp_rpmh_opp1>;
This has ordering problems and IMO pollutes the DT namespace for no
great technical advantage. I appreciate the hesitation for opening up
the flood gates for new OPP bindings but we are entering a new era
of hyper power aware devices and some concessions will need to be made.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
@ 2018-10-10 14:27 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-10 14:27 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Oct 10, 2018 at 03:29:51PM +0530, Viresh Kumar wrote:
> On 27-09-18, 11:23, Georgi Djakov wrote:
> > On 08/27/2018 06:11 PM, Jordan Crouse wrote:
> > > Add the "opp-interconnect-bw" property to specify the
> > > average and peak bandwidth for an interconnect path for
> > > a specific operating power point. A separate bandwidth
> > > pair can be specified for each of the interconnects
> > > defined for the device by appending the interconnect
> > > name to the property.
> > >
> > > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > > ---
> > > Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> > > 1 file changed, 36 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > > index c396c4c0af92..d714c084f36d 100644
> > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > @@ -170,6 +170,11 @@ Optional properties:
> > > functioning of the current device at the current OPP (where this property is
> > > present).
> > >
> > > +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> > > + and peak bandwidth in bytes per second for the interconnect path known by
> > > + 'name'. This should match the name(s) specified by interconnect-names in the
> > > + device definition.
> > > +
> > > Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
> > >
> > > / {
> > > @@ -543,3 +548,34 @@ Example 6: opp-microvolt-<name>, opp-microamp-<name>:
> > > };
> > > };
> > > };
> > > +
> > > +Example 7: opp-interconnect-bw:
> > > +(example: leaf device with frequency and BW quotas)
> > > +
> > > +/ {
> > > + soc {
> > > + gpu at 5000000 {
> > > + ...
> > > + interconnects = <&qnoc 26 &qnoc 512>;
> > > + interconnect-names = "port0";
> > > + ...
> > > + operating-points-v2 = <&gpu_opp_table>;
> > > + };
> > > + };
> > > +
> > > + gpu_opp_table: opp_table0 {
> > > + compatible = "operating-points-v2";
> > > +
> > > + opp-710000000 {
> > > + op-hz = /bits/ 64 <710000000>;
> > > + /* Set peak bandwidth @ 7216000 KB/s */
> > > + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
> >
> > This seems a bit long. I would suggest the following instead.
> > If there is only one path:
> > /* average bandwidth = 0 KB/s, peak bandwidth = 7216000 KB/s */
> > opp-bw-KBps = <0 7216000>;
> > or
> > opp-bw-MBps = <0 7216>;
> >
> > If there are multiple paths:
> > opp-bw-KBps-port0 = <0 7216000>;
> > opp-bw-KBps-port1 = <0 1000000>;
> >
> > The above follows a convention similar to opp-microvolt, where at
> > runtime the platform can pick a <name> and a matching opp-bw-KBps-<name>
> > property. If the platform doesn't pick a specific <name> or <name> does
> > not match with any of the opp-bw-KBps-<name> properties, then
> > opp-bw-KBps shall be used if present.
> > For now supporting only KBps values seems enough to cover all present
> > platforms, so we can start with this and based on the requirements of
> > future platforms we can add MBps etc.
>
> +1
>
> And yes I am fine with such bindings getting introduced to the OPP
> core.
>
> I am not sure if this would fit well, but have a look at
> "required-opps" property in OPP bindings and see if that can be used
> instead of adding new bindings here. Again, I am not sure if that
> should be done :)
I'm not convinced that required-opps would work. I'm worried that the
format is too vague if we need to use it for multiple paths and possibly
other uses too, consider this:
required-opp = <&mdp_path0_opp3, &mdp_path1_opp5, &mdp_rpmh_opp1>;
This has ordering problems and IMO pollutes the DT namespace for no
great technical advantage. I appreciate the hesitation for opening up
the flood gates for new OPP bindings but we are entering a new era
of hyper power aware devices and some concessions will need to be made.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread[parent not found: <20181010142723.GA9977-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>]
* Re: [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
2018-10-10 14:27 ` Jordan Crouse
@ 2018-10-10 14:29 ` Viresh Kumar
-1 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 14:29 UTC (permalink / raw)
To: Georgi Djakov, linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
vireshk-DgEjT+Ai2ygdnm+yROfE0A, Rob Herring,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, nm-l0cyMroinI0,
sboyd-DgEjT+Ai2ygdnm+yROfE0A
On 10-10-18, 08:27, Jordan Crouse wrote:
> I'm not convinced that required-opps would work. I'm worried that the
> format is too vague if we need to use it for multiple paths and possibly
> other uses too, consider this:
>
> required-opp = <&mdp_path0_opp3, &mdp_path1_opp5, &mdp_rpmh_opp1>;
>
> This has ordering problems and IMO pollutes the DT namespace for no
> great technical advantage. I appreciate the hesitation for opening up
> the flood gates for new OPP bindings but we are entering a new era
> of hyper power aware devices and some concessions will need to be made.
Sure.
--
viresh
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
@ 2018-10-10 14:29 ` Viresh Kumar
0 siblings, 0 replies; 72+ messages in thread
From: Viresh Kumar @ 2018-10-10 14:29 UTC (permalink / raw)
To: linux-arm-kernel
On 10-10-18, 08:27, Jordan Crouse wrote:
> I'm not convinced that required-opps would work. I'm worried that the
> format is too vague if we need to use it for multiple paths and possibly
> other uses too, consider this:
>
> required-opp = <&mdp_path0_opp3, &mdp_path1_opp5, &mdp_rpmh_opp1>;
>
> This has ordering problems and IMO pollutes the DT namespace for no
> great technical advantage. I appreciate the hesitation for opening up
> the flood gates for new OPP bindings but we are entering a new era
> of hyper power aware devices and some concessions will need to be made.
Sure.
--
viresh
^ permalink raw reply [flat|nested] 72+ messages in thread
[parent not found: <20180827151112.25211-7-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
2018-08-27 15:11 ` Jordan Crouse
@ 2018-10-15 14:34 ` Rob Herring
-1 siblings, 0 replies; 72+ messages in thread
From: Rob Herring @ 2018-10-15 14:34 UTC (permalink / raw)
To: Jordan Crouse
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Aug 27, 2018 at 09:11:09AM -0600, Jordan Crouse wrote:
> Add the "opp-interconnect-bw" property to specify the
> average and peak bandwidth for an interconnect path for
> a specific operating power point. A separate bandwidth
> pair can be specified for each of the interconnects
> defined for the device by appending the interconnect
> name to the property.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index c396c4c0af92..d714c084f36d 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -170,6 +170,11 @@ Optional properties:
> functioning of the current device at the current OPP (where this property is
> present).
>
> +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> + and peak bandwidth in bytes per second for the interconnect path known by
> + 'name'. This should match the name(s) specified by interconnect-names in the
> + device definition.
> +
I don't think this is good design with the name defined in one node and
then used in the OPP table. First, '*-names' is typically the a name
local to that node/device. If you had 2 instances of a device with a
shared OPP table for the 2 instances, then you are going to have to
make the names unique. Second, how exactly would having multiple b/w
entries work? A given OPP frequency supports the sum of the b/w entries?
What if some devices for b/w entries aren't currently active?
This also seems like a mixture of using OPP table for setting GPU's
bandwidth/freq and then the interconnect binding to set the
interconnect's bandwidth. Perhaps we need a more unified approach. Not
sure what that would look like though.
Rob
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
@ 2018-10-15 14:34 ` Rob Herring
0 siblings, 0 replies; 72+ messages in thread
From: Rob Herring @ 2018-10-15 14:34 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 27, 2018 at 09:11:09AM -0600, Jordan Crouse wrote:
> Add the "opp-interconnect-bw" property to specify the
> average and peak bandwidth for an interconnect path for
> a specific operating power point. A separate bandwidth
> pair can be specified for each of the interconnects
> defined for the device by appending the interconnect
> name to the property.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> index c396c4c0af92..d714c084f36d 100644
> --- a/Documentation/devicetree/bindings/opp/opp.txt
> +++ b/Documentation/devicetree/bindings/opp/opp.txt
> @@ -170,6 +170,11 @@ Optional properties:
> functioning of the current device at the current OPP (where this property is
> present).
>
> +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> + and peak bandwidth in bytes per second for the interconnect path known by
> + 'name'. This should match the name(s) specified by interconnect-names in the
> + device definition.
> +
I don't think this is good design with the name defined in one node and
then used in the OPP table. First, '*-names' is typically the a name
local to that node/device. If you had 2 instances of a device with a
shared OPP table for the 2 instances, then you are going to have to
make the names unique. Second, how exactly would having multiple b/w
entries work? A given OPP frequency supports the sum of the b/w entries?
What if some devices for b/w entries aren't currently active?
This also seems like a mixture of using OPP table for setting GPU's
bandwidth/freq and then the interconnect binding to set the
interconnect's bandwidth. Perhaps we need a more unified approach. Not
sure what that would look like though.
Rob
^ permalink raw reply [flat|nested] 72+ messages in thread
* Re: [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
2018-10-15 14:34 ` Rob Herring
@ 2018-10-15 15:12 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-15 15:12 UTC (permalink / raw)
To: Rob Herring
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Oct 15, 2018 at 09:34:20AM -0500, Rob Herring wrote:
> On Mon, Aug 27, 2018 at 09:11:09AM -0600, Jordan Crouse wrote:
> > Add the "opp-interconnect-bw" property to specify the
> > average and peak bandwidth for an interconnect path for
> > a specific operating power point. A separate bandwidth
> > pair can be specified for each of the interconnects
> > defined for the device by appending the interconnect
> > name to the property.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> > Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > index c396c4c0af92..d714c084f36d 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -170,6 +170,11 @@ Optional properties:
> > functioning of the current device at the current OPP (where this property is
> > present).
> >
> > +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> > + and peak bandwidth in bytes per second for the interconnect path known by
> > + 'name'. This should match the name(s) specified by interconnect-names in the
> > + device definition.
> > +
>
> I don't think this is good design with the name defined in one node and
> then used in the OPP table. First, '*-names' is typically the a name
> local to that node/device. If you had 2 instances of a device with a
> shared OPP table for the 2 instances, then you are going to have to
> make the names unique. Second, how exactly would having multiple b/w
> entries work? A given OPP frequency supports the sum of the b/w entries?
> What if some devices for b/w entries aren't currently active?
For device that is fully scalable a given OPP frequency could need a
different quota for multiple interconnect entries - each one would be
programmed individually, something like this:
set_opp() {
set_device_frequency(opp);
for each interconnect name {
get_device_bw(opp, name);
icc_set(name, bw);
}
}
And the naming scheme gives you the flexibility to choose the icc names
you need. For example if port0 was always fixed and port1 scaled you could
specify the b/w for port1 without having to also have a dummy vote for port0.
The main reason I included the names was that I felt it had a potential to
be confusing if we used absolute indexes or some other implied scheme - at
least for the driver developer it makes slightly more sense to look up the
bandwidth for "port0" with the same name you used to register the interconnect.
> This also seems like a mixture of using OPP table for setting GPU's
> bandwidth/freq and then the interconnect binding to set the
> interconnect's bandwidth. Perhaps we need a more unified approach. Not
> sure what that would look like though.
In a perfect world the interconnect(s) would be left to scale on their own
and they wouldn't be tied to an individual device frequency. But that would
involve significantly more infrastructure for a given device.
Also in RE to our other discussion with Viresh on the qcom,level for the
GPU; the GPU frequency vote is done by the microcontroller but the
interconnect bandwidth is set by the CPU on the sdm845 so we're already
not unified by design. There could be something out there that uses
magic and callbacks but I also don't know what that looks like.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 6/9] PM / OPP: dt-bindings: Add opp-interconnect-bw
@ 2018-10-15 15:12 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-15 15:12 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Oct 15, 2018 at 09:34:20AM -0500, Rob Herring wrote:
> On Mon, Aug 27, 2018 at 09:11:09AM -0600, Jordan Crouse wrote:
> > Add the "opp-interconnect-bw" property to specify the
> > average and peak bandwidth for an interconnect path for
> > a specific operating power point. A separate bandwidth
> > pair can be specified for each of the interconnects
> > defined for the device by appending the interconnect
> > name to the property.
> >
> > Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> > ---
> > Documentation/devicetree/bindings/opp/opp.txt | 36 +++++++++++++++++++
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/opp/opp.txt b/Documentation/devicetree/bindings/opp/opp.txt
> > index c396c4c0af92..d714c084f36d 100644
> > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > @@ -170,6 +170,11 @@ Optional properties:
> > functioning of the current device at the current OPP (where this property is
> > present).
> >
> > +- opp-interconnect-bw-<name>: This is an array of pairs specifying the average
> > + and peak bandwidth in bytes per second for the interconnect path known by
> > + 'name'. This should match the name(s) specified by interconnect-names in the
> > + device definition.
> > +
>
> I don't think this is good design with the name defined in one node and
> then used in the OPP table. First, '*-names' is typically the a name
> local to that node/device. If you had 2 instances of a device with a
> shared OPP table for the 2 instances, then you are going to have to
> make the names unique. Second, how exactly would having multiple b/w
> entries work? A given OPP frequency supports the sum of the b/w entries?
> What if some devices for b/w entries aren't currently active?
For device that is fully scalable a given OPP frequency could need a
different quota for multiple interconnect entries - each one would be
programmed individually, something like this:
set_opp() {
set_device_frequency(opp);
for each interconnect name {
get_device_bw(opp, name);
icc_set(name, bw);
}
}
And the naming scheme gives you the flexibility to choose the icc names
you need. For example if port0 was always fixed and port1 scaled you could
specify the b/w for port1 without having to also have a dummy vote for port0.
The main reason I included the names was that I felt it had a potential to
be confusing if we used absolute indexes or some other implied scheme - at
least for the driver developer it makes slightly more sense to look up the
bandwidth for "port0" with the same name you used to register the interconnect.
> This also seems like a mixture of using OPP table for setting GPU's
> bandwidth/freq and then the interconnect binding to set the
> interconnect's bandwidth. Perhaps we need a more unified approach. Not
> sure what that would look like though.
In a perfect world the interconnect(s) would be left to scale on their own
and they wouldn't be tied to an individual device frequency. But that would
involve significantly more infrastructure for a given device.
Also in RE to our other discussion with Viresh on the qcom,level for the
GPU; the GPU frequency vote is done by the microcontroller but the
interconnect bandwidth is set by the CPU on the sdm845 so we're already
not unified by design. There could be something out there that uses
magic and callbacks but I also don't know what that looks like.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 7/9] OPP: Add dev_pm_opp_get_interconnect_bw()
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-27 15:11 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add dev_pm_opp_get_interconnect_bw() to read the interconnect
bandwidth values for a given OPP.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/opp/of.c | 36 ++++++++++++++++++++++++++++++++++++
include/linux/pm_opp.h | 7 +++++++
2 files changed, 43 insertions(+)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 7af0ddec936b..6a5eecaaf8c1 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -777,3 +777,39 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
return of_node_get(opp->np);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
+
+/**
+ * dev_pm_opp_get_interconnect_bw() - Get the interconnect bandwidth for the opp
+ * @opp: opp containing the bandwidth values
+ * @pathname: name of the interconnect path for the bandwidth values
+ * @avgbw: Pointer for the value to hold the average BW defined for the OPP
+ * @peakbw: Pointer for the value to hold the peak BW defined for the OPP
+ *
+ * Return: Negative value on error or 0 on success
+ */
+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp,
+ const char *pathname, u64 *avgbw, u64 *peakbw)
+{
+ char name[NAME_MAX];
+ struct property *prop;
+ int count;
+
+ if (IS_ERR_OR_NULL(opp))
+ return -ENOENT;
+
+ snprintf(name, NAME_MAX, "opp-interconnect-bw-%s", pathname);
+ prop = of_find_property(opp->np, name, NULL);
+
+ if (!prop)
+ return -ENOENT;
+
+ count = of_property_count_u64_elems(opp->np, name);
+ if (count != 2)
+ return -EINVAL;
+
+ of_property_read_u64_index(opp->np, name, 0, avgbw);
+ of_property_read_u64_index(opp->np, name, 0, peakbw);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_interconnect_bw);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 099b31960dec..70e49e259d0e 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -301,6 +301,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpuma
struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, struct device_node *np);
struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname, u64 *avgbw, u64 *peakbw);
#else
static inline int dev_pm_opp_of_add_table(struct device *dev)
{
@@ -343,6 +344,12 @@ static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
{
return NULL;
}
+
+static inline int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname,
+ u64 *avgbw, u64 *peakbw)
+{
+ return -ENOTSUPP;
+}
#endif
#endif /* __LINUX_OPP_H__ */
--
2.18.0
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH 7/9] OPP: Add dev_pm_opp_get_interconnect_bw()
@ 2018-08-27 15:11 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: linux-arm-kernel
Add dev_pm_opp_get_interconnect_bw() to read the interconnect
bandwidth values for a given OPP.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/opp/of.c | 36 ++++++++++++++++++++++++++++++++++++
include/linux/pm_opp.h | 7 +++++++
2 files changed, 43 insertions(+)
diff --git a/drivers/opp/of.c b/drivers/opp/of.c
index 7af0ddec936b..6a5eecaaf8c1 100644
--- a/drivers/opp/of.c
+++ b/drivers/opp/of.c
@@ -777,3 +777,39 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
return of_node_get(opp->np);
}
EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
+
+/**
+ * dev_pm_opp_get_interconnect_bw() - Get the interconnect bandwidth for the opp
+ * @opp: opp containing the bandwidth values
+ * @pathname: name of the interconnect path for the bandwidth values
+ * @avgbw: Pointer for the value to hold the average BW defined for the OPP
+ * @peakbw: Pointer for the value to hold the peak BW defined for the OPP
+ *
+ * Return: Negative value on error or 0 on success
+ */
+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp,
+ const char *pathname, u64 *avgbw, u64 *peakbw)
+{
+ char name[NAME_MAX];
+ struct property *prop;
+ int count;
+
+ if (IS_ERR_OR_NULL(opp))
+ return -ENOENT;
+
+ snprintf(name, NAME_MAX, "opp-interconnect-bw-%s", pathname);
+ prop = of_find_property(opp->np, name, NULL);
+
+ if (!prop)
+ return -ENOENT;
+
+ count = of_property_count_u64_elems(opp->np, name);
+ if (count != 2)
+ return -EINVAL;
+
+ of_property_read_u64_index(opp->np, name, 0, avgbw);
+ of_property_read_u64_index(opp->np, name, 0, peakbw);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_interconnect_bw);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 099b31960dec..70e49e259d0e 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -301,6 +301,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpuma
struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, struct device_node *np);
struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname, u64 *avgbw, u64 *peakbw);
#else
static inline int dev_pm_opp_of_add_table(struct device *dev)
{
@@ -343,6 +344,12 @@ static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
{
return NULL;
}
+
+static inline int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname,
+ u64 *avgbw, u64 *peakbw)
+{
+ return -ENOTSUPP;
+}
#endif
#endif /* __LINUX_OPP_H__ */
--
2.18.0
^ permalink raw reply related [flat|nested] 72+ messages in thread[parent not found: <20180827151112.25211-8-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 7/9] OPP: Add dev_pm_opp_get_interconnect_bw()
2018-08-27 15:11 ` Jordan Crouse
@ 2018-10-05 6:36 ` Sharat Masetty
-1 siblings, 0 replies; 72+ messages in thread
From: Sharat Masetty @ 2018-10-05 6:36 UTC (permalink / raw)
To: Jordan Crouse, freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On 8/27/2018 8:41 PM, Jordan Crouse wrote:
> Add dev_pm_opp_get_interconnect_bw() to read the interconnect
> bandwidth values for a given OPP.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> drivers/opp/of.c | 36 ++++++++++++++++++++++++++++++++++++
> include/linux/pm_opp.h | 7 +++++++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 7af0ddec936b..6a5eecaaf8c1 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -777,3 +777,39 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> return of_node_get(opp->np);
> }
> EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
> +
> +/**
> + * dev_pm_opp_get_interconnect_bw() - Get the interconnect bandwidth for the opp
> + * @opp: opp containing the bandwidth values
> + * @pathname: name of the interconnect path for the bandwidth values
> + * @avgbw: Pointer for the value to hold the average BW defined for the OPP
> + * @peakbw: Pointer for the value to hold the peak BW defined for the OPP
> + *
> + * Return: Negative value on error or 0 on success
> + */
> +int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp,
> + const char *pathname, u64 *avgbw, u64 *peakbw)
> +{
> + char name[NAME_MAX];
> + struct property *prop;
> + int count;
> +
> + if (IS_ERR_OR_NULL(opp))
> + return -ENOENT;
> +
> + snprintf(name, NAME_MAX, "opp-interconnect-bw-%s", pathname);
> + prop = of_find_property(opp->np, name, NULL);
> +
> + if (!prop)
> + return -ENOENT;
> +
> + count = of_property_count_u64_elems(opp->np, name);
> + if (count != 2)
> + return -EINVAL;
> +
> + of_property_read_u64_index(opp->np, name, 0, avgbw);
> + of_property_read_u64_index(opp->np, name, 0, peakbw);
This should be index 1 for peak bandwidth
of_property_read_u64_index(opp->np, name, 1, peakbw);
I tested with this fix and the GPU's interconnect summary now shows
non zero values for peak bandwidth. Can you please raise a newer version
of this patch? I will have it pulled into our downstream builds.
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_get_interconnect_bw);
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index 099b31960dec..70e49e259d0e 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -301,6 +301,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpuma
> struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
> struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, struct device_node *np);
> struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
> +int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname, u64 *avgbw, u64 *peakbw);
> #else
> static inline int dev_pm_opp_of_add_table(struct device *dev)
> {
> @@ -343,6 +344,12 @@ static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> {
> return NULL;
> }
> +
> +static inline int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname,
> + u64 *avgbw, u64 *peakbw)
> +{
> + return -ENOTSUPP;
> +}
> #endif
>
> #endif /* __LINUX_OPP_H__ */
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 7/9] OPP: Add dev_pm_opp_get_interconnect_bw()
@ 2018-10-05 6:36 ` Sharat Masetty
0 siblings, 0 replies; 72+ messages in thread
From: Sharat Masetty @ 2018-10-05 6:36 UTC (permalink / raw)
To: linux-arm-kernel
On 8/27/2018 8:41 PM, Jordan Crouse wrote:
> Add dev_pm_opp_get_interconnect_bw() to read the interconnect
> bandwidth values for a given OPP.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> drivers/opp/of.c | 36 ++++++++++++++++++++++++++++++++++++
> include/linux/pm_opp.h | 7 +++++++
> 2 files changed, 43 insertions(+)
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index 7af0ddec936b..6a5eecaaf8c1 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -777,3 +777,39 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> return of_node_get(opp->np);
> }
> EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
> +
> +/**
> + * dev_pm_opp_get_interconnect_bw() - Get the interconnect bandwidth for the opp
> + * @opp: opp containing the bandwidth values
> + * @pathname: name of the interconnect path for the bandwidth values
> + * @avgbw: Pointer for the value to hold the average BW defined for the OPP
> + * @peakbw: Pointer for the value to hold the peak BW defined for the OPP
> + *
> + * Return: Negative value on error or 0 on success
> + */
> +int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp,
> + const char *pathname, u64 *avgbw, u64 *peakbw)
> +{
> + char name[NAME_MAX];
> + struct property *prop;
> + int count;
> +
> + if (IS_ERR_OR_NULL(opp))
> + return -ENOENT;
> +
> + snprintf(name, NAME_MAX, "opp-interconnect-bw-%s", pathname);
> + prop = of_find_property(opp->np, name, NULL);
> +
> + if (!prop)
> + return -ENOENT;
> +
> + count = of_property_count_u64_elems(opp->np, name);
> + if (count != 2)
> + return -EINVAL;
> +
> + of_property_read_u64_index(opp->np, name, 0, avgbw);
> + of_property_read_u64_index(opp->np, name, 0, peakbw);
This should be index 1 for peak bandwidth
of_property_read_u64_index(opp->np, name, 1, peakbw);
I tested with this fix and the GPU's interconnect summary now shows
non zero values for peak bandwidth. Can you please raise a newer version
of this patch? I will have it pulled into our downstream builds.
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(dev_pm_opp_get_interconnect_bw);
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index 099b31960dec..70e49e259d0e 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -301,6 +301,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpuma
> struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
> struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, struct device_node *np);
> struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
> +int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname, u64 *avgbw, u64 *peakbw);
> #else
> static inline int dev_pm_opp_of_add_table(struct device *dev)
> {
> @@ -343,6 +344,12 @@ static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> {
> return NULL;
> }
> +
> +static inline int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname,
> + u64 *avgbw, u64 *peakbw)
> +{
> + return -ENOTSUPP;
> +}
> #endif
>
> #endif /* __LINUX_OPP_H__ */
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread[parent not found: <49858ede-66db-b58f-e586-411896efad4b-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 7/9] OPP: Add dev_pm_opp_get_interconnect_bw()
2018-10-05 6:36 ` Sharat Masetty
@ 2018-10-05 17:13 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-05 17:13 UTC (permalink / raw)
To: Sharat Masetty
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Fri, Oct 05, 2018 at 12:06:06PM +0530, Sharat Masetty wrote:
>
>
> On 8/27/2018 8:41 PM, Jordan Crouse wrote:
> >Add dev_pm_opp_get_interconnect_bw() to read the interconnect
> >bandwidth values for a given OPP.
> >
> >Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> >---
> > drivers/opp/of.c | 36 ++++++++++++++++++++++++++++++++++++
> > include/linux/pm_opp.h | 7 +++++++
> > 2 files changed, 43 insertions(+)
> >
> >diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> >index 7af0ddec936b..6a5eecaaf8c1 100644
> >--- a/drivers/opp/of.c
> >+++ b/drivers/opp/of.c
> >@@ -777,3 +777,39 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> > return of_node_get(opp->np);
> > }
> > EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
> >+
> >+/**
> >+ * dev_pm_opp_get_interconnect_bw() - Get the interconnect bandwidth for the opp
> >+ * @opp: opp containing the bandwidth values
> >+ * @pathname: name of the interconnect path for the bandwidth values
> >+ * @avgbw: Pointer for the value to hold the average BW defined for the OPP
> >+ * @peakbw: Pointer for the value to hold the peak BW defined for the OPP
> >+ *
> >+ * Return: Negative value on error or 0 on success
> >+ */
> >+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp,
> >+ const char *pathname, u64 *avgbw, u64 *peakbw)
> >+{
> >+ char name[NAME_MAX];
> >+ struct property *prop;
> >+ int count;
> >+
> >+ if (IS_ERR_OR_NULL(opp))
> >+ return -ENOENT;
> >+
> >+ snprintf(name, NAME_MAX, "opp-interconnect-bw-%s", pathname);
> >+ prop = of_find_property(opp->np, name, NULL);
> >+
> >+ if (!prop)
> >+ return -ENOENT;
> >+
> >+ count = of_property_count_u64_elems(opp->np, name);
> >+ if (count != 2)
> >+ return -EINVAL;
> >+
> >+ of_property_read_u64_index(opp->np, name, 0, avgbw);
> >+ of_property_read_u64_index(opp->np, name, 0, peakbw);
> This should be index 1 for peak bandwidth
> of_property_read_u64_index(opp->np, name, 1, peakbw);
> I tested with this fix and the GPU's interconnect summary now shows
> non zero values for peak bandwidth. Can you please raise a newer
> version of this patch? I will have it pulled into our downstream
> builds.
Ahhh! I can generate a new one but I think we should come to an agreement on the
bindings.
Jordan
> >+
> >+ return 0;
> >+}
> >+EXPORT_SYMBOL_GPL(dev_pm_opp_get_interconnect_bw);
> >diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> >index 099b31960dec..70e49e259d0e 100644
> >--- a/include/linux/pm_opp.h
> >+++ b/include/linux/pm_opp.h
> >@@ -301,6 +301,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpuma
> > struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
> > struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, struct device_node *np);
> > struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
> >+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname, u64 *avgbw, u64 *peakbw);
> > #else
> > static inline int dev_pm_opp_of_add_table(struct device *dev)
> > {
> >@@ -343,6 +344,12 @@ static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> > {
> > return NULL;
> > }
> >+
> >+static inline int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname,
> >+ u64 *avgbw, u64 *peakbw)
> >+{
> >+ return -ENOTSUPP;
> >+}
> > #endif
> > #endif /* __LINUX_OPP_H__ */
> >
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> Linux Foundation Collaborative Project
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 7/9] OPP: Add dev_pm_opp_get_interconnect_bw()
@ 2018-10-05 17:13 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-10-05 17:13 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Oct 05, 2018 at 12:06:06PM +0530, Sharat Masetty wrote:
>
>
> On 8/27/2018 8:41 PM, Jordan Crouse wrote:
> >Add dev_pm_opp_get_interconnect_bw() to read the interconnect
> >bandwidth values for a given OPP.
> >
> >Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> >---
> > drivers/opp/of.c | 36 ++++++++++++++++++++++++++++++++++++
> > include/linux/pm_opp.h | 7 +++++++
> > 2 files changed, 43 insertions(+)
> >
> >diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> >index 7af0ddec936b..6a5eecaaf8c1 100644
> >--- a/drivers/opp/of.c
> >+++ b/drivers/opp/of.c
> >@@ -777,3 +777,39 @@ struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> > return of_node_get(opp->np);
> > }
> > EXPORT_SYMBOL_GPL(dev_pm_opp_get_of_node);
> >+
> >+/**
> >+ * dev_pm_opp_get_interconnect_bw() - Get the interconnect bandwidth for the opp
> >+ * @opp: opp containing the bandwidth values
> >+ * @pathname: name of the interconnect path for the bandwidth values
> >+ * @avgbw: Pointer for the value to hold the average BW defined for the OPP
> >+ * @peakbw: Pointer for the value to hold the peak BW defined for the OPP
> >+ *
> >+ * Return: Negative value on error or 0 on success
> >+ */
> >+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp,
> >+ const char *pathname, u64 *avgbw, u64 *peakbw)
> >+{
> >+ char name[NAME_MAX];
> >+ struct property *prop;
> >+ int count;
> >+
> >+ if (IS_ERR_OR_NULL(opp))
> >+ return -ENOENT;
> >+
> >+ snprintf(name, NAME_MAX, "opp-interconnect-bw-%s", pathname);
> >+ prop = of_find_property(opp->np, name, NULL);
> >+
> >+ if (!prop)
> >+ return -ENOENT;
> >+
> >+ count = of_property_count_u64_elems(opp->np, name);
> >+ if (count != 2)
> >+ return -EINVAL;
> >+
> >+ of_property_read_u64_index(opp->np, name, 0, avgbw);
> >+ of_property_read_u64_index(opp->np, name, 0, peakbw);
> This should be index 1 for peak bandwidth
> of_property_read_u64_index(opp->np, name, 1, peakbw);
> I tested with this fix and the GPU's interconnect summary now shows
> non zero values for peak bandwidth. Can you please raise a newer
> version of this patch? I will have it pulled into our downstream
> builds.
Ahhh! I can generate a new one but I think we should come to an agreement on the
bindings.
Jordan
> >+
> >+ return 0;
> >+}
> >+EXPORT_SYMBOL_GPL(dev_pm_opp_get_interconnect_bw);
> >diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> >index 099b31960dec..70e49e259d0e 100644
> >--- a/include/linux/pm_opp.h
> >+++ b/include/linux/pm_opp.h
> >@@ -301,6 +301,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpuma
> > struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
> > struct dev_pm_opp *of_dev_pm_opp_find_required_opp(struct device *dev, struct device_node *np);
> > struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp);
> >+int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname, u64 *avgbw, u64 *peakbw);
> > #else
> > static inline int dev_pm_opp_of_add_table(struct device *dev)
> > {
> >@@ -343,6 +344,12 @@ static inline struct device_node *dev_pm_opp_get_of_node(struct dev_pm_opp *opp)
> > {
> > return NULL;
> > }
> >+
> >+static inline int dev_pm_opp_get_interconnect_bw(struct dev_pm_opp *opp, const char *pathname,
> >+ u64 *avgbw, u64 *peakbw)
> >+{
> >+ return -ENOTSUPP;
> >+}
> > #endif
> > #endif /* __LINUX_OPP_H__ */
> >
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> Linux Foundation Collaborative Project
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 8/9] drm/msm/a6xx: Add support for an interconnect path
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-27 15:11 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add support for setting the OPP defined bandwidth for a given
GPU frequency value for a6xx. On sdm845 even though the GPU
frequency is set by the GMU but the bus bandwidth quota is
set by the CPU.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 27 +++++++++++++++++++++++--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 7 +++++++
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index d0dac4c2e3e7..d63eefc7c74d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -4,6 +4,7 @@
#include <linux/clk.h>
#include <linux/iopoll.h>
#include <linux/pm_opp.h>
+#include <linux/interconnect.h>
#include <soc/qcom/cmd-db.h>
#include "a6xx_gpu.h"
@@ -65,8 +66,15 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
}
-static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+static void a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
+ struct dev_pm_opp *opp;
+ u64 ab, ib;
+ int ret;
+
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
@@ -82,7 +90,22 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
- return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ if (ret)
+ dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
+
+ /* Set the interconnect bandwidth from the CPU */
+ if (IS_ERR_OR_NULL(gpu->icc_path))
+ return;
+
+ opp = dev_pm_opp_find_freq_exact(&gpu->pdev->dev,
+ gmu->gpu_freqs[index], true);
+ if (!IS_ERR_OR_NULL(opp)) {
+ if (!dev_pm_opp_get_interconnect_bw(opp, "port0", &ab, &ib))
+ icc_set(gpu->icc_path, ab, ib);
+
+ dev_pm_opp_put(opp);
+ }
}
static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index da1363a0c54d..2eace9bf32c7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,7 @@
#include <linux/kernel.h>
#include <linux/pm_opp.h>
#include <linux/slab.h>
+#include <linux/interconnect.h>
#include "adreno_gpu.h"
#include "msm_gem.h"
#include "msm_mmu.h"
@@ -694,6 +695,9 @@ static int adreno_get_pwrlevels(struct device *dev,
DBG("fast_rate=%u, slow_rate=27000000", gpu->fast_rate);
+ /* Check for an interconnect path for the bus */
+ gpu->icc_path = of_icc_get(dev, "port0");
+
return 0;
}
@@ -732,10 +736,13 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
{
+ struct msm_gpu *gpu = &adreno_gpu->base;
unsigned int i;
for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
release_firmware(adreno_gpu->fw[i]);
+ icc_put(gpu->icc_path);
+
msm_gpu_cleanup(&adreno_gpu->base);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 9122ee6e55e4..9c851d03f344 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -20,6 +20,7 @@
#include <linux/clk.h>
#include <linux/regulator/consumer.h>
+#include <linux/interconnect.h>
#include "msm_drv.h"
#include "msm_fence.h"
@@ -117,6 +118,8 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;
+ struct icc_path *icc_path;
+
/* Hang and Inactivity Detection:
*/
#define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
--
2.18.0
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH 8/9] drm/msm/a6xx: Add support for an interconnect path
@ 2018-08-27 15:11 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: linux-arm-kernel
Add support for setting the OPP defined bandwidth for a given
GPU frequency value for a6xx. On sdm845 even though the GPU
frequency is set by the GMU but the bus bandwidth quota is
set by the CPU.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 27 +++++++++++++++++++++++--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 7 +++++++
drivers/gpu/drm/msm/msm_gpu.h | 3 +++
3 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index d0dac4c2e3e7..d63eefc7c74d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -4,6 +4,7 @@
#include <linux/clk.h>
#include <linux/iopoll.h>
#include <linux/pm_opp.h>
+#include <linux/interconnect.h>
#include <soc/qcom/cmd-db.h>
#include "a6xx_gpu.h"
@@ -65,8 +66,15 @@ static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_CLK_OFF));
}
-static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
+static void a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
{
+ struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);
+ struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
+ struct msm_gpu *gpu = &adreno_gpu->base;
+ struct dev_pm_opp *opp;
+ u64 ab, ib;
+ int ret;
+
gmu_write(gmu, REG_A6XX_GMU_DCVS_ACK_OPTION, 0);
gmu_write(gmu, REG_A6XX_GMU_DCVS_PERF_SETTING,
@@ -82,7 +90,22 @@ static int a6xx_gmu_set_freq(struct a6xx_gmu *gmu, int index)
a6xx_gmu_set_oob(gmu, GMU_OOB_DCVS_SET);
a6xx_gmu_clear_oob(gmu, GMU_OOB_DCVS_SET);
- return gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ ret = gmu_read(gmu, REG_A6XX_GMU_DCVS_RETURN);
+ if (ret)
+ dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
+
+ /* Set the interconnect bandwidth from the CPU */
+ if (IS_ERR_OR_NULL(gpu->icc_path))
+ return;
+
+ opp = dev_pm_opp_find_freq_exact(&gpu->pdev->dev,
+ gmu->gpu_freqs[index], true);
+ if (!IS_ERR_OR_NULL(opp)) {
+ if (!dev_pm_opp_get_interconnect_bw(opp, "port0", &ab, &ib))
+ icc_set(gpu->icc_path, ab, ib);
+
+ dev_pm_opp_put(opp);
+ }
}
static bool a6xx_gmu_check_idle_level(struct a6xx_gmu *gmu)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index da1363a0c54d..2eace9bf32c7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,6 +21,7 @@
#include <linux/kernel.h>
#include <linux/pm_opp.h>
#include <linux/slab.h>
+#include <linux/interconnect.h>
#include "adreno_gpu.h"
#include "msm_gem.h"
#include "msm_mmu.h"
@@ -694,6 +695,9 @@ static int adreno_get_pwrlevels(struct device *dev,
DBG("fast_rate=%u, slow_rate=27000000", gpu->fast_rate);
+ /* Check for an interconnect path for the bus */
+ gpu->icc_path = of_icc_get(dev, "port0");
+
return 0;
}
@@ -732,10 +736,13 @@ int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
{
+ struct msm_gpu *gpu = &adreno_gpu->base;
unsigned int i;
for (i = 0; i < ARRAY_SIZE(adreno_gpu->info->fw); i++)
release_firmware(adreno_gpu->fw[i]);
+ icc_put(gpu->icc_path);
+
msm_gpu_cleanup(&adreno_gpu->base);
}
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 9122ee6e55e4..9c851d03f344 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -20,6 +20,7 @@
#include <linux/clk.h>
#include <linux/regulator/consumer.h>
+#include <linux/interconnect.h>
#include "msm_drv.h"
#include "msm_fence.h"
@@ -117,6 +118,8 @@ struct msm_gpu {
struct clk *ebi1_clk, *core_clk, *rbbmtimer_clk;
uint32_t fast_rate;
+ struct icc_path *icc_path;
+
/* Hang and Inactivity Detection:
*/
#define DRM_MSM_INACTIVE_PERIOD 66 /* in ms (roughly four frames) */
--
2.18.0
^ permalink raw reply related [flat|nested] 72+ messages in thread[parent not found: <20180827151112.25211-9-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 8/9] drm/msm/a6xx: Add support for an interconnect path
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-28 1:23 ` kbuild test robot
-1 siblings, 0 replies; 72+ messages in thread
From: kbuild test robot @ 2018-08-28 1:23 UTC (permalink / raw)
To: Jordan Crouse
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, kbuild-all-JC7UmRfGjtg,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.19-rc1 next-20180827]
[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/Jordan-Crouse/Add-interconnect-support-bindings-for-A630-GPU/20180828-004407
base: git://people.freedesktop.org/~robclark/linux msm-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/msm/adreno/adreno_gpu.h:25:0,
from drivers/gpu/drm/msm/adreno/adreno_device.c:20:
>> drivers/gpu/drm/msm/msm_gpu.h:23:10: fatal error: linux/interconnect.h: No such file or directory
#include <linux/interconnect.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
--
>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:24:10: fatal error: linux/interconnect.h: No such file or directory
#include <linux/interconnect.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
--
>> drivers/gpu/drm/msm/adreno/a6xx_gmu.c:7:10: fatal error: linux/interconnect.h: No such file or directory
#include <linux/interconnect.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +23 drivers/gpu/drm/msm/msm_gpu.h
20
21 #include <linux/clk.h>
22 #include <linux/regulator/consumer.h>
> 23 #include <linux/interconnect.h>
24
---
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: 43978 bytes --]
[-- Attachment #3: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [PATCH 8/9] drm/msm/a6xx: Add support for an interconnect path
@ 2018-08-28 1:23 ` kbuild test robot
0 siblings, 0 replies; 72+ messages in thread
From: kbuild test robot @ 2018-08-28 1:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on v4.19-rc1 next-20180827]
[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/Jordan-Crouse/Add-interconnect-support-bindings-for-A630-GPU/20180828-004407
base: git://people.freedesktop.org/~robclark/linux msm-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=arm
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/msm/adreno/adreno_gpu.h:25:0,
from drivers/gpu/drm/msm/adreno/adreno_device.c:20:
>> drivers/gpu/drm/msm/msm_gpu.h:23:10: fatal error: linux/interconnect.h: No such file or directory
#include <linux/interconnect.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
--
>> drivers/gpu/drm/msm/adreno/adreno_gpu.c:24:10: fatal error: linux/interconnect.h: No such file or directory
#include <linux/interconnect.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
--
>> drivers/gpu/drm/msm/adreno/a6xx_gmu.c:7:10: fatal error: linux/interconnect.h: No such file or directory
#include <linux/interconnect.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +23 drivers/gpu/drm/msm/msm_gpu.h
20
21 #include <linux/clk.h>
22 #include <linux/regulator/consumer.h>
> 23 #include <linux/interconnect.h>
24
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 43978 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180828/84a48c24/attachment-0001.gz>
^ permalink raw reply [flat|nested] 72+ messages in thread
* [PATCH 9/9] arm64: dts: Add interconnect for the GPU on SDM845
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-27 15:11 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Add the interconnect properties for the GPU on SDM845
and set the corresponding OPP bandwidth values.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 10db0ceb3699..1e67f4fdd7d1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -198,36 +198,43 @@ gpu_opp_table: adreno-opp-table {
opp-710000000 {
opp-hz = /bits/ 64 <710000000>;
qcom,level = <416>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
};
opp-675000000 {
opp-hz = /bits/ 64 <675000000>;
qcom,level = <384>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
};
opp-596000000 {
opp-hz = /bits/ 64 <596000000>;
qcom,level = <320>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 5184000000>;
};
opp-520000000 {
opp-hz = /bits/ 64 <520000000>;
qcom,level = <256>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 4068000000>;
};
opp-414000000 {
opp-hz = /bits/ 64 <414000000>;
qcom,level = <192>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 3072000000>;
};
opp-342000000 {
opp-hz = /bits/ 64 <342000000>;
qcom,level = <128>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 2188000000>;
};
opp-257000000 {
opp-hz = /bits/ 64 <257000000>;
qcom,level = <64>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
};
};
@@ -418,6 +425,9 @@ gpu_opp_table: adreno-opp-table {
operating-points-v2 = <&gpu_opp_table>;
+ interconnects = <&qnoc 26 &qnoc 512>;
+ interconnect-names = "port0";
+
qcom,gmu = <&gmu>;
};
--
2.18.0
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply related [flat|nested] 72+ messages in thread* [PATCH 9/9] arm64: dts: Add interconnect for the GPU on SDM845
@ 2018-08-27 15:11 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-27 15:11 UTC (permalink / raw)
To: linux-arm-kernel
Add the interconnect properties for the GPU on SDM845
and set the corresponding OPP bandwidth values.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 10db0ceb3699..1e67f4fdd7d1 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -198,36 +198,43 @@ gpu_opp_table: adreno-opp-table {
opp-710000000 {
opp-hz = /bits/ 64 <710000000>;
qcom,level = <416>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
};
opp-675000000 {
opp-hz = /bits/ 64 <675000000>;
qcom,level = <384>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
};
opp-596000000 {
opp-hz = /bits/ 64 <596000000>;
qcom,level = <320>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 5184000000>;
};
opp-520000000 {
opp-hz = /bits/ 64 <520000000>;
qcom,level = <256>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 4068000000>;
};
opp-414000000 {
opp-hz = /bits/ 64 <414000000>;
qcom,level = <192>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 3072000000>;
};
opp-342000000 {
opp-hz = /bits/ 64 <342000000>;
qcom,level = <128>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 2188000000>;
};
opp-257000000 {
opp-hz = /bits/ 64 <257000000>;
qcom,level = <64>;
+ opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
};
};
@@ -418,6 +425,9 @@ gpu_opp_table: adreno-opp-table {
operating-points-v2 = <&gpu_opp_table>;
+ interconnects = <&qnoc 26 &qnoc 512>;
+ interconnect-names = "port0";
+
qcom,gmu = <&gmu>;
};
--
2.18.0
^ permalink raw reply related [flat|nested] 72+ messages in thread[parent not found: <20180827151112.25211-10-jcrouse-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 9/9] arm64: dts: Add interconnect for the GPU on SDM845
2018-08-27 15:11 ` Jordan Crouse
@ 2018-08-28 18:16 ` Jordan Crouse
-1 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-28 18:16 UTC (permalink / raw)
To: freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
georgi.djakov-QSEj5FYQhm4dnm+yROfE0A
Cc: nm-l0cyMroinI0, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA, sboyd-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A,
vireshk-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
On Mon, Aug 27, 2018 at 09:11:12AM -0600, Jordan Crouse wrote:
> Add the interconnect properties for the GPU on SDM845
> and set the corresponding OPP bandwidth values.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 10db0ceb3699..1e67f4fdd7d1 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -198,36 +198,43 @@ gpu_opp_table: adreno-opp-table {
> opp-710000000 {
> opp-hz = /bits/ 64 <710000000>;
> qcom,level = <416>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
> };
>
> opp-675000000 {
> opp-hz = /bits/ 64 <675000000>;
> qcom,level = <384>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
> };
>
> opp-596000000 {
> opp-hz = /bits/ 64 <596000000>;
> qcom,level = <320>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 5184000000>;
> };
>
> opp-520000000 {
> opp-hz = /bits/ 64 <520000000>;
> qcom,level = <256>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 4068000000>;
> };
>
> opp-414000000 {
> opp-hz = /bits/ 64 <414000000>;
> qcom,level = <192>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 3072000000>;
> };
>
> opp-342000000 {
> opp-hz = /bits/ 64 <342000000>;
> qcom,level = <128>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 2188000000>;
> };
>
> opp-257000000 {
> opp-hz = /bits/ 64 <257000000>;
> qcom,level = <64>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
> };
> };
>
> @@ -418,6 +425,9 @@ gpu_opp_table: adreno-opp-table {
>
> operating-points-v2 = <&gpu_opp_table>;
>
> + interconnects = <&qnoc 26 &qnoc 512>;
Pointing out for posterity that the src_id here is incorrect. It should be 36.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply [flat|nested] 72+ messages in thread* [Freedreno] [PATCH 9/9] arm64: dts: Add interconnect for the GPU on SDM845
@ 2018-08-28 18:16 ` Jordan Crouse
0 siblings, 0 replies; 72+ messages in thread
From: Jordan Crouse @ 2018-08-28 18:16 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Aug 27, 2018 at 09:11:12AM -0600, Jordan Crouse wrote:
> Add the interconnect properties for the GPU on SDM845
> and set the corresponding OPP bandwidth values.
>
> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 10db0ceb3699..1e67f4fdd7d1 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -198,36 +198,43 @@ gpu_opp_table: adreno-opp-table {
> opp-710000000 {
> opp-hz = /bits/ 64 <710000000>;
> qcom,level = <416>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
> };
>
> opp-675000000 {
> opp-hz = /bits/ 64 <675000000>;
> qcom,level = <384>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 7216000000>;
> };
>
> opp-596000000 {
> opp-hz = /bits/ 64 <596000000>;
> qcom,level = <320>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 5184000000>;
> };
>
> opp-520000000 {
> opp-hz = /bits/ 64 <520000000>;
> qcom,level = <256>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 4068000000>;
> };
>
> opp-414000000 {
> opp-hz = /bits/ 64 <414000000>;
> qcom,level = <192>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 3072000000>;
> };
>
> opp-342000000 {
> opp-hz = /bits/ 64 <342000000>;
> qcom,level = <128>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 2188000000>;
> };
>
> opp-257000000 {
> opp-hz = /bits/ 64 <257000000>;
> qcom,level = <64>;
> + opp-interconnect-bw-port0 = /bits/ 64 <0 1200000000>;
> };
> };
>
> @@ -418,6 +425,9 @@ gpu_opp_table: adreno-opp-table {
>
> operating-points-v2 = <&gpu_opp_table>;
>
> + interconnects = <&qnoc 26 &qnoc 512>;
Pointing out for posterity that the src_id here is incorrect. It should be 36.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 72+ messages in thread