AM5748: GPU affecting DSP

Hello Ro,

Not sure that there i8s any examples for this but take a look at the following chapter in the TRM.

15.2.3.3 Bandwidth Regulators

FYI, I am going on a business trip next week so responses will be somewhat delayed until Thursday the 13th.

-Josue

Hello Josue,

I've tried the following but didn't seem to avoid the problem. Please let me know if I've done something wrong:




I've tried also "touching" SDRAM & L3_Main Initiator priority registers, PEG priorities, DSP NoC Arbitration and DMM Emergency, none worked . 

I will write what I did on following posts

I couldn't get to understand how to use class of service priorizing just the DSP or the DSPs + IPUs. Haven't been able to see masterID+mask combination or priority just for them.

Thanks for the support

Best regards

Hello Ro,

Like I said prior, I haven't seen an example of this before so I am not sure either. Hopefully the GPU dev team can be of help.

-Josue

Hello Josue,

Let me share you other "options" I've tried in order to give a more complete information to the GPU dev team. So, apart from the BW Regulators and Limiters from my previous post, I tried:

Initiator Prioriry Registers

DMM PEG Priorities

DSP NoC Arbitration

DISPC MFLAG

MFLAG Override

With all this changes, it seems that the GPU affects the DSP less than with default values, but it still happens sometimes.

So, I would be very grateful if the GPU dev team or anyone could share any hint or help to avoid this. Or if someone sees an error on the values of the registers, or maybe if we have to do it in a proper order, in a proper stage of the booting or whatever...

Hello Ro,

The Dev team is essentially pointing at using the same tools you are using as QoS "knobs".

You can use the following App note for additional guidance: https://www.ti.com/lit/an/sprabx1a/sprabx1a.pdf

These are very similar devices so the same "knobs" apply.

Is it safe to assume that you are using Linux since you are using devmem2 to write to registers?

One idea is to analyze what the defaults for these "knobs" are in AM5718 and compare them to AM5748. Otherwise they believe it might be necessary to tweak them some to fit your usecase. 

Let me know if this helps. I will also review your changes later this week.

-Josue

Hello Josue, 

Actually, I followed sprabx1a along with the TRM to use all the knobs mentioned in my previous posts, and you are right, we are running linux on A15 core(s). Specifically Yocto Dunfell, kernel 5.10.100-rt62, SDK 08.02.01.00.

Following your suggestion, I've checked the register values at reset (taken from TRM), after linux boot and after applying the knobs.

TRM reset values are the same for both AM5718 and AM5748. Columns D and E in the picture below.

Register values after linux boot are also the same for both AM5718 and AM5748 (Columns F and G. And the only register with a different value from reset values is  DISPC_GLOBAL_MFLAG_ATTRIBUTE which has the MFLAG_CTRL activated (by the GPU driver I guess).

You can see it in blue color in the following picture, along with the registers that are changed (red, column I) after applying knobs (column H).

I'm open to change any other registers or values of the mentioned registers. We would appreciate light and orientation from the Dev team in case we are doing something wrong or lacks something else.

Thank you for the support

Best Regards

Ro

Ro,

I will need a few days to review.

-Josue

Hello Josue,

Sorry, I pushed "This resolved my isse" by mistake. 

I appreciate the feedback but I can't imagine what else to experiment. I don't know if the dev team had the chance to look into all the registers we've tried modifying following the Knobs and the TRM from my previous posts... we've been experimenting with bandwith regulators for DSP, DMAs and GPU; bandwith limiter for GPU; SDRAM Initiator Priority; L3_MAIN Initiator Priority; PEG Priorities; DSP NoC Arbitrarion; DISPC MFlag Mechanism and Arbitration; MFlag Override and DMM Emergency.

The only thing left is Class of Service, which only works if Mflag Override is set (then, the other things I've tried are all I have seen), because I see no way to give priority to DSP and maybe collaterally to IPUs without giving priority also to MPU or other no real time peripherals.

Maybe I have misunderstood something and I'm not writing the proper value or in the right order, but how to know without the orientation of an expert? All the registers I've "touched" have been oriented to give highest priority to DSP and its DMAs or to remove priority from GPU or at least keep it at default medium value.

And there's still the question of the other thread, why does it happen with AM5748 but not with AM5718? What difference could be?

Regarding the Framerate, we are not capping it as far as I know, I mean we didn't know about the framerate (and I don't find it in the TRM). Any hint where we can take a look?

Thank you for the support
Ro

Ro, You can edit under the More dropdown to remove the Green 'solved' highlight from the response.

Ro said:

but how to know without the orientation of an expert?

The unfortunate part is that the majority of J6 developers are no longer in TI or have moved on to different roles. This means that you only have me. (Not an expert and often-times spread thin in terms of BW). It will take me some time to go through your changes and my BW at the moment is very low.

Ro said:

And there's still the question of the other thread, why does it happen with AM5748 but not with AM5718? What difference could be?

I believe the differences have been addressed, the root cause I cannot confirm, I will reach out to our HW team for comment.

Ro said:

Regarding the Framerate, we are not capping it as far as I know, I mean we didn't know about the framerate (and I don't find it in the TRM). Any hint where we can take a look?

Dev team mentioned this as something that would be done at the application level. One way to do it would be using KMS (Kernel Mode Setting), and force a lower resolution. Seems like you can pass arguments via the bootargs to the kernel (Not tested on our side)

Example: https://wiki.archlinux.org/title/Kernel_mode_setting

Let me know if you try this.

-Josue