DM8148: DDR access priority

Andrea,

I'm not really sure about A8 vs HDVPSS priority. Have you checked the details of ELLA (Extreme Low Latency Access) port for A8?

What is your exact problem? Are you facing any performance issues w.r.t A8?

Hi Thomas,

ELLA port cannot be configured in software, IIUC from TRM.

I'm experiencing a flickering problem on video output, when Cortex A8 draws some graphics on fb.

IIUC this is a problem due bandwidth consumption on DDR. However, I think that rising HDVPSS priority over A8 on DDR access should solve the problem.

I've try to configure the register I mention on my first post but without notable changes on output. So maybe I'm missing something regarding priority configuration.

IOW: I need to be sure that HDVPSS (or video subsystem in general) has a higher priority vs all the other masters when accessing DDR. IIUC this is not the default configuration.

Best Regards,

Andrea

Andrea,

Yes, ELLA cannot be configured. Are you using SGX for graphics? What is the size of your graphics window? Are you using Graphics plane in HDVPSS for overlay?

Also have you checked your ARM and DDR clock?

Dear Thomas,

here are the answer to your questions:

* SGX is unused (driver unloaded)

* graphics (fb0) goes to HDMI, configured in 1080p60

* graphis is overlayed with video (taken from VIN1A, also 1080p60). Most of the time the graphic app (QT based) cover the whole screen, in some situation only some buttons are visible over the video

* we are running at OPP166: ARM Cortex A8 @1GHz and DDR @400MHz (or @533MHz, we have some benefit from the last configuration but the problem is not solved).

However yesterday I wrote another testbench:

* Application running as before but not drawing graphics actively. Overlay Active.

* VIN disabled. As video I have a sample gstreamer pipeline with two H264 (1080p, 25fps, the sample video provided with EZSDK) played Picture in Picture with videomixer

In this situation everything goes fine until I run another application, which just do something like:

area = malloc(1024*1024)

while (1)

   memset(area, rand(), 1024*1024)

As soon as I run this simple memset() loop I see a huge flickering on HDMI output.

Dear Andrea,

I've been seeing this kind of performance issue with A8. Even I've seen the A8 CPU utilization on DM8148 is generally high. But to solve your problem for time being, what I believe is that, you've to use SGX for your graphics. That should solve the problem for time being. This performance issue with A8 needs to be investigated more deeply. 

Hi Andrea,

For prioritizing some initiator over the Cortex-A8 ARM, check DM814x TRM section 1.12.2.3.3 Bandwidth Regulators:

Bandwidth regulators are mainly used to give priority to the following masters: HDVICP, TPTC_RD2/4, TPTC_WR2/4, MMU, ISS and SGX.

The registers that you can try to modify are: L3_BW_REGULATOR_BANDWIDTH and L3_BW_REGULATOR_WATERMARK.

Also you can configure the “pressure input to interconnect” in INIT_PRIORITY_0 Register:

[9:8] DSS0 (Display Subsystem Port 0 initiator priority) = 0x3

[11:10] DSS1 (Display Subsystem Port 1 initiator priority) = 0x3

INIT_PRIORITY_1[15:14] DSS_CTLR (DSS Controller (Media Controller) initiator priority) = 0x3

This should help prioritize HDVPSS traffic within the interconnect.

Best Regards,

Pavel

Renjith,

Thanks for your suggestion. In fact I also try some SGX demos and those does not show the flickering issue. However for our application I need to use QT. I've seen that QT supports SGX acceleration, but only for 3D graphics, not for 2D. And what I have in our app is only 2D graphics (buttons, text and so on)

Andrea,

I'm not an expert in application. Might sound stupid, but can you enable SGX anyways and try your application? Just to see whether it makes any difference or not.

Dear Pavel,

'til now I've been looking only at DMM/DDR registers because I've seen that changing DDR frequency changes a lot the issue.

The best thing I've found until now is to lower DMM_PEG_PRIO0/1 of all initiator (the TRM says that DMM bypasses this value for HDVPSS, which seems true. However I did not found "where" the PEG priority for HDVPSS is configure..)

Lowering all initiator give a good result, but it's not perfect. Sometimes I still see the flickering (not sure yet which is the root cause of this)

Changing INIT_PRIORITY does not give any good result. I've configured INIT_PRIORITY_0=0xF00 INIT_PRIORITY_1=0xC000 but (with DMM_PEG_PRIOx configured as default) I see no changes at all. Maybe I've misunderstand the register meaning..

Abount L3_BW_REGULATOR_X

1) which is the A8 regulator? MMU?

2) which is HDVPSS regulator? ISS?

3) I cannot understand well the meaning of those register too. For example I'm running a dual H264 decode Picture in Picture (not flickering if I dont touch the user interface and left the default BW configuration). I've changed HDIVCP configuration like:

a) changing HDVICP L3_BW_R_BANDWIDTH to low values (let's say 1 to 0x15): no flickering

b) changing HDVICP L3_BW_R_BANDWIDTH to high values (let's say 0x100 to max allowed): lot of flickering.

c) changing HDVICP L3_BW_REGULATOR_WATERMARK: = 0: this gives lot of flickering. To me is correct because I lower the bw.

In all configuration (a, b, c) I've seen no changes in L3_BW_R_PRESS.

I'll continue with my tests.

Thanks in advance for any clarification,

Andrea

Hi Andrea,

For HDVPSS traffic priority you can try:

1. Set bits INIT_PRIORITY_0[8] and INIT_PRIORITY_0[10]  to 0x1

2. Clear bit field DMM_PEG_PRIO1[6:4] P1 to 0x0

Regards,

Pavel

Dear Pavel,

first of all thanks for your answer.

To reproduce the flickering I just have to:

- run a double decode display, Picture In Picture with videomixer, with gstreamer

 gst-launch omx_videomixer port-index=0 framerate=25
 name=mix sink_00::outX=0 sink_00::outY=0 sink_00::outWidth=1920 sink_00::outHei
ght=816  sink_01::outX=128 sink_01::outY=128 sink_01::outWidth=848 sink_01::outH
eight=360 ! omx_ctrl display-mode=OMX_DC_MODE_1080P_60 ! gstperf !  omx_videosin
k sync=false filesrc location=/usr/share/ti/data/videos/dm816x_1080p_demo.264 !
'video/x-h264' ! h264parse access-unit=true ! omx_h264dec !  mix. filesrc locati
on=/usr/share/ti/data/videos/dm816x_1080p_demo.264 ! 'video/x-h264' ! h264parse
access-unit=true ! omx_h264dec ! mix.

- run a simple C program that:

buffer = malloc(1024*1024);

while (1) {

   memset(buffer, rand(), 1024*1024);

}

This will lead to lot of flickering if I dont set DMM_PEG_PRIO0[4:0] to 7 (*(unsigned long*)0x4E000620=0xf.

just changing INIT_PRIORITY_0[8] and INIT_PRIORITY_0[10] to 1 and configuring DMM_PEG_PRIO1[6:4] to 0, does not lead to any notable effect

Am I missing something?

However, by using a more complex QT application, just lowering DMM_PEG_PRIO0[4:0] priority (from 4 to 7) is not enoght. It seems that, sometimes, HDVPSS loose internal bus or DDR access an the output flickers.

Is there a way to "be sure" that HDVPSS give all it's bandwidth (e.g. by limiting all the bandwidth of the other systems) so I'll avoid the flickering in any situation?

Hi Andrea,

Each initiator (Cortex-A8, HDVPSS, HDVICP2, SGX, etc) have programmable

1. Priority/pressure control for Interconnect

2. Priority control for DDR

Interconnect supports 3 level of pressure:

0x0: low pressure

0x1: medium presure

0x3: high pressure

Note: 0x2 pressure value is illegal

Pressure for Interconnect is controlled in 2 ways:

1. Static pressure value specified in INIT_PRIORITY_0/1 register (address  0x4814_0608/ 0x4814_060C) - for EMAC, USB, PCIe, HDVICP, SGX, Cortex-A8 ARM, DSP, HDVPSS, etc.

2. Dynamic pressure value determined by Bandwidth Regulators - for HDVICP, EDMA, MMU, ISS and SGX.

For static interconnect pressure settings, valid values for each initiator (except HDVPSS) are 0x0 (low), 0x1 (medium) and 0x3 (high). HDVPSS has 2 ports on interconnect and 1 bit per port in INIT_PRIORITY_0, valid values are 0x0 and 0x1.

Bandwidth regulator increases pressure when the actual consumed bandwidth is lower than expected bandwidth and decreases the pressure once the expected bandwidth is reached.

Example for HDVICP Bandwidth Regulator programming:

Intent - HDVICP should have 1GB/s bandwidth & should not take excessive bandwidth

Method:

- High Pressure for HDVICP accesses by default ( to ensure bandwidth)

- Low Pressure if Bandwidth requirement goes above a limit

- Compute watermark over approximately 1 MacroBlock interval ~1000 cycles of 500 MHz

Calculation

- Bandwidth register => 1000MB/s /15.625 =  64 ( 0x40 )

- Watermark register => 1000 MB/s * 1000 cycles * 2 ns =  2000 (0X7D0)

- Pressure Register => { PresLow = 0x0 ,PressHigh = 0x3 }

- Clear History by writing 0x1 to Clear history register after writing above 3 registers.

Priority Control in DDR: priority configuration in DMM PEG registers. Priority is 3 bit field (0...7), 0 is highest priority. Priority determines prioritization of data transfers in DDR. The 3-bit priority coded on the 3 least significant bits (0 is the higher priority). A “W” field-specific active-high local write enable bit, always read as 0. The role of the W bit is to allow the modification of a single entry without requiring a read-modify-write sequence.

Regards,

Pavel

Hello Andrea Scian:

  As you refered,you are running at OPP166: ARM Cortex A8 @1GHz and DDR @400MHz (or @533MHz),How to get it?

Now my system (Dm8148 too)works at OPP122:ARM Cortex A8 @600MZ and DDR@400M.

How to get Opp166,in uboot or Kernel?Thanks very much.

Dear zhichao,

I wrote a custom driver into the kernel to allow full power management of DM8148 chip.

This includes OPP changes and standby (plus clock management).

You can change OPP in u-boot too, if you change not only the working frequencies (clocks_ti814x.h) but also the voltage value of the PMIC via I2C

Regards,

Andrea

Hi Andrea Scian:

   Thanks for your reply.And I have another doubt:

   Wheather  must  I  adjust the OPP value(Change the voltage)  first  if I want to change the frequencies of ARM and DDR?

   If I use OPP166,How can configure the PMIC value?I can't find the PMIC register till now,Thanks,Very appriciate for you help. 

   Regards

   zhichao.

Looking at sprugz8e.pdf, section 3.2.18 INIT_PRIORITY_0, can one read "between the lines" and assume priority 0x3 is highest and 0x0 is lowest?

Datasheet sprs647e.pdf, Table2-7.L4 Slow Peripheral Memory Map

shows

0x4814_0000 0x4815_FFFF 0x0814_0000 0x0815_FFFF 128KB

Control Module Peripheral Registers (C674x DSP Restricted to only exposed peripherals)

is INIT_PRIORITY_0 considered an "exposed" peripheral?

And is INIT_PRIORITY_0 in the "Control Module Support Registers" group, or "Control Module Peripheral Registers Group"? Section 3.2 of sprugz8e.pdf (TRM) does not divide the registers in to groups!

Thanks,

Andrew

Andrew,

Andrew Elder said:

Looking at sprugz8e.pdf, section 3.2.18 INIT_PRIORITY_0, can one read "between the lines" and assume priority 0x3 is highest and 0x0 is lowest?

This is correct.

0x0: lowest
0x1: middle
0x2: illegal value
0x3: highest

Regards,
Pavel

Pavel Botev said:

Andrew,

Looking at sprugz8e.pdf, section 3.2.18 INIT_PRIORITY_0, can one read "between the lines" and assume priority 0x3 is highest and 0x0 is lowest?

This is correct.

0x0: lowest
0x1: middle
0x2: illegal value
0x3: highest

Regards,
Pavel

[/quote]

Thanks Pavel!

BTW other question is related to trying to change EDMA TC priority from the DSP side. Don't know if this is possible.

Regards,

Andrew

INIT_PRIORITY_0 is in the "Control Module Peripheral Registers" group, base address 0x48140000, full address 0x48140608

Regards,
Pavel

Pavel Botev said:

INIT_PRIORITY_0 is in the "Control Module Peripheral Registers" group, base address 0x48140000, full address 0x48140608

Regards,
Pavel

And is it writeable by C674x?

Regards,

Andrew

We have one pdf at the link below, please have a look, it might be in help:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/323639/1130127.aspx#1130127

Regards,
Pavel

Andrew,

Andrew Elder said:

INIT_PRIORITY_0 is in the "Control Module Peripheral Registers" group, base address 0x48140000, full address 0x48140608

Regards,
Pavel