Re: [PATCH v2 4/5] drm: Add and export function drm_gem_cma_sync_data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Thomas,

Le lun. 15 mars 2021 à 8:43, Thomas Zimmermann <tzimmermann@xxxxxxx> a écrit :
Hi

Am 11.03.21 um 13:33 schrieb Paul Cercueil:


Le jeu. 11 mars 2021 à 12:28, Christoph Hellwig <hch@xxxxxxxxxxxxx> a écrit :
On Sun, Mar 07, 2021 at 08:28:34PM +0000, Paul Cercueil wrote:
 +    drm_atomic_for_each_plane_damage(&iter, &clip) {
 +        for (i = 0; i < finfo->num_planes; i++) {
 +            daddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
 +
 +            /* Ignore x1/x2 values, invalidate complete lines */
 +            offset = clip.y1 * state->fb->pitches[i];
 +
 +            dma_sync_single_for_device(dev, daddr + offset,
+ (clip.y2 - clip.y1) * state->fb->pitches[i],
 +                       DMA_TO_DEVICE);

Are these helpers only ever used to transfer data to the device and
never from it?  If so please clearly document that.

Yes. In the DRM world, are there cases where we transfer data from the device? I assume these cases are handled by v4l2 instead.

Software rendering (i.e., anything wrt dumb buffers) likely reads back framebuffer content during blit operations. For devices where this is a slow operation (e.g., PCI read) we set struct drm_mode_config.prefer_shadow to hint renderers to use shadow buffering.

This has been brought up a few times already. I answered that in the cover letter. In my case, *writes* (e.g. dumb memcpy) are also slower with a write-combine buffer than with a non-coherent buffer + cache sync. So a shadow buffer does nothing for me.

Cheers,
-Paul





[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux