Linux/AM5728: Sending VIP DMABUF as source surface to GC320

phil class

Part Number: AM5728

Tool/software: Linux

I am attempting to use the Vivante GC320 2D Accelerator in the AM5728 to process a captured frame from the VIP port. I need to do this with zero copies for performance.

There are several posts on the TI E2E forums about sharing DMABUFs with the GC320. Most of them provide the galRunTest2_drm.c file as an example of allocating a DMABUF with omap_bo_new for a Target Surface for the GC320 to render into. I need the opposite example showing how to directly provide a DMABUF from the VIP port to the GC320.

I have written a small test app to do some processing on a VIP port frame. I am able to do some processing on a Source Surface I create myself and successfully render into a DRM DMABUF as the output or "Target Surface". However, I am unable to provide a DMABUF as an input surface to the 2D GPU from the VIP Port directly. If I mmap the VIP port DMABUF and pass it to the 2D Surface Creation routine directly, the Linux Kernel panics and the 2D Accelerator attempts to “recover” itself indefinitely. I have pasted some of the kernel traceback below. It complains about "stuck" DMA.

So my workaround right now is to copy it. I create a DMABUF based Surface ( in the same way as I created the output DMABUF which works ), and mmap it. Then I memcpy the VIP port’s mmap’d buffer into the surface buffer. This seems to work but has the cost of the extra 6 ms to memcpy from one DMABUF to the other before rendering in the 2D GPU using it as an input surface.

I have attached my small test application to this posting in hopes that someone can tell me what I am doing wrong. This application captures a frame from the VIP port, attempts to submit it to the GC320, and saves the file to disk. The resulting file can be viewed on Ubuntu with the following command:

convert -depth 8 -size 640x480+0 RGBA:gc320.rgb a.png ; eog a.png

vip_to_gc320.zip

How can I pass a DMABUF directly to the GC320 Source Surface? Thank you.

DMA Causes Kernel Panic:

 [ 2572.062341] omap_l3_noc 44000000.ocp: L3 application error: target 5 mod:1 (unclearable)

[ 2572.070549] omap_l3_noc 44000000.ocp: L3 debug error: target 5 mod:1 (unclearable)

[ 2576.126358] [galcore]: GPU[0] hang, automatic recovery.

[ 2580.229141] GPU[0](ChipModel=0x320 ChipRevision=0x5301):

[ 2580.235542] **************************

[ 2580.239805] ***   GPU STATE DUMP   ***

[ 2580.243578] **************************

[ 2580.247712]   axi     = 0x00000071

[ 2580.251225]   idle     = 0x7FFFFFFE

[ 2580.254731]     FE not idle

[ 2580.257648]   DMA appears to be stuck at this address:

[ 2580.262816]     0x7E724000

[ 2580.265539]   dmaLow   = 0x48000000

[ 2580.269089]   dmaHigh = 0x00000701

[ 2580.272599]   dmaState = 0x00000000

[ 2580.276107]     command state       = 0 (PAR_IDLE_ST)

[ 2580.281583]     command DMA state   = 0 (CMD_IDLE_ST)

[ 2580.286739]     command fetch state = 0 (FET_IDLE_ST)

[ 2580.291820]     DMA request state   = 0 (REQ_IDLE_ST)

[ 2580.296977]     cal state           = 0 (CAL_IDLE_ST)

[ 2580.302064]     VE request state   = 0 (VER_IDLE_ST)

over 7 years ago

0 Biser Gatchev-XID over 7 years ago

TI__Guru**** 393215 points

The software team have been notified. They will respond here.

0 Manisha Agrawal over 7 years ago in reply to Biser Gatchev-XID

TI__Mastermind 22946 points

Hi Phil,

I am checking on this with GC320 driver expert. Will get back when I have some answer for you.

Regards,
Manisha

0 phil class over 7 years ago in reply to Manisha Agrawal

Intellectual 640 points

Hi Manisha,

Has there been any update on this? Thank you.

Phil

0 Manisha Agrawal over 7 years ago in reply to phil class

TI__Mastermind 22946 points

Hi Phil,

Sorry for the delayed response. Initial response from GC320 driver expert was that there shouldn't be any issue inside the driver. GC320 driver supports the dmabuf import feature that has been validated to be working with output buffer and the dmabuf import feature doesn't differentiate between input and output buffer, so likely the problem is at the application layer. He is suppose to look into the application that you shared. Due to Thanks Giving Holidays in US, he is on vacation. I shall ping him again when he is back in office this week.

0 phil class over 7 years ago in reply to Manisha Agrawal

Intellectual 640 points

Hi Manisha,

Thanks for the update. I look forward to hearing from the driver expert.

Thanks,

Phil

0 Gowtham Tammana over 7 years ago in reply to phil class

TI__Expert 3430 points

Hi Phil,

The mapping code in the reference test example looks ok. With that a couple of
questions and comments.

- What TI baseline are you running this against.
- In regard to alignment, can you check if the alignment requirements are
satisfied at the source allocation time in VIP port. May be its ensured
already, just a caution.
- If alignment is aligned, could you try `memset`ting the buffers to zero at
allocation time.

Thanks,
Gowtham

0 phil class over 7 years ago in reply to Gowtham Tammana

Intellectual 640 points

Hi Gowtham,

Thank you for the response. Below is the version information:

Linux Kernel Version:

uname -r
4.4.41

GAL Version:

[318156.996308] GC320 IRQ: 304
[318156.999191] Galcore version 5.0.11.33433

Chip Revision Information:

=================== Chip Information ==================
Chip : GC320
Chip revision: 0x00005301
Patch revision: 0x00000000
Chip Features: 0xe02c7eca
Chip MinorFeatures0: 0xc9399eff
Chip MinorFeatures1: 0xfe1fb2db
Chip MinorFeatures2: 0xdeff0080
Chip MinorFeatures3: 0x00000005
Chip MinorFeatures4: 0x00000000
Chip MinorFeatures5: 0x00000000
=======================================================

The Kernel errors boil down to:

[  212.952678] [galcore]: Hardware not reset successfully, give up
[  218.946585] [galcore]: GPU[0] hang, automatic recovery.

The VIP DRM Buffers are allocated and aligned per TI's dualcamera example:

    struct omap_bo *bo;

    bo_flags |= OMAP_BO_WC;

    bo = omap_bo_new(omapDevice, width * height * bpp / 8, bo_flags);

    if (bo) {
        *bo_handle = omap_bo_handle(bo);
        *pitch = width * bpp / 8;
        if (bo_flags & OMAP_BO_TILED)
            *pitch = ALIGN2(*pitch, PAGE_SHIFT);
    }

Which buffers are you referring to memsetting to zero? The createGC320Surface() function was taken from the galRunTest2 example which memsets the surface buffer to zero at the end of the function. The alignment code in that function is also the same as the example.

Do you have an example of providing serperate DMABUFs as both an input and output surfaces to the GC320?

Thank you for the help,

Phil

0 Gowtham Tammana over 7 years ago in reply to phil class

TI__Expert 3430 points

Hi Phil,

> Which buffers are you referring to memsetting to zero? The
> createGC320Surface() function was taken from the galRunTest2 example which
> memsets the surface buffer to zero at the end of the function. The alignment
> code in that function is also the same as the example.

In the code that was shared where the VIP DRM buffers are being allocated, make
sure that the alignment requirements are considered and as well *memset* them to
zero before passing it to gcoSURF. Something along the lines.

```
struct omap_bo *bo;

bo_flags |= OMAP_BO_WC;

# adjust size to match the alignment requirements
# size = ((width + 15) & ~15) * height * bpp / 8;
bo = omap_bo_new(omapDevice, size, bo_flags);

if (bo) {
*bo_handle = omap_bo_handle(bo);
*pitch = width * bpp / 8;
if (bo_flags & OMAP_BO_TILED)
*pitch = ALIGN2(*pitch, PAGE_SHIFT);
}

void *vaddr = omap_bo_map(bo);
memset(vaddr, 0, size);
```

Thanks,

Gowtham

0 phil class over 7 years ago in reply to Gowtham Tammana

Intellectual 640 points

Hi Gowtham,

Memsetting the VIP buffers to 0 worked! Thank you for the support on this.

Thanks,

Phil

0 Gowtham Tammana over 7 years ago in reply to phil class

TI__Expert 3430 points

Hi Phil,

Glad to hear that the issue is resolved.

Thanks,

Gowtham

Processors

Processors forum

Linux/AM5728: Sending VIP DMABUF as source surface to GC320