On 2020/10/14 下午4:37, Jie Deng wrote:
On 2020/10/13 16:00, Jason Wang wrote:
+
+ virtqueue_kick(vq);
+
+ time_left =
wait_for_completion_timeout(>completion, adap->timeout);
+ if (!time_left) {
+ dev_err(>dev, "msg[%d]: addr=0x%x
timeout.\n", i,
On 15.10.20 06:02, Wei Yang wrote:
> On Mon, Oct 12, 2020 at 02:52:56PM +0200, David Hildenbrand wrote:
>> We actually need one byte less (next_mb_id is exclusive, first_mb_id is
>> inclusive). Simplify.
>>
>> Cc: "Michael S. Tsirkin"
>> Cc: Jason Wang
>> Cc: Pankaj Gupta
>> Signed-off-by:
On 15.10.20 10:28, Wei Yang wrote:
> On Mon, Oct 12, 2020 at 02:52:59PM +0200, David Hildenbrand wrote:
>> Let's check by traversing busy system RAM resources instead, to avoid
>> relying on memory block states.
>>
>> Don't use walk_system_ram_range(), as that works on pages and we want to
>> use
On 2020/10/14 上午7:42, si-wei liu wrote:
So what I suggest is to fix the pinning leakage first and do the
possible optimization on top (which is still questionable to me).
OK. Unfortunately, this was picked and got merged in upstream. So I
will post a follow up patch set to 1) revert the
On 15.10.20 10:32, Wei Yang wrote:
> On Mon, Oct 12, 2020 at 02:53:00PM +0200, David Hildenbrand wrote:
>> Avoid using memory block ids. Rename it to virtio_mem_contains_range().
>>
>> Cc: "Michael S. Tsirkin"
>> Cc: Jason Wang
>> Cc: Pankaj Gupta
>> Signed-off-by: David Hildenbrand
>> ---
>>
On 15.10.20 12:00, Wei Yang wrote:
> On Thu, Oct 15, 2020 at 10:00:15AM +0200, David Hildenbrand wrote:
>> On 15.10.20 06:02, Wei Yang wrote:
>>> On Mon, Oct 12, 2020 at 02:52:56PM +0200, David Hildenbrand wrote:
We actually need one byte less (next_mb_id is exclusive, first_mb_id is
On Thu, Oct 15, 2020 at 02:15:32PM +0800, Jason Wang wrote:
>
> On 2020/10/14 上午7:42, si-wei liu wrote:
> > >
> > >
> > > So what I suggest is to fix the pinning leakage first and do the
> > > possible optimization on top (which is still questionable to me).
> > OK. Unfortunately, this was
On Mon, Oct 12, 2020 at 02:53:21PM +0200, David Hildenbrand wrote:
> virtio-mem soon wants to use offline_and_remove_memory() memory that
> exceeds a single Linux memory block (memory_block_size_bytes()). Let's
> remove that restriction.
>
> Let's remember the old state and try to restore that if
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
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
GEM's vmap and vunmap interfaces now wrap memory pointers in struct
dma_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
---
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.
Signed-off-by: Thomas Zimmermann
---
include/linux/dma-buf-map.h | 72 +++--
1 file changed, 62 insertions(+), 10 deletions(-)
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.
For
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
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
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
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:
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
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
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
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
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
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 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
---
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
---
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
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
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 1 -
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
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17 -
drivers/gpu/drm/vc4/vc4_bo.c | 1 -
include/drm/drm_gem_cma_helper.h
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
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
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
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
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > 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
Hi
On Thu, 15 Oct 2020 16:08:13 +0200 Christian König
wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
> > 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
On 10/15/2020 6:11 AM, Michael S. Tsirkin wrote:
On Thu, Oct 15, 2020 at 02:15:32PM +0800, Jason Wang wrote:
On 2020/10/14 上午7:42, si-wei liu wrote:
So what I suggest is to fix the pinning leakage first and do the
possible optimization on top (which is still questionable to me).
OK.
28 matches
Mail list logo
