Hello Andrew,
On 22/05/24 21:14, Andrew Davis wrote:
On 5/22/24 6:37 AM, Jayesh Choudhary wrote:
Enable Quality of Service (QoS) blocks for Display SubSystem (DSS), by servicing the DSS - DDR traffic from the Real-Time (RT) queue. This is done by setting the DSS DMA orderID to greater than 7. ATYPE 3 is selected so that the traffic takes non-coherent path and does
So this is the part I'm not sure about, this change is not just a performance adjustment, it can and does break things. The ORDERID setting is fine with me, but changing ATYPE should be done in a separate patch so it can be debated on its own.
not have a conflict with coherent traffic from C7x (deep-learning applications). Before setting up the QoS, the ORDERID needs to be mapped to VBUSM sources using setup_navss_nb() function call that sets the threadmap for NBSS registers. (Section 10.2.10.1.2 "NB Parameters" in TRM[0])
Section 3.3.2 "Quality of Service (QoS)" in the TRM[0] provide more details.
Signed-off-by: Jayesh Choudhary j-choudhary@ti.com
arch/arm/mach-k3/j721e/j721e_init.c | 28 +++++ arch/arm/mach-k3/r5/j721e/Makefile | 1 + arch/arm/mach-k3/r5/j721e/j721e_qos.h | 96 +++++++++++++++ arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c | 125 ++++++++++++++++++++ 4 files changed, 250 insertions(+) create mode 100644 arch/arm/mach-k3/r5/j721e/j721e_qos.h create mode 100644 arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c
diff --git a/arch/arm/mach-k3/j721e/j721e_init.c b/arch/arm/mach-k3/j721e/j721e_init.c index c2024f2500..e9ed8cb267 100644 --- a/arch/arm/mach-k3/j721e/j721e_init.c +++ b/arch/arm/mach-k3/j721e/j721e_init.c
[...]
diff --git a/arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c b/arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c new file mode 100644 index 0000000000..c829057200 --- /dev/null +++ b/arch/arm/mach-k3/r5/j721e/j721e_qos_uboot.c @@ -0,0 +1,125 @@ +// SPDX-License-Identifier: GPL-2.0+ +/*
- j721e Quality of Service (QoS) Configuration Data
- Auto generated from K3 Resource Partitioning tool
- */
+#include <asm/arch/k3-qos.h> +#include "j721e_qos.h"
+struct k3_qos_data qos_data[] = { + /* DSS_PIPE_VID1 - 2 endpoints, 2 channels */ + { + .reg = K3_DSS_MAIN_0_DSS_INST0_VBUSM_DMA + 0x100 + 0x4 * 0,
0x100 being the instance, and 0x4 * x being the specific device register right? That could be encoded in a macro (the "Resource Partitioning tool" would be updated to generate that too).
Andrew
Okay both val and reg could be updated.
+ .val = ATYPE_3 | ORDERID_15, + }, + { + .reg = K3_DSS_MAIN_0_DSS_INST0_VBUSM_DMA + 0x100 + 0x4 * 1, + .val = ATYPE_3 | ORDERID_15, + },
[...]
+ /* Following registers set 1:1 mapping for orderID MAP1/MAP2 + * remap registers. orderID x is remapped to orderID x again + * This is to ensure orderID from MAP register is unchanged + */
+ /* K3_DSS_MAIN_0_DSS_INST0_VBUSM_DMA - 2 groups */ + { + .reg = K3_DSS_MAIN_0_DSS_INST0_VBUSM_DMA + 0, + .val = 0x76543210, + }, + { + .reg = K3_DSS_MAIN_0_DSS_INST0_VBUSM_DMA + 4, + .val = 0xfedcba98, + },
From the looks of it, these register and val can also be encoded as K3_QOS_GROUP_REG and K3_QOS_GROUP_VAL_HIGH (0xfedcba98) and K3_QOS_GROUP_VAL_LOW (0x76543210)????
[...]
+u32 qos_count = ARRAY_SIZE(qos_data);