Re: [Intel-gfx] [PATCH 0/7] drm drivers: kill drm_get_connector_name() and drm_get_encoder_name()

Am 26.05.2014 15:52, schrieb Daniel Vetter: On Mon, May 26, 2014 at 3:52 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, May 26, 2014 at 04:35:39PM +0300, Jani Nikula wrote: As requested by David [1],[2]. These are on top of drm-intel-nightly which carries the required core patches adding

Re: [Intel-gfx] [PATCH] drm/i915: support address only i2c-over-aux transactions

Am 08.04.2014 15:04, schrieb Alex Deucher: On Tue, Apr 8, 2014 at 4:03 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Apr 8, 2014 at 8:58 AM, Jani Nikula jani.nik...@intel.com wrote: Before the conversion to dp aux helpers there was a switch case [1] that ended up in msg_bytes = 3 for

Re: [Intel-gfx] [RFC PATCH] drm/radeon: fixup locking inversion between mmap_sem and reservations

Am 08.10.2013 16:33, schrieb Jerome Glisse: On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote: Allocate and copy all kernel memory before doing reservations. This prevents a locking inversion between mmap_sem and reservation_class, and allows us to drop the trylocking in

Re: [Intel-gfx] [PATCH 00/11] Mixed bag of ioctl and agp cleanups

Patches #1, #6, #7, #8 and #10 are Reviewed-by: Christian König <christian.koe...@amd.com>. That should be everything touching radeon/amdgpu if I missed something leave me a note. Regards, Christian. On 08.09.2015 13:56, Daniel Vetter wrote: Hi all, Big thing for sure is depre

Re: [Intel-gfx] [PATCH 04/29] drm/amdgpu: Use unlocked gem unreferencing

el.vet...@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Alex Deucher <alexander.deuc...@amd.com> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> For this and the radeon patch Reviewed-by: Christian König <

Re: [Intel-gfx] [PATCH 00/10] drm/edid: Clean up display_info stuff

Looks reasonable to me, adding a few more AMD people which probably want to take a look as well. Patch #3 and #4 are Reviewed-by: Christian König <christian.koe...@amd.com> since they touch the radeon/amdgpu driver. Patch #1, #2 and #5 - #8 are Acked-by: Christian König <chri

Re: [Intel-gfx] [PATCH 1/2] dma-fence: Flag when a fence-array is using signal-on-any

Cc: Gustavo Padovan <gust...@padovan.org> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: "Christian König" <christian.koe...@amd.com> Reviewed-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/dma-fence-array.c | 3 +++ include/linux/dma

Re: [Intel-gfx] [PATCH v2 1/2] drm/prime: Passing the right owner through to dma_buf_export()

Why not just use dev->fops->owner instead of changing the interface everywhere? Regards, Christian. Am 30.09.2016 um 13:44 schrieb Chris Wilson: dma_buf_export() adds a reference to the owning module to the dmabuf (to prevent the driver from being unloaded whilst a third party still refers to

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

g Cc: dri-de...@lists.freedesktop.org Cc: linaro-mm-...@lists.linaro.org Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> Need to strike the r-b here, since Christian König pointed out that objects won't magically switch signalling on. Oh, it also means that commit fb8b7d2b9d80e1e71f379e57355936bd2b02

Re: [Intel-gfx] [PATCH] drm: squash lines for simple wrapper functions

Am 07.09.2016 um 01:04 schrieb Masahiro Yamada: Remove unneeded variables and assignments. Signed-off-by: Masahiro Yamada Tom StDenis was working on a similar patch for amdgpu as well, please make sure that your work doesn't conflict with his. Apart from

Re: [Intel-gfx] [PATCH 01/11] drm/amdgpu: Remove call to reservation_object_test_signaled_rcu before wait

the error code between the nonblocking busy check and potentially blocking wait. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Alex Deucher <alexander.deuc...@amd.com> Cc: Christian König <christian.koe...@amd.com> Mhm, actually it was one of our developers who

Re: [Intel-gfx] [PATCH v3 1/3] drm/prime: Pass the right module owner through to dma_buf_export()

ff-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Petri Latvala <petri.latv...@intel.com> Cc: Christian König <christian.koe...@amd.com> Cc: sta...@vger.kernel.org Tested-by: Petri Latvala <petri.latv...@intel.com> Reviewed-by: Christian König <christian.koe...@amd.com>

Re: [Intel-gfx] [PATCH] drm: move allocation out of drm_get_format_name()

Am 05.11.2016 um 17:49 schrieb Rob Clark: On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom <e...@engestrom.ch> wrote: On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote: Am 05.11.2016 um 02:33 schrieb Eric Engestrom: +typedef char drm_format_name_buf[32]; Please don't use a t

Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()

ed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: Rob Clark <robdcl...@gmail.com> Cc: Christian König <christian.koe...@amd.com> Suggested-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Signed-off-by: Eric Engestrom <e...@engestrom.ch> Acked-by: Chris

Re: [Intel-gfx] [PATCH] drm: move allocation out of drm_get_format_name()

Am 05.11.2016 um 02:33 schrieb Eric Engestrom: +typedef char drm_format_name_buf[32]; Please don't use a typedef for this, just define the maximum size of characters the function might write somewhere. See the kernel coding style as well: In general, a pointer, or a struct that has

Re: [Intel-gfx] [PATCH] dma-buf: Replace reservation shared fence array with a compressed radix tree

Hi Chris, Am 14.11.2016 um 09:31 schrieb Chris Wilson: The primary operation on the shared fence arrays is insertion and retrieval. Retrieval is reasonably fast, as we just copy the array, but insertion into the shared fence array is slow as we must iterate over all current fences to discard

Re: [Intel-gfx] [PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

l <sumit.sem...@linaro.org Reviewed-by: Christian König <christian.koe...@amd.com>. --- include/linux/reservation.h | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/include/linux/reservation.h b/include/linux/reservation.h index 2e313cca08f0..d9706a6f5ae2

Re: [Intel-gfx] [PATCH 1/2] drm: Add some kselftests for the DRM range manager (struct drm_mm)

Am 27.11.2016 um 15:08 schrieb Chris Wilson: A set of test cases to capture some annoying bugs and to ensure that correct behaviour does not regress whilst fixing those! Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Acked-by: Christian König <christian.koe..

Re: [Intel-gfx] [PATCH] drm: Promote drm_mm alignment to u64

/align64 Testcase: igt/gem_exec_alignment Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Reviewed-by: Christian König <christian.koe...@amd.com>. And yeah, we have a couple of use cases aligning something to a 4GB b

Re: [Intel-gfx] [PATCH v2 00/37] drm: Deduplicate fb format information (v2)

Patches #2 and #3 are Reviewed-by: Christian König <christian.koe...@amd.com>. The rest is Acked-by: Christian König <christian.koe...@amd.com>. Regards, Christian. Am 18.11.2016 um 20:52 schrieb ville.syrj...@linux.intel.com: From: Ville Syrjälä <ville.syrj...@linux.int

Re: [Intel-gfx] [PATCH 1/2] drm: Track drm_mm allocators and show leaks on shutdown

tracking down the leak. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Thanks, exactly what I need to debug the leaks in amdgpu as well. Patch is Reviewed-by: Christian König <christian.koe...@amd.com>. Regards, Christian. --- drivers/gpu/drm/Kconfig | 12 dri

Re: [Intel-gfx] [PATCH 00/10] mm: adjust get_user_pages* functions to explicitly pass FOLL_* flags

Patch number 6 in this series (which touches drivers I co-maintain) is Acked-by: Christian König <christian.koe...@amd.com>. In general looks like a very nice cleanup to me, but I'm not enlightened enough to full judge. Regards, Christian. arch/alpha/kernel/pt

Re: [Intel-gfx] [PATCH 21/34] drm: Promote drm_mm alignment to u64

/align64 Testcase: igt/gem_exec_alignment Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Nice, we have a few things which could use an alignment above 4GB as well. Patch is Reviewed-by: Christian König <christian

Re: [Intel-gfx] [PATCH v6] drm: add fourcc codes for 16bit R and RG

online.de> Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Good to see some work landing on that part, patch is Acked-by: Christian König <christian.koe...@amd.com>. --- include/uapi/drm/drm_fourcc.h | 7 +++ 1 file changed, 7 insertions(+) diff

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

Am 09.04.2017 um 18:02 schrieb Chris Wilson: On Sun, Apr 09, 2017 at 09:08:53AM +0200, Christian König wrote: Am 08.04.2017 um 20:00 schrieb Chris Wilson: On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote: Am 08.04.2017 um 18:26 schrieb Chris Wilson: Reserve 0 for general use

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

, Christian. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Sumit Semwal <sumit.sem...@linaro.org> Cc: Gustavo Padovan <gust...@padovan.org> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: "Christian König" <christian.koe...@amd.com Cc: Daniel Vet

Re: [Intel-gfx] [PATCH 1/3] dma-fence: Reserve 0 as a special NO_CONTEXT token

Am 08.04.2017 um 20:00 schrieb Chris Wilson: On Sat, Apr 08, 2017 at 07:49:37PM +0200, Christian König wrote: Am 08.04.2017 um 18:26 schrieb Chris Wilson: Reserve 0 for general use a token meaning that the fence doesn't belong to an ordered timeline (fence context). NAK, we kept context

Re: [Intel-gfx] [PATCH 15/24] drm/radeon: Merge pre/postclose hooks

Reviewed-by: Christian König <christian.koe...@amd.com> for this one and #19. Christian. Am 08.03.2017 um 15:12 schrieb Daniel Vetter: Again no apparent explanation for the split except hysterical raisins. Merging them also makes it a bit more obviuos what's going on wrt the runt

Re: [Intel-gfx] [patch net-next 0/3] net/sched: Improve getting objects by indexes

Am 16.08.2017 um 04:12 schrieb Chris Mi: Using current TC code, it is very slow to insert a lot of rules. In order to improve the rules update rate in TC, we introduced the following two changes: 1) changed cls_flower to use IDR to manage the filters. 2) changed all act_xxx

Re: [Intel-gfx] [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

lt;log...@deltatee.com> --- Good to know that somebody is working on this. Those problems troubled us as well. Patch is Acked-by: Christian König <christian.koe...@amd.com>. Regards, Christian. include/linux/scatterlist.h | 85 + 1 file changed

Re: [Intel-gfx] [PATCH 00/13] mmu_notifier kill invalidate_page callback

Am 31.08.2017 um 15:59 schrieb Jerome Glisse: [Adding Intel folks as they might be interested in this discussion] On Wed, Aug 30, 2017 at 05:51:52PM -0400, Felix Kuehling wrote: Hi Jérôme, I have some questions about the potential range-start-end race you mentioned. On 2017-08-29 07:54 PM,

Re: [Intel-gfx] [PATCH] dma-buf/fence: Fix lock inversion within dma-fence-array

to a minimum by using an irq-work, which is executed asap. Reported-by: Rob Clark <robdcl...@gmail.com> Suggested-by: Rob Clark <robdcl...@gmail.com> References: 1476635975-21981-1-git-send-email-robdcl...@gmail.com Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Reviewed-by:

Re: [Intel-gfx] [PATCH 04/15] dma-fence: Make ->wait callback optional

Am 04.05.2018 um 11:25 schrieb Daniel Vetter: On Fri, May 4, 2018 at 11:16 AM, Chris Wilson wrote: Quoting Daniel Vetter (2018-05-04 09:57:59) On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote: Quoting Daniel Vetter (2018-05-04 09:23:01) On Fri, May 04,

Re: [Intel-gfx] [PATCH] gpu: Consistently use octal not symbolic permissions

Well I think we rejected that multiple times now. At least I find the symbolic permissions easier to read and I absolutely don't see any reason why we should only use one form. Christian. Am 24.05.2018 um 22:22 schrieb Joe Perches: There is currently a mixture of octal and symbolic

Re: [Intel-gfx] [PATCH 04/15] dma-fence: Make ->wait callback optional

Am 02.07.2018 um 10:23 schrieb Daniel Vetter: On Fri, May 04, 2018 at 03:47:59PM +0200, Daniel Vetter wrote: On Fri, May 04, 2018 at 03:17:08PM +0200, Christian König wrote: Am 04.05.2018 um 11:25 schrieb Daniel Vetter: On Fri, May 4, 2018 at 11:16 AM, Chris Wilson wrote: Quoting Daniel

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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 Lahtinen Cc: Rodrigo Viv

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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 because I

Re: [Intel-gfx] [RFC PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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 received

[Intel-gfx] [PATCH 4/4] drm/amdgpu: add independent DMA-buf import v4

interface v4: split out from unpinned DMA-buf work Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 38 +++ drivers/gpu/drm/amd/amdgpu

[Intel-gfx] [PATCH 1/4] dma-buf: add dma_buf_(un)map_attachment_locked variants v2

Add function variants which can be called with the reservation lock already held. v2: reordered, add lockdep asserts, fix kerneldoc Signed-off-by: Christian König --- drivers/dma-buf/dma-buf.c | 57 +++ include/linux/dma-buf.h | 5 + 2 files

[Intel-gfx] First step towards unpinned DMA-buf operation.

[As requested by Daniel cross posting to intel-gfx as well]. This set is the first step towards allowing to use a DMA-buf without actually pinning the underlying resources. This in turn the the ground work for PCIe P2P operations as well as quite a bunch of other use cases. The idea is that we

[Intel-gfx] [PATCH 3/4] drm/amdgpu: add independent DMA-buf export v3

debugging leftovers v3: split out from unpinned DMA-buf work Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 94 +-- 3 files changed, 39

[Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

First step towards unpinned DMA buf operation. I've checked the DRM drivers to potential locking of the reservation object, but essentially we need to audit all implementations of the dma_buf _ops for this to work. v2: reordered Signed-off-by: Christian König --- drivers/dma-buf/dma-buf.c | 9

Re: [Intel-gfx] [PATCH 1/4] dma-buf: add dma_buf_(un)map_attachment_locked variants v2

Am 28.06.2018 um 11:53 schrieb Zhang, Jerry (Junwei): On 06/22/2018 10:11 PM, Christian König wrote: Add function variants which can be called with the reservation lock already held. v2: reordered, add lockdep asserts, fix kerneldoc Signed-off-by: Christian König ---   drivers/dma-buf/dma

Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

Am 25.06.2018 um 11:12 schrieb Daniel Vetter: On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote: On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote: First step towards unpinned DMA buf operation. I've checked the DRM drivers to potential locking of the reservation

Re: [Intel-gfx] [PATCH 3/4] drm/amdgpu: add independent DMA-buf export v3

Am 28.06.2018 um 11:58 schrieb Zhang, Jerry (Junwei): On 06/22/2018 10:11 PM, Christian König wrote: The caching of SGT's done by the DRM code is actually quite harmful and should probably removed altogether in the long term. Start by providing a separate DMA-buf export implementation

Re: [Intel-gfx] [PATCH 13/17] drm/radeon: Remove custom dma_fence_ops->wait implementation

Am 30.04.2018 um 17:38 schrieb Daniel Vetter: On Sun, Apr 29, 2018 at 09:08:31AM +0200, Christian König wrote: NAK, there is a subtitle but major difference: - if (rdev->needs_reset) { - t = -EDEADLK; - br

Re: [Intel-gfx] [PATCH 04/17] dma-fence: Allow wait_any_timeout for all fences

Am 27.04.2018 um 08:17 schrieb Daniel Vetter: When this was introduced in commit a519435a96597d8cd96123246fea4ae5a6c90b02 Author: Christian König <christian.koe...@amd.com> Date: Tue Oct 20 16:34:16 2015 +0200 dma-buf/fence: add fence_wait_any_timeout funct

Re: [Intel-gfx] [PATCH 13/17] drm/radeon: Remove custom dma_fence_ops->wait implementation

iel Vetter: It's a copy of dma_fence_default_wait, written slightly differently. Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: Alex Deucher <alexander.deuc...@amd.com> Cc: "Christian König" <christian.koe...@amd.com> Cc: "David (ChunMing)

Re: [Intel-gfx] [PATCH 00/17] dma-fence doc polish and small cleanup

Patches #1-#5 in this series are Reviewed-by: Christian König <christian.koe...@amd.com> Regards, Christian. Am 27.04.2018 um 08:17 schrieb Daniel Vetter: Hi all, Somewhat motivated by me looking at the v3d patch I went and dug around in the dma-fence code a bit. Result was a bit

Re: [Intel-gfx] [PATCH 06/17] drm/amdgpu: Remove unecessary dma_fence_ops

Am 27.04.2018 um 08:17 schrieb Daniel Vetter: dma_fence_default_wait is the default now. Signed-off-by: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: Alex Deucher <alexander.deuc...@amd.com> Cc: "Christian König" <christian.koe...@amd.com> Cc: Monk Liu <monk.

Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

Am 03.07.2018 um 15:11 schrieb Daniel Vetter: On Tue, Jul 03, 2018 at 03:02:11PM +0200, Christian König wrote: Am 03.07.2018 um 14:52 schrieb Daniel Vetter: On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote: Am 25.06.2018 um 11:12 schrieb Daniel Vetter: On Mon, Jun 25, 2018

Re: [Intel-gfx] [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

Am 03.07.2018 um 14:52 schrieb Daniel Vetter: On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote: Am 25.06.2018 um 11:12 schrieb Daniel Vetter: On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote: On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote: First

Re: [Intel-gfx] [PATCH] dma-buf: Refanctor reservation_object_add_shared_fence()

Am 30.01.2018 um 13:50 schrieb Chris Wilson: Quoting Christian König (2018-01-30 12:26:05) Am 30.01.2018 um 10:32 schrieb Chris Wilson: Adding a shared fence to a reservation_object is currently split into two handlers, one to insert the fence into the existing array and the other to replace

Re: [Intel-gfx] [PATCH] dma-buf: Refanctor reservation_object_add_shared_fence()

faster. Can we keep that as well? Regards, Christian. Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> Cc: Christian König <christian.koe...@amd.com> Cc: Alex Deucher <alexander.deuc...@amd.com> --- drivers/dma-buf/reservation.c | 178 ++---

Re: [Intel-gfx] [PATCH] drm: Use idr_init_base(1) when using id==0 for invalid

-wilson.co.uk> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Cc: Christian Konig <christian.koe...@amd.com> Cc: Dave Airlie <airl...@redhat.com> Yep, looks like all of these pass start==1 to idr_alloc(). Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com> Acked-by: C

[Intel-gfx] [PATCH] drm: move read_domains and write_domain into i915 v2

uot; drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c Change is only compile tested. v2: move fields around as suggested by Chris. Signed-off-by: Christian König <chr

[Intel-gfx] [PATCH] drm: move read_domains and write_domain into i915

uot; drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c sed -i "s/obj->base.write_domain/obj->write_domain/g" drivers/gpu/drm/i915/*.c drivers/gpu/drm/i915/*/*.c Change is only compile tested. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/

Re: [Intel-gfx] [PATCH] drm: move read_domains and write_domain into i915

Am 16.02.2018 um 11:18 schrieb Chris Wilson: Quoting Christian König (2018-02-16 09:31:23) i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all other drivers. Move the fields into drm_i915_gem_object instead and patch the i915 code

Re: [Intel-gfx] [PATCH] drm: move read_domains and write_domain into i915

Am 16.02.2018 um 13:30 schrieb Chris Wilson: Quoting Christian König (2018-02-16 12:27:28) Am 16.02.2018 um 11:18 schrieb Chris Wilson: Quoting Christian König (2018-02-16 09:31:23) i915 is the only driver using those fields in the drm_gem_object structure, so they only waste memory for all

Re: [Intel-gfx] [CI] drm/mm: Fix caching of leftmost node in the interval tree

dlohr Bueso <dbu...@suse.de> Cc: Jérôme Glisse <jgli...@redhat.com> Cc: Christian König <christian.koe...@amd.com> Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Acked-by: Christian König <christian.koe...@amd.com> for now. But I agre

Re: [Intel-gfx] [PULL] drm-misc-next

-subsystem Changes: - some devicetree Docs update Core Changes: - Reject over-sized allocation requests early (Chris Wilson) - gem-fb-helper: Always do implicit sync (Daniel Vetter) - dma-buf cleanups (Christian König) My dma-buf cleanups unfortunately caused a build breakage in ION which I just pu

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

Am 10.08.2018 um 11:21 schrieb Daniel Vetter: [SNIP] Then don't track _any_ of the amdgpu internal fences in the reservation object: - 1 reservation object that you hand to ttm, for use internally within amdgpu - 1 reservation object that you attach to the dma-buf (or get from the imported

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

Am 09.08.2018 um 15:38 schrieb Daniel Vetter: On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote: Hi everyone, This set of patches tries to improve read after write hazard handling for reservation objects. It allows us to specify for each shared fence if it represents a write

Re: [Intel-gfx] [PATCH 1/6] dma-buf: remove shared fence staging in reservation object

Am 09.08.2018 um 14:08 schrieb Chris Wilson: Quoting Christian König (2018-08-09 12:37:08) void reservation_object_add_shared_fence(struct reservation_object *obj, struct dma_fence *fence) { - struct reservation_object_list *old, *fobj = obj

[Intel-gfx] RFC: Add write flag to reservation object fences

Hi everyone, This set of patches tries to improve read after write hazard handling for reservation objects. It allows us to specify for each shared fence if it represents a write operation. Based on this the i915 driver is modified to always wait for all writes before pageflip and the

[Intel-gfx] [PATCH 1/6] dma-buf: remove shared fence staging in reservation object

No need for that any more. Just replace the list when there isn't enough room any more for at least one additional fence. Signed-off-by: Christian König --- drivers/dma-buf/reservation.c | 180 ++ include/linux/reservation.h | 4 - 2 files changed, 60

[Intel-gfx] [PATCH 4/6] dma-buf: add writes_only flag to reservation_object_get_fences_rcu

That allows us to only retreive fences of write operations. Signed-off-by: Christian König --- drivers/dma-buf/reservation.c| 19 +++ drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 3 ++- drivers/gpu/drm/amd

[Intel-gfx] [PATCH 6/6] drm/amdgpu: remove exclusive fence workaround

We now note that all fences are potential writers. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1

[Intel-gfx] [PATCH 3/6] dma-buf: add is_write to reservation_object_add_shared_fence

Note if the added fence is a write by using the lsb in the fenc pointer. Signed-off-by: Christian König --- drivers/dma-buf/dma-buf.c| 8 +++- drivers/dma-buf/reservation.c| 59 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2

[Intel-gfx] [PATCH 5/6] drm/i915: wait for write fences before pflip

Wait for all write operations before page flipping. Signed-off-by: Christian König --- drivers/gpu/drm/i915/intel_display.c | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915

[Intel-gfx] [PATCH 2/6] dma-buf: add reservation object shared fence accessor

Add a helper to access the shared fences in an reservation object. Signed-off-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_sync.c | 3 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++-- drivers/gpu

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

Am 09.08.2018 um 16:22 schrieb Daniel Vetter: On Thu, Aug 9, 2018 at 3:58 PM, Christian König wrote: Am 09.08.2018 um 15:38 schrieb Daniel Vetter: On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote: [SNIP] See to me the explicit fence in the reservation object is not even

Re: [Intel-gfx] [PATCH v5] drm/amdgpu: Transfer fences to dmabuf importer

ex Deucher Cc: "Christian König" Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 58 +++ 1 file changed, 50 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c b/drivers/gpu/drm/amd/amdgpu/

Re: [Intel-gfx] [PATCH] drm: Remove defunct dma_buf_kmap stubs

nd map function pointers optional") Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: Gerd Hoffmann Cc: Alex Deucher Cc: "Christian König" Reviewed-by: Christian König --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 2 -- drivers/gpu/drm/

Re: [Intel-gfx] [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

Am 07.08.2018 um 20:14 schrieb Chris Wilson: Quoting Christian König (2018-08-07 18:57:16) Am 07.08.2018 um 18:08 schrieb Chris Wilson: amdgpu only uses shared-fences internally, but dmabuf importers rely on implicit write hazard tracking via the reservation_object.fence_excl. For example

Re: [Intel-gfx] [PATCH v4] drm/amdgpu: Transfer fences to dmabuf importer

-to-i915 References: 8e94a46c1770 ("drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)") Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: "Christian König" --- This time, hopefully proofread and references complete. -Chris --- drivers/gpu/drm/amd/amdgpu

Re: [Intel-gfx] [PATCH v3] drm/amdgpu: Transfer fences to dmabuf importer

-to-i915 Signed-off-by: Chris Wilson Cc: Alex Deucher Cc: "Christian König" --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 68 --- 1 file changed, 60 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c b/drivers/gpu/drm/

Re: [Intel-gfx] [PATCH v3] drm/amdgpu: Transfer fences to dmabuf importer

Am 07.08.2018 um 14:43 schrieb Daniel Vetter: On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote: Am 07.08.2018 um 13:05 schrieb Chris Wilson: amdgpu only uses shared-fences internally, but dmabuf importers rely on implicit write hazard tracking via

Re: [Intel-gfx] [PATCH v3] drm/amdgpu: Transfer fences to dmabuf importer

Am 07.08.2018 um 14:59 schrieb Daniel Vetter: On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote: Am 07.08.2018 um 14:43 schrieb Daniel Vetter: On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote: Am 07.08.2018 um 13:05 schrieb Chris Wilson: amdgpu only uses shared

Re: [Intel-gfx] [PATCH v3] drm/amdgpu: Transfer fences to dmabuf importer

Am 07.08.2018 um 15:37 schrieb Daniel Vetter: On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote: Am 07.08.2018 um 14:59 schrieb Daniel Vetter: On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote: Am 07.08.2018 um 14:43 schrieb Daniel Vetter: On Tue, Aug 07, 2018

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

Am 10.08.2018 um 09:51 schrieb Chris Wilson: Quoting Christian König (2018-08-09 15:54:31) Am 09.08.2018 um 16:22 schrieb Daniel Vetter: On Thu, Aug 9, 2018 at 3:58 PM, Christian König wrote: Am 09.08.2018 um 15:38 schrieb Daniel Vetter: On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

Am 10.08.2018 um 10:32 schrieb Daniel Vetter: On Fri, Aug 10, 2018 at 10:24 AM, Christian König wrote: Am 10.08.2018 um 09:51 schrieb Chris Wilson: Quoting Christian König (2018-08-09 15:54:31) Am 09.08.2018 um 16:22 schrieb Daniel Vetter: On Thu, Aug 9, 2018 at 3:58 PM, Christian König

Re: [Intel-gfx] RFC: Add write flag to reservation object fences

Am 10.08.2018 um 10:29 schrieb Daniel Vetter: [SNIP] I'm only interested in the case of shared buffers. And for those you _do_ pessimistically assume that all access must be implicitly synced. Iirc amdgpu doesn't support EGL_ANDROID_native_fence_sync, so this makes sense that you don't bother

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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_range_end

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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) -

Re: [Intel-gfx] Possible use_mm() mis-uses

Adding Felix because the KFD part of amdgpu is actually his responsibility. If I'm not completely mistaken the release callback of the mmu_notifier should take care of that for amdgpu. Regards, Christian. Am 22.08.2018 um 18:44 schrieb Linus Torvalds: Guys and gals, this is a *very*

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

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) * *

[Intel-gfx] [PATCH 2/4] drm: remove prime sg_table caching

That is now done by the DMA-buf helpers instead. Signed-off-by: Christian König --- drivers/gpu/drm/drm_prime.c | 78 +++-- 1 file changed, 18 insertions(+), 60 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index

[Intel-gfx] [PATCH 1/4] dma-buf: add caching of sg_table

To allow a smooth transition from pinning buffer objects to dynamic invalidation we first start to cache the sg_table for an attachment unless the driver explicitly says to not do so. Signed-off-by: Christian König --- drivers/dma-buf/dma-buf.c | 24 include/linux/dma

[Intel-gfx] [PATCH 3/4] dma-buf: add dma_buf_(un)map_attachment_locked variants v3

Add function variants which can be called with the reservation lock already held. v2: reordered, add lockdep asserts, fix kerneldoc v3: rebased on sgt caching Signed-off-by: Christian König --- drivers/dma-buf/dma-buf.c | 63 +++ include/linux/dma

[Intel-gfx] [PATCH 4/4] dma-buf: lock the reservation object during (un)map_dma_buf v3

First step towards unpinned DMA buf operation. I've checked the DRM drivers to potential locking of the reservation object, but essentially we need to audit all implementations of the dma_buf _ops for this to work. v2: reordered v3: rebased on sgt caching Signed-off-by: Christian König

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] dma-buf: add caching of sg_table

Hi Daniel, Am 18.07.2018 um 14:07 schrieb Patchwork: == Series Details == Series: series starting with [1/4] dma-buf: add caching of sg_table URL : https://patchwork.freedesktop.org/series/46778/ State : failure [SNIP] it looks like I'm a step further understanding the problems which come

Re: [Intel-gfx] [PATCH 5/5] dma-fence: Polish kernel-doc for dma-fence.c

Padovan Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org Reviewed-by: Christian König --- Documentation/driver-api/dma-buf.rst | 6 ++ drivers/dma-buf/dma-fence.c | 147 +++ 2 files changed, 109 insertions(+), 44 deletions(-) diff --git

  1   2   3   4   5   6   7   8   9   10   >