[PATCH 4/4] drm/mgag200: Use DMA to copy the framebuffer to the VRAM

[Jocelyn Falempe]

On 09/05/2023 11:49, Jocelyn Falempe wrote:
> On 08/05/2023 10:04, Thomas Zimmermann wrote:
>> Hi Jocelyn
>>
>> Am 05.05.23 um 14:43 schrieb Jocelyn Falempe:

[cut]
>>> +    /* pad each line to 32bits boundaries see section 4.5.7 of G200 
>>> Specification */
>>> +    int width_padded = round_up(width * cpp, 4);
>>> +
>>> +    for (i = 0; i < height; i++)
>>> +        memcpy(mdev->dma_buf + width_padded * i,
>>> +               src + (((clip->y1 + i) * pitch) + clip->x1 * cpp),
>>> +               width * cpp);
>>
>> This memcpy() should probably go away.  Instead of SHMEM, mgag200 
>> should allocate with GEM DMA helpers. We have a number of drivers that 
>> use DMA helpers with DRM format helpers, so the conversion should be 
>> strait-forward and can be done independently from the other patches.
> 
> This is something I tried to do.
> It will also make the driver a bit more complex, because when the damage 
> rectangle is not the full screen, I will need to do one ILOAD per line, 
> instead of one for the whole rectangle, but that's still manageable.
> Do you know which driver I can take as an example ?

I've tested using the GEM DMA helper, but on my test machine, I have the 
same issue that it fails to allocate the framebuffer when it is more 
than 4MB.
So it works in 1024x768 (3MB) but fails for 1280x1024 (5MB).

Adding cma=128M to the kernel command line makes it work (in 1280x1024) 
sometime but not reliably. (it fails to allocate in loop for 30min, and 
then suddenly the allocation succeed, and graphics start working). Also 
enabling iommu seems to have no effect.

I'm probably missing something, as other drivers are using this 
successfully ?

I just used DEFINE_DRM_GEM_DMA_FOPS instead of DEFINE_DRM_GEM_FOPS and
DRM_GEM_DMA_DRIVER_OPS instead of DRM_GEM_SHMEM_DRIVER_OPS in mgag200_drv.c

Then I call drm_fb_dma_get_gem_obj() to get the physical address for the 
Matrox's DMA.

Best regards,

-- 

Jocelyn