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=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 55F5CC433E1 for ; Tue, 23 Jun 2020 10:51:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2F8BE20768 for ; Tue, 23 Jun 2020 10:51:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=ffwll.ch header.i=@ffwll.ch header.b="gOKzF5Yl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732328AbgFWKvS (ORCPT ); Tue, 23 Jun 2020 06:51:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732289AbgFWKvR (ORCPT ); Tue, 23 Jun 2020 06:51:17 -0400 Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 02880C061755 for ; Tue, 23 Jun 2020 03:51:15 -0700 (PDT) Received: by mail-ot1-x342.google.com with SMTP id 18so1442311otv.6 for ; Tue, 23 Jun 2020 03:51:15 -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:content-transfer-encoding; bh=QoCPlVuRfLdDkwTBRDRK73tEwxS3sN2fuJiGkn2CvdE=; b=gOKzF5Yl8kKYahi5zjnsTU+qXPPirvcXIt/7AkVJ+qdy+FWf0uU8V6HbpsO4r2juD7 w2iP9eBLHtTmU+rweutvCfl7szvkDoX2LnG9M/YYCRnGryXBoohfc4iAuNKngf9sT2St 1E0jtqC1MmLkv3KSwEE7j8DVPU+fk/IRWiczw= 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:content-transfer-encoding; bh=QoCPlVuRfLdDkwTBRDRK73tEwxS3sN2fuJiGkn2CvdE=; b=ft20848uuN0REbIxvbIUR69AX2J11ojBvUfFf/R3a+miI9rBHavE6ikGmgx3JF1oJm Oz5iCs5Y4LiyLua9KTYv35J205fQIiPqLLodKjoqM89q+SAC9VJ+IEN12/u8QQAf/fa+ eY9r+5UCuWv5G0oNECj9MGywFD4ezIL7iJXDzo0uJwOa8DgW79l3Ej19tzS+rF0V3gB4 zljK4DUweiybgSUcH+zLewcnVJBxRdpJXASYyeebhJANmmKdI+VJhKIEdlbvekn/z4bf IrgvgMeJ6auIcgTSI6XVE+qLqLnOtgj+/OUBvzC7RUoaQ0LekKJoYoMfT30Ug/YXJ9h8 /Wsw== X-Gm-Message-State: AOAM5336WvV6QY9WCy+LjqPBjmDWImwkXhD0ik9e4/OlxdCbs+UDznGx jCzNksXI0LQ88JjjObI55/kjXUCtUir1EJMsrkd8uQ== X-Google-Smtp-Source: ABdhPJwsXeafc7ngCrqn/R9dExkVr9aTpMWL7pHCp5L8XQ6N2/9uvR1ASQII2PdIi3/ADKwLAzkpagO1g50upZNnhdo= X-Received: by 2002:a05:6830:54:: with SMTP id d20mr18786397otp.281.1592909475390; Tue, 23 Jun 2020 03:51:15 -0700 (PDT) MIME-Version: 1.0 References: <20200604081224.863494-1-daniel.vetter@ffwll.ch> <20200604081224.863494-9-daniel.vetter@ffwll.ch> In-Reply-To: <20200604081224.863494-9-daniel.vetter@ffwll.ch> From: Daniel Vetter Date: Tue, 23 Jun 2020 12:51:04 +0200 Message-ID: Subject: Re: [PATCH 08/18] drm/amdgpu: add dma-fence annotations to atomic commit path To: DRI Development , Roland Scheidegger , VMware Graphics , Thomas Hellstrom Cc: Intel Graphics Development , LKML , linux-rdma , amd-gfx list , "open list:DMA BUFFER SHARING FRAMEWORK" , "moderated list:DMA BUFFER SHARING FRAMEWORK" , Chris Wilson , Maarten Lankhorst , =?UTF-8?Q?Christian_K=C3=B6nig?= , Daniel Vetter Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-rdma-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-rdma@vger.kernel.org Hi Roland & vmwgfx maintainers, Thomas has played around with these annotations on his vmwgfx setup, and found some issues. Apparently in the atomic_commit_tail path when handling the dirty rectangle stuff you acquire a ttm reservation, which is a no-go since it could deadlock with other paths - atomic commits can produce a dma_fence. This patch here highlights that with the new annotations, and apparently causes a lockdep splat if you go through the dirty rect paths (not sure if it also happens otherwise, Thomas can fill you in with the details). Can you pls take a look at this? I'm happy to help out with analyzing any lockdep splats. For actual fixes Thomas is better since I don't understand a lot of how drm/vmwgfx works internally. Cheers, Daniel On Thu, Jun 4, 2020 at 10:12 AM Daniel Vetter wrot= e: > > I need a canary in a ttm-based atomic driver to make sure the > dma_fence_begin/end_signalling annotations actually work. > > Cc: linux-media@vger.kernel.org > Cc: linaro-mm-sig@lists.linaro.org > Cc: linux-rdma@vger.kernel.org > Cc: amd-gfx@lists.freedesktop.org > Cc: intel-gfx@lists.freedesktop.org > Cc: Chris Wilson > Cc: Maarten Lankhorst > Cc: Christian K=C3=B6nig > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/= gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index bdba0bfd6df1..adabfa929f42 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -57,6 +57,7 @@ > > #include "ivsrcid/ivsrcid_vislands30.h" > > +#include > #include > #include > #include > @@ -7320,6 +7321,9 @@ static void amdgpu_dm_atomic_commit_tail(struct drm= _atomic_state *state) > struct drm_connector_state *old_con_state, *new_con_state; > struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; > int crtc_disable_count =3D 0; > + bool fence_cookie; > + > + fence_cookie =3D dma_fence_begin_signalling(); > > drm_atomic_helper_update_legacy_modeset_state(dev, state); > > @@ -7600,6 +7604,8 @@ static void amdgpu_dm_atomic_commit_tail(struct drm= _atomic_state *state) > /* Signal HW programming completion */ > drm_atomic_helper_commit_hw_done(state); > > + dma_fence_end_signalling(fence_cookie); > + > if (wait_for_vblank) > drm_atomic_helper_wait_for_flip_done(dev, state); > > -- > 2.26.2 > --=20 Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch