Hi Thomas,

Le lun. 15 mars 2021 à 8:43, Thomas Zimmermann tzimmermann@suse.de a écrit :

Hi

Am 11.03.21 um 13:33 schrieb Paul Cercueil:

...

Le jeu. 11 mars 2021 à 12:28, Christoph Hellwig hch@infradead.org 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