The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's location ani/or writecombine flags.
On top TTM's
This patch replaces the vmap/vunmap's use of raw pointers in GEM object
functions with instances of struct dma_buf_map. GEM backends are
converted as well. For most of them, this simply changes the returned type.
TTM-based drivers now return information about the location of the memory,
either
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client.c | 18 +++---
drivers/gpu/drm/drm_gem.c | 26 +-
To do framebuffer updates, one needs memcpy from system memory and a
pointer-increment function. Add both interfaces with documentation.
v5:
* include to build on sparc64 (Sam)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
Tested-by: Sam Ravnborg
---
The parameters map and is_iomem are always of the same value. Removed them
to prepares the function for conversion to struct dma_buf_map.
v4:
* don't check for !kmap->virtual; will always be false
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
At least sparc64 requires I/O-specific access to framebuffers. This
patch updates the fbdev console accordingly.
For drivers with direct access to the framebuffer memory, the callback
functions in struct fb_ops test for the type of memory and call the rsp
fb_sys_ of fb_cfb_ functions. Read and
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
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c
The functions exynos_drm_gem_prime_{vmap,vunmap}() are empty. Remove
them before changing the interface to use struct drm_buf_map. As a side
effect of removing drm_gem_prime_vmap(), the error code changes from
ENOMEM to EOPNOTSUPP.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
Kernel DRM clients now store their framebuffer address in an instance
of struct dma_buf_map. Depending on the buffer's location, the address
refers to system or I/O memory.
Callers of drm_client_buffer_vmap() receive a copy of the value in
the call's supplied arguments. It can be accessed and
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Tested-by: Sam Ravnborg
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
I sent a patch to the mailing list and wanted to have some review on
that from at least Ben, but no idea if Ben already picked it and if
it's good enough for sending it to stable yet.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
On Saturday 10 October 2020 02:02:42 Karol Herbst wrote:
> On Sat, Oct 10, 2020 at 12:23 AM Ilia Mirkin wrote:
> >
> > On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote:
> > >
> > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote:
> > > >
> > > > Hello,
> > > > I'm testing 5.9.0-rc8 and found
On Wed, Oct 28, 2020 at 7:50 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features,
On Wed, Oct 28, 2020 at 8:02 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 50145474f6ef
Hi
Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem is that most
Hi Daniel.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
> Now the problem
On Wed, Oct 28, 2020 at 5:45 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> >
Hi Daniel et al.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> So ever since syzbot discovered fbcon, we have solid proof that it's
> full of bugs. And often the solution is to just delete code and remove
> features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
>
So ever since syzbot discovered fbcon, we have solid proof that it's
full of bugs. And often the solution is to just delete code and remove
features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat
fbcon as an dumb
On Wed, Oct 28, 2020 at 10:20 AM Dave Stevenson
wrote:
>
> Hi Ilia
>
> Thanks for taking the time to reply.
>
> On Wed, 28 Oct 2020 at 14:10, Ilia Mirkin wrote:
> >
> > The most common issue on arm is that the pci memory window is too narrow to
> > allocate all the BARs. Can you see if there
Hi Ilia
Thanks for taking the time to reply.
On Wed, 28 Oct 2020 at 14:10, Ilia Mirkin wrote:
>
> The most common issue on arm is that the pci memory window is too narrow to
> allocate all the BARs. Can you see if there are messages in the kernel to
> that effect?
All the BAR allocations
The most common issue on arm is that the pci memory window is too narrow to
allocate all the BARs. Can you see if there are messages in the kernel to
that effect?
On Wed, Oct 28, 2020, 9:46 AM Dave Stevenson
wrote:
> Hi
>
> Seeing as we (Raspberry Pi) have just launched the Compute Module 4
>
Hi
Seeing as we (Raspberry Pi) have just launched the Compute Module 4
with an exposed PCIe x1 lane, people are asking about adding graphics
cards.
Seeing as you are the people who have the knowledge with regard to
NVidia and nouveau, what are your immediate thoughts of nouveau
working on
25 matches
Mail list logo
