ll get pci_p2pdma_distance and check attach->peer2peer
before calling drm_gem_map_attach().
Signed-off-by: Julia Zhang
I can't judge that virtgpu or XEN code path, but that here looks like it
should work.
Acked-by: Christian König
---
drivers/gpu/drm/virtio/virtgpu_prime.c | 14 +-
Am 18.06.24 um 16:12 schrieb Demi Marie Obenour:
On Tue, Jun 18, 2024 at 08:33:38AM +0200, Christian König wrote:
> Am 18.06.24 um 02:57 schrieb Demi Marie Obenour:
>> On Mon, Jun 17, 2024 at 10:46:13PM +0200, Marek Marczykowski-Górecki
>> wrote:
>>> On Mon, Jun 17,
asically impossible to restart and still have enough contagious
> memory for a network driver, and there it was about _much_ smaller
> buffers, like 2M or 4M. At least not without shutting down a lot more
> things to free some more memory.
Ouch! That makes me wonder if all GPU drivers ac
special Xen device) we can avoid using
pages and calculate gfns directly from dma addresses provided by
the sg table.
Suggested-by: Daniel Vetter
Signed-off-by: Oleksandr Tyshchenko
I can't say that I can judge the full technical background, but that
looks reasonable to me.
Acked-by: Chri
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König:
Hello Maxime,
On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote:
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote:
Background is that this makes merge conflicts easier to handle and detect.
Really?
FWIW, I agree with
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when thes
Am 17.03.23 um 15:45 schrieb Alex Deucher:
On Thu, Mar 16, 2023 at 7:09 PM Stefano Stabellini
wrote:
On Thu, 16 Mar 2023, Juergen Gross wrote:
On 16.03.23 14:53, Alex Deucher wrote:
On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote:
On 16.03.23 14:45, Alex Deucher wrote:
On Thu, Mar 16,
Am 13.03.23 um 08:23 schrieb Christian König:
Am 12.03.23 um 08:54 schrieb Huang Rui:
From: Chen Jiqian
When dom0 is PVH and we want to passthrough gpu to guest,
we should allow BAR writes even through BAR is mapped. If
not, the value of BARs are not initialized when guest firstly
start
Hi Ray,
one nit comment on the style, apart from that looks technical correct.
But I'm *really* not and expert on all that stuff.
Regards,
Christian.
Am 12.03.23 um 08:54 schrieb Huang Rui:
Hi all,
In graphic world, the 3D applications/games are runing based on open
graphic libraries such as
Am 12.03.23 um 08:54 schrieb Huang Rui:
From: Chen Jiqian
When dom0 is PVH and we want to passthrough gpu to guest,
we should allow BAR writes even through BAR is mapped. If
not, the value of BARs are not initialized when guest firstly
start.
Signed-off-by: Chen Jiqian
Signed-off-by: Huang
Am 20.10.22 um 12:37 schrieb Thomas Zimmermann:
Don't set struct drm_driver.lastclose. It's used to restore the
fbdev console. But as amdgpu uses generic fbdev emulation, the
console is being restored by the DRM client helpers already. See
the call to drm_client_dev_restore() in drm_lastclose().
r of vmap helpers (Daniel,
Christian)
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Tested-by: Sam Ravnborg
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_ttm_helper.c | 38 +++
drivers/gpu/drm/ttm/ttm_bo_util.c| 72 +
Hi Thomas,
[SNIP]
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = &bo->mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_
Am 15.10.20 um 19:52 schrieb Thomas Zimmermann:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
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
rmann
The amdgpu changes look good to me, but I can't fully judge the other stuff.
Acked-by: Christian König
---
Documentation/gpu/todo.rst | 18
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drive
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
: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
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 -
drivers
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
mmermann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3213429f8444..2d5e
PM Christian König
wrote:
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi
Am 02.10.20 um 11:58 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
On Wed, Sep 30, 2020 at 2:34 PM Christian König
wrote:
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi Christian
Am 29.09.20 um 17:35 schrieb Christian König:
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes s
Am 29.09.20 um 17:14 schrieb Thomas Zimmermann:
The new helper ttm_kmap_obj_to_dma_buf() extracts address and location
from and instance of TTM's kmap_obj and initializes struct dma_buf_map
with these values. Helpful for TTM-based drivers.
We could completely drop that if we use the same struct
Feel free to add an Acked-by: Christian König
to all patches which I haven't explicitly reviewed.
I would say we should just push this to drm-misc-next now.
Thanks for the nice cleanup,
Christian.
Am 23.09.20 um 12:21 schrieb Thomas Zimmermann:
The GEM and PRIME related callbacks in s
Added my rb to the amdgpu and radeon patches.
Should we pick those up through the amd branches or do you want to push
everything to drm-misc-next?
I think the later since this should result in much merge clash.
Christian.
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
The GEM and PRIME rel
)
* set callbacks in radeon_gem_object_create() (Christian)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_drv.c | 23 +
drivers/gpu/drm/radeon/radeon_gem.c | 31 +
2 files changed, 28
= kzalloc(sizeof(struct amdgpu_bo), GFP_KERNEL);
if (bo == NULL)
return -ENOMEM;
+
The newline is not unrelated.
Apart from that the patch is Reviewed-by: Christian König
.
But I think we need some smoke testing of it.
Christian.
drm_gem_private_object_init(adev_to_drm(adev), &a
Am 14.09.20 um 17:05 schrieb Thomas Zimmermann:
Hi
Am 13.08.20 um 12:22 schrieb Christian König:
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per
Am 18.08.20 um 10:27 schrieb Gerd Hoffmann:
On Tue, Aug 18, 2020 at 09:57:59AM +0200, Christian König wrote:
Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to gem objects and pass it to
drm_prime_pages_to_sg() calls in d
Am 13.08.20 um 12:41 schrieb Thomas Zimmermann:
Hi
Am 13.08.20 um 12:24 schrieb Christian König:
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_drv.c
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Sign
user_pages in worker
threads")
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Jason Gunthorpe
One question inline to confirm my understanding. Otherwise this patch is
Reviewed-by: Felix Kuehling
---
drivers/gpu/dr
Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
I don't understand this reasoning. What are the
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
v2: rebase cleanup and fix all new implementations as well
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 13 +++--
drivers/gpu/drm
Am 26.08.2018 um 10:40 schrieb Tetsuo Handa:
On 2018/08/24 22:52, Michal Hocko wrote:
@@ -180,11 +180,15 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
*/
static int amdgpu_mn_read_lock(struct amdgpu_mn *amn, bool blockable)
{
- if (blockable)
- mutex_lock(&amn->read_l
Am 24.08.2018 um 15:40 schrieb Michal Hocko:
On Fri 24-08-18 15:28:33, Christian König wrote:
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am
Am 24.08.2018 um 15:24 schrieb Michal Hocko:
On Fri 24-08-18 15:10:08, Christian König wrote:
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
Thiking about it some more, I can imagine that a
Am 24.08.2018 um 15:01 schrieb Michal Hocko:
On Fri 24-08-18 14:52:26, Christian König wrote:
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
[...]
Thiking about it some more, I can imagine that a notifier callback which
performs an allocation might trigger a memory reclaim and that in turn
Am 24.08.2018 um 14:33 schrieb Michal Hocko:
On Fri 24-08-18 14:18:44, Christian König wrote:
Am 24.08.2018 um 14:03 schrieb Michal Hocko:
On Fri 24-08-18 13:57:52, Christian König wrote:
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote
Am 24.08.2018 um 14:03 schrieb Michal Hocko:
On Fri 24-08-18 13:57:52, Christian König wrote:
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
[...]
That won't work like this there might be multiple
invalidate_range_start()/invalidate_rang
Am 24.08.2018 um 13:52 schrieb Michal Hocko:
On Fri 24-08-18 13:43:16, Christian König wrote:
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd
Am 24.08.2018 um 13:32 schrieb Michal Hocko:
On Fri 24-08-18 19:54:19, Tetsuo Handa wrote:
Two more worries for this patch.
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -178,12 +178,18 @@ void amdgpu_mn_unlock(struct amdgpu_mn *mn)
*
* @a
Am 02.07.2018 um 14:35 schrieb Michal Hocko:
On Mon 02-07-18 14:24:29, Christian König wrote:
Am 02.07.2018 um 14:20 schrieb Michal Hocko:
On Mon 02-07-18 14:13:42, Christian König wrote:
Am 02.07.2018 um 13:54 schrieb Michal Hocko:
On Mon 02-07-18 11:14:58, Christian König wrote:
Am
Am 02.07.2018 um 14:20 schrieb Michal Hocko:
On Mon 02-07-18 14:13:42, Christian König wrote:
Am 02.07.2018 um 13:54 schrieb Michal Hocko:
On Mon 02-07-18 11:14:58, Christian König wrote:
Am 27.06.2018 um 09:44 schrieb Michal Hocko:
This is the v2 of RFC based on the feedback I've rec
Am 02.07.2018 um 13:54 schrieb Michal Hocko:
On Mon 02-07-18 11:14:58, Christian König wrote:
Am 27.06.2018 um 09:44 schrieb Michal Hocko:
This is the v2 of RFC based on the feedback I've received so far. The
code even compiles as a bonus ;) I haven't runtime tested it yet, mostly
nvl_range_start waits for completion down the unmap_grant_pages
path so we have to back off early on overlapping ranges
Cc: "David (ChunMing) Zhou"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Jani Nikula
Cc: Joonas
ight away. We simply retry if there is at least one notifier which
couldn't make any progress. A retry loop is already implemented to wait
for the mmap_sem and this is basically the same thing.
Cc: "David (ChunMing) Zhou"
Cc: Paolo Bonzini
Cc: "Radim Krčmář"
Cc: Alex Deucher
ostmem resource that can be used for the hotplug.
Signed-off-by: Boris Ostrovsky
Acked-by: Christian König
---
Changes in v3:
* Use PFN_PHYS
* Replace kzalloc with kmalloc
* Declare arch_xen_balloon_init prototype in balloon.h
* Rename resources (s/memory/RAM/)
* Clarify (I think) com
Am 12.12.2017 um 19:12 schrieb Bjorn Helgaas:
[+cc Boris, Juergen, xen-devel]
On Mon, Dec 11, 2017 at 04:04:52PM +0100, Christian König wrote:
Xen hides a bit of system memory from the OS for its own purpose by
intercepting e820. This memory is unfortunately not reported as
reserved, but
Am 28.11.2017 um 11:53 schrieb Jan Beulich:
On 28.11.17 at 11:17, wrote:
Am 28.11.2017 um 10:46 schrieb Jan Beulich:
On 28.11.17 at 10:12, wrote:
In theory the BIOS would search for address space and won't find
anything, so the hotplug operation should fail even before it reaches
the kernel
Am 27.11.2017 um 19:30 schrieb Boris Ostrovsky:
On 11/23/2017 09:12 AM, Boris Ostrovsky wrote:
On 11/23/2017 03:11 AM, Christian König wrote:
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On 11
Am 28.11.2017 um 10:46 schrieb Jan Beulich:
On 28.11.17 at 10:12, wrote:
In theory the BIOS would search for address space and won't find
anything, so the hotplug operation should fail even before it reaches
the kernel in the first place.
How would the BIOS know what the OS does or plans to do
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On 11/22/2017 05:09 AM, Christian König wrote:
Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
On 11/21/2017 08:34 AM, Christian König wrote:
Hi
58 matches
Mail list logo
