From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3C825C433DF for ; Fri, 10 Jul 2020 20:02:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F10CD2078B for ; Fri, 10 Jul 2020 20:02:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SqNPnTQb" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728397AbgGJUCd (ORCPT ); Fri, 10 Jul 2020 16:02:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38902 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727810AbgGJUCc (ORCPT ); Fri, 10 Jul 2020 16:02:32 -0400 Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C7E3C08C5DC for ; Fri, 10 Jul 2020 13:02:32 -0700 (PDT) Received: by mail-oi1-x243.google.com with SMTP id t198so5762915oie.7 for ; Fri, 10 Jul 2020 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=SqNPnTQbjsymEOAYWvf7HTkD0FI+HW6j/e6KRe6XGJh3lSuGZ0C7kP/iBUFjVJ03M5 t8w6HTmvlfEqaW7ZR4/WDh2zFfGdT+tuiUcDAyD+AEP04wFuCMGfRQQM26yq17Soms89 nnpW0b1zmvAznK5+R6nx5wurVKlahUyCP/oLY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=H+jBDvEgkCX4tmiM3rElPeZqRgVa2NUj/cokgAg6Cq4es3ZwoZL1BOfUpVwIa8vcs2 k4oSiz4lz+iLpvpS9TM2UnhFfkzzZm1Vqyd8UasB4CmrBrbJM2jnYiwvYc3LMEyuFRZW B2fAAtOkDar2gmRAHLLMtGgJ8Q/gHW54Vq4dh6KsJlPjnujGhCt2rCo/9Wj8jIlzNImg l7cTTwgiAEf2qHD1dpuJaieEDPYG4dk97+5XjikKQIHqMzHF6IZi+Sh/ERuIYS54qqeh P8ZBFavwOm1cq0gCnrZ50yScwoh75FxurUTWAWg4HYniab4pel8z9metpC52nNEl17aj 0Lcg== X-Gm-Message-State: AOAM5300QX6zh0/SN0yZ/PeAO1INlfEc+8xXZUMQbanwwQRVSTjwuIs1 +V2l9c9cMVu/GHLG1eAf50dCRFS8nltXU7bd3y2ijg== X-Google-Smtp-Source: ABdhPJyXe/UuJLRx5f5TlPpv/BPhnkWHORX2InNLi0AlJObIla3gh+GkiBljOI27Z+bfXCvGSQK4tsearkrRp5oifn8= X-Received: by 2002:aca:da03:: with SMTP id r3mr5553679oig.14.1594411351996; Fri, 10 Jul 2020 13:02:31 -0700 (PDT) MIME-Version: 1.0 References: <20200707201229.472834-1-daniel.vetter@ffwll.ch> <20200707201229.472834-3-daniel.vetter@ffwll.ch> <20200709080911.GP3278063@phenom.ffwll.local> <20200710124357.GB23821@mellanox.com> <5c163d74-4a28-1d74-be86-099b4729a2e0@amd.com> <20200710125453.GC23821@mellanox.com> <4f4a2cf7-f505-8494-1461-bd467870481e@amd.com> <20200710134826.GD23821@mellanox.com> <20200710142347.GE23821@mellanox.com> In-Reply-To: <20200710142347.GE23821@mellanox.com> From: Daniel Vetter Date: Fri, 10 Jul 2020 22:02:20 +0200 Message-ID: Subject: Re: [PATCH 02/25] dma-fence: prime lockdep annotations To: Jason Gunthorpe Cc: =?UTF-8?Q?Christian_K=C3=B6nig?= , DRI Development , Intel Graphics Development , linux-rdma , Felix Kuehling , kernel test robot , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , Mika Kuoppala , "open list:DMA BUFFER SHARING FRAMEWORK" , "moderated list:DMA BUFFER SHARING FRAMEWORK" , amd-gfx list , Chris Wilson , Maarten Lankhorst , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org On Fri, Jul 10, 2020 at 4:23 PM Jason Gunthorpe wrote: > > On Fri, Jul 10, 2020 at 04:02:35PM +0200, Daniel Vetter wrote: > > > > dma_fence only possibly makes some sense if you intend to expose the > > > completion outside a single driver. > > > > > > The prefered kernel design pattern for this is to connect things with > > > a function callback. > > > > > > So the actual use case of dma_fence is quite narrow and tightly linked > > > to DRM. > > > > > > I don't think we should spread this beyond DRM, I can't see a reason. > > > > Yeah v4l has a legit reason to use dma_fence, android wants that > > there. > > 'legit' in the sense the v4l is supposed to trigger stuff in DRM when > V4L DMA completes? I would still see that as part of DRM Yes, and also the other way around. But thus far it didn't land. -Daniel > Or is it building a parallel DRM like DMA completion graph? > > > > Trying to improve performance of limited HW by using sketchy > > > techniques at the cost of general system stability should be a NAK. > > > > Well that's pretty much gpu drivers, all the horrors for a bit more speed :-) > > > > On the text itself, should I upgrade to "must not" instead of "should > > not"? Or more needed? > > Fundamentally having some unknowable graph of dependencies where parts > of the graph can be placed in critical regions like notifiers is a > complete maintenance nightmare. > > I think building systems like this should be discouraged :\ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35B02C433E4 for ; Fri, 10 Jul 2020 20:02:35 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 065C52075D for ; Fri, 10 Jul 2020 20:02:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SqNPnTQb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 065C52075D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8C2556ED02; Fri, 10 Jul 2020 20:02:33 +0000 (UTC) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by gabe.freedesktop.org (Postfix) with ESMTPS id B3CA66E175 for ; Fri, 10 Jul 2020 20:02:32 +0000 (UTC) Received: by mail-oi1-x243.google.com with SMTP id w17so5760136oie.6 for ; Fri, 10 Jul 2020 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=SqNPnTQbjsymEOAYWvf7HTkD0FI+HW6j/e6KRe6XGJh3lSuGZ0C7kP/iBUFjVJ03M5 t8w6HTmvlfEqaW7ZR4/WDh2zFfGdT+tuiUcDAyD+AEP04wFuCMGfRQQM26yq17Soms89 nnpW0b1zmvAznK5+R6nx5wurVKlahUyCP/oLY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=JsiTOZOQ1KB9N6I4VMjius9XvljR1bVHVBKQezQfMquXgeCmRfZi5WueomuQ+LfA6O LASqAm+CsjYYNJ0XF/9Wb3LlQmcx/AWCTOsSgjTu4lwhJnRHLiBdZG8j7y5RxiGwKmcV 3OW/tfD7dWiWv8oNe6zeCEIouHC1C1Igi3QUoiz6dRVIYhSOvTPfAxubcwBNiaoSb0aZ kQLm4rMDT9HT6B0I9SvQh3Gyayg0GK++mGMvlH2WqSm6zU0HnKy/Gi/GX0GQ19pUSp3B Enw/UZiYUY4fks9jaBQbTT1u+DETAr1WF94Vl1rJ/Ba1sZ6Clpl/Bvb7/9k6Fyh3StyB hrng== X-Gm-Message-State: AOAM530BE3hoxcOoOw8db/HyeAEx1VOrtjeFfF87xhm5fKZoXDlMzjVN ZKmuzK2ioMkCdo1Hsbxl95eereInssd7djWnLr6ERERW X-Google-Smtp-Source: ABdhPJyXe/UuJLRx5f5TlPpv/BPhnkWHORX2InNLi0AlJObIla3gh+GkiBljOI27Z+bfXCvGSQK4tsearkrRp5oifn8= X-Received: by 2002:aca:da03:: with SMTP id r3mr5553679oig.14.1594411351996; Fri, 10 Jul 2020 13:02:31 -0700 (PDT) MIME-Version: 1.0 References: <20200707201229.472834-1-daniel.vetter@ffwll.ch> <20200707201229.472834-3-daniel.vetter@ffwll.ch> <20200709080911.GP3278063@phenom.ffwll.local> <20200710124357.GB23821@mellanox.com> <5c163d74-4a28-1d74-be86-099b4729a2e0@amd.com> <20200710125453.GC23821@mellanox.com> <4f4a2cf7-f505-8494-1461-bd467870481e@amd.com> <20200710134826.GD23821@mellanox.com> <20200710142347.GE23821@mellanox.com> In-Reply-To: <20200710142347.GE23821@mellanox.com> From: Daniel Vetter Date: Fri, 10 Jul 2020 22:02:20 +0200 Message-ID: Subject: Re: [PATCH 02/25] dma-fence: prime lockdep annotations To: Jason Gunthorpe X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Chris Wilson , kernel test robot , linux-rdma , Felix Kuehling , DRI Development , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , amd-gfx list , Daniel Vetter , "open list:DMA BUFFER SHARING FRAMEWORK" , Intel Graphics Development , Mika Kuoppala Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Jul 10, 2020 at 4:23 PM Jason Gunthorpe wrote: > > On Fri, Jul 10, 2020 at 04:02:35PM +0200, Daniel Vetter wrote: > > > > dma_fence only possibly makes some sense if you intend to expose the > > > completion outside a single driver. > > > > > > The prefered kernel design pattern for this is to connect things with > > > a function callback. > > > > > > So the actual use case of dma_fence is quite narrow and tightly linked > > > to DRM. > > > > > > I don't think we should spread this beyond DRM, I can't see a reason. > > > > Yeah v4l has a legit reason to use dma_fence, android wants that > > there. > > 'legit' in the sense the v4l is supposed to trigger stuff in DRM when > V4L DMA completes? I would still see that as part of DRM Yes, and also the other way around. But thus far it didn't land. -Daniel > Or is it building a parallel DRM like DMA completion graph? > > > > Trying to improve performance of limited HW by using sketchy > > > techniques at the cost of general system stability should be a NAK. > > > > Well that's pretty much gpu drivers, all the horrors for a bit more speed :-) > > > > On the text itself, should I upgrade to "must not" instead of "should > > not"? Or more needed? > > Fundamentally having some unknowable graph of dependencies where parts > of the graph can be placed in critical regions like notifiers is a > complete maintenance nightmare. > > I think building systems like this should be discouraged :\ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 419A3C433E2 for ; Fri, 10 Jul 2020 20:02:34 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D8EDD2077D for ; Fri, 10 Jul 2020 20:02:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SqNPnTQb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8EDD2077D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 436526E175; Fri, 10 Jul 2020 20:02:33 +0000 (UTC) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id B9EC36ED02 for ; Fri, 10 Jul 2020 20:02:32 +0000 (UTC) Received: by mail-oi1-x242.google.com with SMTP id r8so5773550oij.5 for ; Fri, 10 Jul 2020 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=SqNPnTQbjsymEOAYWvf7HTkD0FI+HW6j/e6KRe6XGJh3lSuGZ0C7kP/iBUFjVJ03M5 t8w6HTmvlfEqaW7ZR4/WDh2zFfGdT+tuiUcDAyD+AEP04wFuCMGfRQQM26yq17Soms89 nnpW0b1zmvAznK5+R6nx5wurVKlahUyCP/oLY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=b/tKGO5zmSTSznhMPbw2UOpyxm3N++JZPATE9ingrdVoQrvZX+ktzivr9BH+z4Kb0+ PGsn0uh+RJCon4jD8CQiTUFnpE8qkfOpPWz7Gh+v8RBkOUExM/7n9NjFoxhUpYie5lJV SPQZXNa4GeSJ0bqXq+eDv/WayPnFiR6l1nHOXmoLs6q7g63XIhFfG8OGaNia9VH4e7OK aME1zNJOeTIUFq68qjggzn5UGmIzAo5vUyf38M45mdKnBRNH40hc/kk0O13R2m8UfdYT N1AhneBUBJj51RVrbcYHCY1UhlcLNLt9VgXxyp4IbqAo73X0fQ/m59HK3cg5KfZSTpU/ 6OYQ== X-Gm-Message-State: AOAM530QJCasAOEgG7uCLNqIXvs3SGcy9pQ1CIsP34FUFa1T10lQX95a M/SplywZw/FzgBkV3MqHcTZEGcNfMOxWuo/FyyLtwA== X-Google-Smtp-Source: ABdhPJyXe/UuJLRx5f5TlPpv/BPhnkWHORX2InNLi0AlJObIla3gh+GkiBljOI27Z+bfXCvGSQK4tsearkrRp5oifn8= X-Received: by 2002:aca:da03:: with SMTP id r3mr5553679oig.14.1594411351996; Fri, 10 Jul 2020 13:02:31 -0700 (PDT) MIME-Version: 1.0 References: <20200707201229.472834-1-daniel.vetter@ffwll.ch> <20200707201229.472834-3-daniel.vetter@ffwll.ch> <20200709080911.GP3278063@phenom.ffwll.local> <20200710124357.GB23821@mellanox.com> <5c163d74-4a28-1d74-be86-099b4729a2e0@amd.com> <20200710125453.GC23821@mellanox.com> <4f4a2cf7-f505-8494-1461-bd467870481e@amd.com> <20200710134826.GD23821@mellanox.com> <20200710142347.GE23821@mellanox.com> In-Reply-To: <20200710142347.GE23821@mellanox.com> From: Daniel Vetter Date: Fri, 10 Jul 2020 22:02:20 +0200 Message-ID: To: Jason Gunthorpe Subject: Re: [Intel-gfx] [PATCH 02/25] dma-fence: prime lockdep annotations X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Chris Wilson , linux-rdma , Felix Kuehling , DRI Development , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , amd-gfx list , Daniel Vetter , "open list:DMA BUFFER SHARING FRAMEWORK" , Intel Graphics Development , Mika Kuoppala Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Fri, Jul 10, 2020 at 4:23 PM Jason Gunthorpe wrote: > > On Fri, Jul 10, 2020 at 04:02:35PM +0200, Daniel Vetter wrote: > > > > dma_fence only possibly makes some sense if you intend to expose the > > > completion outside a single driver. > > > > > > The prefered kernel design pattern for this is to connect things with > > > a function callback. > > > > > > So the actual use case of dma_fence is quite narrow and tightly linked > > > to DRM. > > > > > > I don't think we should spread this beyond DRM, I can't see a reason. > > > > Yeah v4l has a legit reason to use dma_fence, android wants that > > there. > > 'legit' in the sense the v4l is supposed to trigger stuff in DRM when > V4L DMA completes? I would still see that as part of DRM Yes, and also the other way around. But thus far it didn't land. -Daniel > Or is it building a parallel DRM like DMA completion graph? > > > > Trying to improve performance of limited HW by using sketchy > > > techniques at the cost of general system stability should be a NAK. > > > > Well that's pretty much gpu drivers, all the horrors for a bit more speed :-) > > > > On the text itself, should I upgrade to "must not" instead of "should > > not"? Or more needed? > > Fundamentally having some unknowable graph of dependencies where parts > of the graph can be placed in critical regions like notifiers is a > complete maintenance nightmare. > > I think building systems like this should be discouraged :\ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50BEEC433E1 for ; Fri, 10 Jul 2020 20:02:34 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 20A15207BB for ; Fri, 10 Jul 2020 20:02:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="SqNPnTQb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 20A15207BB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9A19F6ED04; Fri, 10 Jul 2020 20:02:33 +0000 (UTC) Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id BA4806ED04 for ; Fri, 10 Jul 2020 20:02:32 +0000 (UTC) Received: by mail-oi1-x242.google.com with SMTP id e4so5793641oib.1 for ; Fri, 10 Jul 2020 13:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=SqNPnTQbjsymEOAYWvf7HTkD0FI+HW6j/e6KRe6XGJh3lSuGZ0C7kP/iBUFjVJ03M5 t8w6HTmvlfEqaW7ZR4/WDh2zFfGdT+tuiUcDAyD+AEP04wFuCMGfRQQM26yq17Soms89 nnpW0b1zmvAznK5+R6nx5wurVKlahUyCP/oLY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hlzdQKgtPmO74k0pNR7vHuIZBrt/Pc63RtVTndWe5dA=; b=B2g1aU6Lctp3kwtco5urFM6+/yzW+c/HAvcnApu//J3tJNwiXV6YSqMQgf17IQRQbO 5qS4mw8D3qcmiEFoC3bstB2ne/WXvhSFmnMZTWVmpT50dYyp2VbKAKP0v2wuot2VDfbT mYsttbtvVt9XJ4WTHTToG0oGmGhDvrGQqqi84MCa8rOwF/ZU5Z7KkpnNxk05cF3agT0e M9FNKmlm0zows+2G4AaNE2R4AVIfFz5/NR3zGUlRexgSrRsLfan+jbclCPb1UU009+eZ SXHfJpmoi8/nxnFwV3gjgrWx2fpm5g/k2yT/XTm5BsQwlle1Rdmx3izArz5T2UNzrS1T YR6Q== X-Gm-Message-State: AOAM531l2+HBdzFQgoMGvxUaZ55lQr/cepjPXO0NSS9gges5FG1NOFqq 49RTYNcsy15LHhDL9RQ0TAxukfD/WdrGFL3j/eCmtQ== X-Google-Smtp-Source: ABdhPJyXe/UuJLRx5f5TlPpv/BPhnkWHORX2InNLi0AlJObIla3gh+GkiBljOI27Z+bfXCvGSQK4tsearkrRp5oifn8= X-Received: by 2002:aca:da03:: with SMTP id r3mr5553679oig.14.1594411351996; Fri, 10 Jul 2020 13:02:31 -0700 (PDT) MIME-Version: 1.0 References: <20200707201229.472834-1-daniel.vetter@ffwll.ch> <20200707201229.472834-3-daniel.vetter@ffwll.ch> <20200709080911.GP3278063@phenom.ffwll.local> <20200710124357.GB23821@mellanox.com> <5c163d74-4a28-1d74-be86-099b4729a2e0@amd.com> <20200710125453.GC23821@mellanox.com> <4f4a2cf7-f505-8494-1461-bd467870481e@amd.com> <20200710134826.GD23821@mellanox.com> <20200710142347.GE23821@mellanox.com> In-Reply-To: <20200710142347.GE23821@mellanox.com> From: Daniel Vetter Date: Fri, 10 Jul 2020 22:02:20 +0200 Message-ID: Subject: Re: [PATCH 02/25] dma-fence: prime lockdep annotations To: Jason Gunthorpe X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Chris Wilson , kernel test robot , linux-rdma , Felix Kuehling , Maarten Lankhorst , DRI Development , =?UTF-8?Q?Christian_K=C3=B6nig?= , "moderated list:DMA BUFFER SHARING FRAMEWORK" , =?UTF-8?Q?Thomas_Hellstr=C3=B6m?= , amd-gfx list , Daniel Vetter , "open list:DMA BUFFER SHARING FRAMEWORK" , Intel Graphics Development , Mika Kuoppala Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" On Fri, Jul 10, 2020 at 4:23 PM Jason Gunthorpe wrote: > > On Fri, Jul 10, 2020 at 04:02:35PM +0200, Daniel Vetter wrote: > > > > dma_fence only possibly makes some sense if you intend to expose the > > > completion outside a single driver. > > > > > > The prefered kernel design pattern for this is to connect things with > > > a function callback. > > > > > > So the actual use case of dma_fence is quite narrow and tightly linked > > > to DRM. > > > > > > I don't think we should spread this beyond DRM, I can't see a reason. > > > > Yeah v4l has a legit reason to use dma_fence, android wants that > > there. > > 'legit' in the sense the v4l is supposed to trigger stuff in DRM when > V4L DMA completes? I would still see that as part of DRM Yes, and also the other way around. But thus far it didn't land. -Daniel > Or is it building a parallel DRM like DMA completion graph? > > > > Trying to improve performance of limited HW by using sketchy > > > techniques at the cost of general system stability should be a NAK. > > > > Well that's pretty much gpu drivers, all the horrors for a bit more speed :-) > > > > On the text itself, should I upgrade to "must not" instead of "should > > not"? Or more needed? > > Fundamentally having some unknowable graph of dependencies where parts > of the graph can be placed in critical regions like notifiers is a > complete maintenance nightmare. > > I think building systems like this should be discouraged :\ -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx