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
