Displaying 16 results from an estimated 16 matches for "drm_leak_fbdev_smem".
2019 Jul 05
0
[PATCH v2 2/6] drm/fb-helper: Map DRM client buffer only when required
...->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = fb->height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
- fbi->screen_buffer = buffer->vaddr;
- /* Shamelessly leak the physical address to user-space */
-#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
- if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0)
- fbi->fix.smem_start =
- page_to_phys(virt_to_page(fbi->screen_buffer));
-#endif
+
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
if (fb->funcs->dirty) {
@@ -2231,6 +2235,19 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper *fb_he...
2020 Oct 28
0
[PATCH v6 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
...fbi->screen_buffer = vaddr;
- /* Shamelessly leak the physical address to user-space */
+ /*
+ * Shamelessly leak the physical address to user-space. As
+ * page_to_phys() is undefined for I/O memory, warn in this
+ * case.
+ */
#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
- if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0)
+ if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0 &&
+ !drm_WARN_ON_ONCE(dev, map.is_iomem))
fbi->fix.smem_start =
page_to_phys(virt_to_page(fbi->screen_buffer));
#endif
diff --git a/include/drm/drm_client.h b/incl...
2020 Oct 22
2
[PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
...f (map.is_iomem)
> + fbi->screen_base = map.vaddr_iomem;
> + else
> + fbi->screen_buffer = map.vaddr;
>
> - fbi->screen_buffer = vaddr;
> /* Shamelessly leak the physical address to user-space */
> #if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
> if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0)
Just noticed a tiny thing here: I think this needs to be patched to only
set smem_start when the map is _not_ iomem. Since virt_to_page isn't
defined on iomem at all.
I guess it'd be neat if we can set this for iomem too, but I have no idea
how to c...
2020 Sep 29
0
[PATCH v3 5/7] drm/gem: Store client buffer mappings as struct dma_buf_map
...p;map);
+ if (ret)
+ return ret;
+ if (map.is_iomem)
+ fbi->screen_base = map.vaddr_iomem;
+ else
+ fbi->screen_buffer = map.vaddr;
- fbi->screen_buffer = vaddr;
/* Shamelessly leak the physical address to user-space */
#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0)
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 7aaea665bfc2..f07f2fb02e75 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -3,6 +3,7 @@
#ifndef _DRM_CLIENT_H_
#define _DRM_CLIENT_H_
+#include <linux/dma-bu...
2020 Oct 20
0
[PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
...p;map);
+ if (ret)
+ return ret;
+ if (map.is_iomem)
+ fbi->screen_base = map.vaddr_iomem;
+ else
+ fbi->screen_buffer = map.vaddr;
- fbi->screen_buffer = vaddr;
/* Shamelessly leak the physical address to user-space */
#if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0)
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 7aaea665bfc2..f07f2fb02e75 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -3,6 +3,7 @@
#ifndef _DRM_CLIENT_H_
#define _DRM_CLIENT_H_
+#include <linux/dma-bu...
2020 Oct 22
0
[PATCH v5 08/10] drm/gem: Store client buffer mappings as struct dma_buf_map
...i->screen_base = map.vaddr_iomem;
>> + else
>> + fbi->screen_buffer = map.vaddr;
>>
>> - fbi->screen_buffer = vaddr;
>> /* Shamelessly leak the physical address to user-space */
>> #if IS_ENABLED(CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM)
>> if (drm_leak_fbdev_smem && fbi->fix.smem_start == 0)
>
> Just noticed a tiny thing here: I think this needs to be patched to only
> set smem_start when the map is _not_ iomem. Since virt_to_page isn't
> defined on iomem at all.
>
> I guess it'd be neat if we can set this for iomem to...
2019 Jul 05
11
[PATCH v2 0/6] Unmappable DRM client buffers for fbdev emulation
DRM client buffers are permanently mapped throughout their lifetime. This
prevents us from using generic framebuffer emulation for devices with
small dedicated video memory, such as ast or mgag200. With fb buffers
permanently mapped, such devices often won't have enough space left to
display other content (e.g., X11).
This patch set introduces unmappable DRM client buffers for framebuffer
2019 Jul 05
11
[PATCH v2 0/6] Unmappable DRM client buffers for fbdev emulation
DRM client buffers are permanently mapped throughout their lifetime. This
prevents us from using generic framebuffer emulation for devices with
small dedicated video memory, such as ast or mgag200. With fb buffers
permanently mapped, such devices often won't have enough space left to
display other content (e.g., X11).
This patch set introduces unmappable DRM client buffers for framebuffer
2020 Oct 28
10
[PATCH v6 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use
2020 Nov 03
10
[PATCH v7 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use
2020 Nov 03
10
[PATCH v7 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use
2020 Nov 03
10
[PATCH v7 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use
2020 Oct 20
15
[PATCH v5 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use
2020 Sep 29
14
[PATCH v3 0/7] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use
2020 Sep 29
14
[PATCH v3 0/7] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use
2020 Oct 15
19
[PATCH v4 00/10] Support GEM object mappings from I/O memory
DRM's fbdev console uses regular load and store operations to update
framebuffer memory. The bochs driver on sparc64 requires the use of
I/O-specific load and store operations. We have a workaround, but need
a long-term solution to the problem.
This patchset changes GEM's vmap/vunmap interfaces to forward pointers
of type struct dma_buf_map and updates the generic fbdev emulation to
use