Welcome to Arm Community

yifanfeng said:

I am reading GIC-700 TRM, and seems that it can directly inject SGIs/LPIs into virtual machine without be trapped into Hypervisor.

That's correct, GICv4.1 (which is what GIC-700 implements) only supports direct-injection of SGI/LPIs.

yifanfeng said:

I am wondering if there is some special considerations to not suppport SPI direct injection?

Direct-injection of SPIs, and also PPIs, comes in the recently announced GICv5 spec.

https://developer.arm.com/Architectures/Generic%20Interrupt%20Controller

Hi Andy, 

There are two ways that AFBC gets managed, depending on the type of framebuffer. 

The main application window surface framebuffer, and any other surfaces that are shared by multiple hardware blocks such video imports, are allocated and managed by a system component, for example using Gralloc on Android. The color format and memory layout is determined by this external component rather than the driver because all of the hardware blocks need to agree on the supported format, so there is normally some integration by the SoC provider to make sure that the GPU/Display/Video surfaces are optimally configured.

The internal framebuffers used for render-to-texture within a single application are managed by the driver, as it has full visibility of how that image gets used. AFBC is not compatible with all image usage, so some application usage can cause a fall-back to non-compressed data. More details can be found in our best practices guide:

• https://developer.arm.com/documentation/101897/0304/Buffers-and-textures/AFBC-textures
• https://developer.arm.com/documentation/101897/0304/Buffers-and-textures/AFBC-textures-for-Vulkan

Kind regards, 
Pete

thank you Peter!  As of right now I am just trying to understand how the Mali is indicated that it needs to compress frame buffer output data, but I think I understand that now.

Hi Peter,

Have you considered migrating to the Arm Toolchain for Embedded (ATfE) Open Beta? The linker in that toolchain might be better for meeting your needs. See

https://developer.arm.com/documentation/110032/200000/Release-overview/Migrating-your-existing-ACfE6-project-to-the-ATfE-Open-Beta

Hi Lingfan,

I've just responded in https://community.arm.com/support-forums/f/architectures-and-processors-forum/57205/c2c-snp-address-width-diff-from-chi, as I saw the question there first.

In isolation here though, your calculations look correct to me.

Kind regards,

Ben

Hi Ben,

There may be some misunderstandings in my previous reply.

My current understanding is as follows:

For Req_Addr_Width = 52, SNP Addr width defined as Req_Addr_width – 3 = 49,

So the mapping between CHI <-> C2C would be:

CHI SNP -> C2C Snoop: C2C.Snoop.Addr[47:0] = CHI.SNP.Addr[48:1];

C2C Snoop -> CHI SNP: CHI.SNP.Addr[48:0]   = {C2C.Snoop.Addr[47:0],1’b0];

So For Req_Addr_Width = 51, SNP Addr width defined as 51 – 3 = 48,

So the mapping between CHI <-> C2C would be:

CHI SNP -> C2C Snoop: C2C.Snoop.Addr[47:0] = {1’b0,CHI.SNP.Addr[47:1]};

C2C Snoop -> CHI SNP: CHI.SNP.Addr[47:0]   = {C2C.Snoop.Addr[46:0],1’b0];

Then For Req_Addr_Width = 50, SNP Addr width defined as 50 – 3 = 47,

So the mapping between CHI <-> C2C would be:

CHI SNP -> C2C Snoop: C2C.Snoop.Addr[46:0] = {2’b0,CHI.SNP.Addr[46:1]};

C2C Snoop -> CHI SNP: CHI.SNP.Addr[46:0]   = {C2C.Snoop.Addr[45:0],1’b0];

Please help me to confirm whether these mapping relationships are correct or not.

I‘m looking forward to your reply.

Best Regards

Hi Lingfan,

Yes, your calculations look correct to me.

Kind regards,

Ben