AnsweredAssumed Answered

i.MX8MQ NOC/AQoS changes for LCDIF

Question asked by Gary Bisson on Jul 31, 2018
Latest reply on Aug 8, 2018 by Gary Bisson

Hi,

 

After seeing some issues on i.MX8MQ when using the LCDIF output, it seems that the Kernel does some specific configurations when this latter is enabled:

soc-imx8.c\imx\soc\drivers - linux-imx - i.MX Linux kernel 

=> When LCDIF is enabled, it "Config NOC for VPU and CPU"

 

Looking into imx-atf, here is what is actually done:

src.c\imx8mq\freescale\plat - imx-atf - i.MX ARM Truststed firmware 

          /* config NOC for VPU */
          mmio_write_32(IMX_NOC_BASE + 0x108, 0x34);
          mmio_write_32(IMX_NOC_BASE + 0x10c, 0x1);
          mmio_write_32(IMX_NOC_BASE + 0x110, 0x500);
          mmio_write_32(IMX_NOC_BASE + 0x114, 0x30);
          /* config NOC for CPU */
          mmio_write_32(IMX_NOC_BASE + 0x188, 0x34);
          mmio_write_32(IMX_NOC_BASE + 0x18c, 0x1);
          mmio_write_32(IMX_NOC_BASE + 0x190, 0x500);
          mmio_write_32(IMX_NOC_BASE + 0x194, 0x30);

 

So here are my questions:

1. Why is this configuration necessary when LCDIF is enabled?

2. What is this configuration doing? It seems that it is limiting the CPU/VPU DDR bandwidth.

3. Can you provide an updated documentation? The one present in the "i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual, Rev. 0" (section 4.6.2.2.2 Advanced QoS (AQoS) Control Register) seems to be a copy/paste of the i.MX6QP, am I correct? All the offsets / slave IDs seem wrong (it even contains IPU0/1, G2D which aren't present in i.MX8MQ).

=> my guess is that the offsets are 0x100 + slave_id × 0x80 (instead of 0xB_0100 + slave_id × 0x80)

=> my other guess is that VPU is slave id 2 and CPU is slave id 3 (if the comments in the code are true)

 

Regards,

Gary

Outcomes