Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4008116imw; Mon, 11 Jul 2022 22:47:24 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tune8+ejclG8dc+NgTt2bmDnC+SanAzOZc5OFaiIHwf7ivxChObG9lQWYke8IwSh3PXIZd X-Received: by 2002:a17:902:e945:b0:16a:1c41:f66 with SMTP id b5-20020a170902e94500b0016a1c410f66mr22099865pll.129.1657604844396; Mon, 11 Jul 2022 22:47:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657604844; cv=none; d=google.com; s=arc-20160816; b=XWa8dOcrLrPWHKKcBG68oaDSPUqvYqTzH2lYNYBpCkCrg8+LDRe4COWWbSaM7ohSZO e4zFcrJEnJvH2ar89oR59DW7InKz/Ng0AVzOWNXq+JtbzWyBSCBF7+MzIpgHg+dKflRX 0D8kWs3AvDQDx/CYtXHNZ9OH9rqqiItodzo0bLvsG0vkLm4pEB+WeDSHKCcWJRM3j7V1 C0dx9c4U8o83p4nHODm4iMNaaGD0NRlQCmKuWoAJrNIXRpuAv7qnAO+waMhG38JRjwXY lqHY017GzU0ndDdqYyTntFxWf5e7mYjlv4R3ZSdYmMxttFKsyvmoFEX6Zm12fERxp8SH 7utA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=Io6RTZE60SvPtzfl8Dwm+AesX4Q9CRLNrTuqz3l+qg0=; b=WS2jqx0h94BPqpGATXwg/vnoW06Nz90PH47zsgyZ+3p191wzMi3wEat8QHcCvCpBY3 c8kuMzcKT5sPZnQMhJHSkbhbXpzPHJ0HlzIul8+K2SkFDkBlNSk1cLlqYVNaRjYI5Sh8 6KdXav7bGdRpt2n9r4IWP8868kHDqQchyDnNPxQLlwwNMP3n9oWEuKSHNQ28OHKoxJH9 o9hbfRpwan5tocIzXrDkE3QxB1ChHT9fyyPc+YeNPRDXOfYIKltsfpypto3VmK6v4TBM 68LF6SvVjnDaSPmaaZYwQqqTFL8tBtjoWDsr2AELWDPUo/XcFnZ/O93sba27ciXAfbG/ lXTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Qy2pxTID; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e4-20020a636904000000b004019c5f7652si11501842pgc.640.2022.07.11.22.47.11; Mon, 11 Jul 2022 22:47:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Qy2pxTID; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230040AbiGLF3T (ORCPT + 99 others); Tue, 12 Jul 2022 01:29:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbiGLF3R (ORCPT ); Tue, 12 Jul 2022 01:29:17 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0AC265C362 for ; Mon, 11 Jul 2022 22:29:16 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id 9-20020a1c0209000000b003a2dfdebe47so3300886wmc.3 for ; Mon, 11 Jul 2022 22:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Io6RTZE60SvPtzfl8Dwm+AesX4Q9CRLNrTuqz3l+qg0=; b=Qy2pxTIDUhMcsrUj9m9+hKPul6UxVB+rIB5xK1BX53iPqa4Kj/PE67MjJsTMNkepFs C3Hg07/0BMsdINcb+ODlseHtuCnrkWEnUAIzVa5/vjLkhOgjvcqTJcbNiaBNNVnBifB3 70dBirHYnACWQ/iJuTGwU9BSTP9l+HheELEyKL8skCvIx5OGrsqQjCBZYTVVAz96SI6g KCE1eqBa2i4GLSOStPR80aBR1Rwkwtej10rTgAf05wH3i6g7z5rIM99Uzu4AXZ3ByqHT KwvUC99jMfOJOYSJGhpl4IQjG/tXUKoZ+tDn9D+fCBV5ngFDEpttivrImYgsYTU6JdiU 0GuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Io6RTZE60SvPtzfl8Dwm+AesX4Q9CRLNrTuqz3l+qg0=; b=HdCyFBrTXtNoPH4PueDHHZcLmNXG2Mw0yNaU+tKeDBF1BUCv7KeHZmij8hArQCHK6+ 9EweTVZzbAq+jSDrd0z4DBb5z2JSvO/CZs4JDWciaS/VHTok+PqX6UhhA+kP9jci0m0e T2ukAUTLJClR00KNBWU/t2SEy/tJb0xU/ON1RbtTQ1if3Xz0O48r3Zc4OuOHd02bUFqh kaZf/WS+GdJ1mbCJwKnuEClc2veN6cpJ5FqrnmdAp3b8kr8aODLOgPD4bnOcshHNrNw2 5QmeSJpBWU2v5Ot61ppCuYDuu1k17qVbioB4C4KhdnkFm8KUm0QmvcD/kHmubQ1cD4IX v6UQ== X-Gm-Message-State: AJIora8hWovfQRUyDXaM9rnbqFohFhXIH+MfQ39GhLTAeArbIgV65VIS ROrqb8y4AP7DR22t7dxSJv3gwlRtnqqv+dfef79dbFsm3IpJ X-Received: by 2002:a7b:cb8e:0:b0:3a2:da0f:d8ae with SMTP id m14-20020a7bcb8e000000b003a2da0fd8aemr1847538wmi.23.1657603754324; Mon, 11 Jul 2022 22:29:14 -0700 (PDT) MIME-Version: 1.0 References: <20220712042258.293010-1-jstultz@google.com> In-Reply-To: <20220712042258.293010-1-jstultz@google.com> From: John Stultz Date: Mon, 11 Jul 2022 22:29:02 -0700 Message-ID: Subject: Re: [RFC][PATCH 1/3] drm: drm_syncobj: Add note in DOC about absolute timeout values To: LKML Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Jason Ekstrand , =?UTF-8?Q?Christian_K=C3=B6nig?= , Lionel Landwerlin , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 11, 2022 at 9:23 PM John Stultz wrote: > > After having to debug down through the kernel to figure out > why my _WAIT calls were always timing out, I realized its > an absolute timeout value instead of the more common relative > timeouts. > > This detail should be called out in the documentation, as while > the absolute value makes sense here, its not as common for timeout > values. > > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Thomas Zimmermann > Cc: Jason Ekstrand > Cc: Christian K=C3=B6nig > Cc: Lionel Landwerlin > Cc: Chunming Zhou > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel@lists.freedesktop.org > Signed-off-by: John Stultz > --- > drivers/gpu/drm/drm_syncobj.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.= c > index 7e48dcd1bee4..b84d842a1c21 100644 > --- a/drivers/gpu/drm/drm_syncobj.c > +++ b/drivers/gpu/drm/drm_syncobj.c > @@ -136,6 +136,10 @@ > * requirement is inherited from the wait-before-signal behavior require= d by > * the Vulkan timeline semaphore API. > * > + * It should be noted, that both &DRM_IOCTL_SYNCOBJ_WAIT and > + * &DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT takes an *absolute* CLOCK_MON= OTONIC Gah. That should be &DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT. I must have pasted in the wrong symbol. Fixed in my tree and I'll share v2 in a few days so I can get additional feedback. thanks -john