Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp18275074rwd; Tue, 27 Jun 2023 14:33:44 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6xcl1V7WJLMSap65P8kSYqatzFLsrxB3AcNR1yCaeJ43WE/pnft//7Pw8wnen7QOYcRZo1 X-Received: by 2002:a05:6402:1150:b0:518:6a99:cac3 with SMTP id g16-20020a056402115000b005186a99cac3mr20402290edw.31.1687901624591; Tue, 27 Jun 2023 14:33:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687901624; cv=none; d=google.com; s=arc-20160816; b=etVH5dVIfB1Xdg8GmgNyxujz+WIXPTionr8PoMPe/hesHOLirNXdA40ODq7IQ6+bxx PFeTZGOSaToVyJ4bR9URIatHcmwEJJdygBF12aOZRLAsaFJ0iz2Nejhj/d+5TEhVHuDW mxhPhO8hGdF8nykziGgnybZQ3kJOFg8iwkWLIdeEDdbZZl4F+2s3sF1JIxKJAlg2V8y+ TFfnXMHBPkcFCZ17YGrFXBoQ8vHKWcY7YbBsKhQh0WaKAJhsDHZ6wmukFeMUKQE3AdKX +K2GFVZGyH28zBSG1o2xTMYr0J18LVj3PgwGAZD9DPrE8QUlDlJooxdlySvLCMGUPOAW rX9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=3vhPCu53nxpX9E42A4ruWOxKwyzxqXGXKDJSyV2Vnpk=; fh=hSkWbTg/sPOp08JFiS7xUOpVjTx6rT4+KRetYYIRzAg=; b=clFusy9RRn2qd4J+90ihLnwBubfT0p4A8TLl1qlShULEjlcuPbd7hDbQXxLxRI1InZ JjIcXN2z4do46mOggRZDpvB8bsGbgK2IJPnMay49YTxOF5tMqDZggARfLPKWlNmJTviJ plOhFUHC6ibFGYCeXb5WjUktFB70WK0DRLXI3/1LQqx7hvFyezfWsc65tfLaxglOkzEO l8VxqpCBWQFTHexyqb0/q7e8tD3kYr6hcsVM3cN4Lp5IvzFtiaLsif4Qu20dAgwBaWcn eMoVZZISccFIpHeJbiwWg2izkVBOC/xSgnqYro2bgV+NdK5Sxc9kMg6LDCUS0Qr1W/y3 Rx2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@igalia.com header.s=20170329 header.b=esBYqXRa; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e5-20020a056402104500b0051a318aa40asi4059876edu.502.2023.06.27.14.33.20; Tue, 27 Jun 2023 14:33:44 -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=fail header.i=@igalia.com header.s=20170329 header.b=esBYqXRa; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229998AbjF0VSQ (ORCPT + 99 others); Tue, 27 Jun 2023 17:18:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34364 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjF0VSP (ORCPT ); Tue, 27 Jun 2023 17:18:15 -0400 Received: from fanzine2.igalia.com (fanzine2.igalia.com [213.97.179.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA522198E for ; Tue, 27 Jun 2023 14:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3vhPCu53nxpX9E42A4ruWOxKwyzxqXGXKDJSyV2Vnpk=; b=esBYqXRaJNsjQ7Zydh+R9urN/b Nx18p1tk8NSIfdccDDViIdi7Y4yI4IjhMdoC/pqWR3U4zCNfghH42qR9ZWLrZLWxQEl0eyXYVfr2T zRki6ceQ3fztKcCmjzZB+9Al4YmhFZEhVTGMysYYU5Bed4DbqOfKcn6qscLRLE9/YsUBu5HzXMGT7 DiDXo3saZGh+Tt90xcLek0eYfnUzWIf9gy+9Jzi5LEBWQGodVo/i70P9vt00nYyPDpefIeFUTWoO1 fKWUK/RrFuYDqubMpbg+YzkDjDBZDK4L/iKZ4+0rO/mR3OdTXi0y6py6yweLj/ZPuvy779Y57jAd6 7knoxslw==; Received: from [179.113.218.86] (helo=[192.168.1.111]) by fanzine2.igalia.com with esmtpsa (Cipher TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_128_GCM:128) (Exim) id 1qEG4D-004r3K-UH; Tue, 27 Jun 2023 23:17:42 +0200 Message-ID: Date: Tue, 27 Jun 2023 18:17:35 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations To: =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: pierre-eric.pelloux-prayer@amd.com, Randy Dunlap , Daniel Vetter , =?UTF-8?B?J01hcmVrIE9sxaHDoWsn?= , =?UTF-8?Q?Michel_D=c3=a4nzer?= , Simon Ser , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, =?UTF-8?Q?Timur_Krist=c3=b3f?= , amd-gfx@lists.freedesktop.org, Pekka Paalanen , Daniel Stone , Rob Clark , Samuel Pitoiset , kernel-dev@igalia.com, Bas Nieuwenhuizen , alexander.deucher@amd.com, Pekka Paalanen , Dave Airlie , christian.koenig@amd.com References: <20230627132323.115440-1-andrealmeid@igalia.com> <1dbeb507-3f18-1b5d-37be-fcfd60a1c0d4@gmail.com> Content-Language: en-US From: =?UTF-8?Q?Andr=c3=a9_Almeida?= In-Reply-To: <1dbeb507-3f18-1b5d-37be-fcfd60a1c0d4@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 Em 27/06/2023 14:47, Christian König escreveu: > Am 27.06.23 um 15:23 schrieb André Almeida: >> Create a section that specifies how to deal with DRM device resets for >> kernel and userspace drivers. >> >> Acked-by: Pekka Paalanen >> Signed-off-by: André Almeida >> --- >> >> v4: >> https://lore.kernel.org/lkml/20230626183347.55118-1-andrealmeid@igalia.com/ >> >> Changes: >>   - Grammar fixes (Randy) >> >>   Documentation/gpu/drm-uapi.rst | 68 ++++++++++++++++++++++++++++++++++ >>   1 file changed, 68 insertions(+) >> >> diff --git a/Documentation/gpu/drm-uapi.rst >> b/Documentation/gpu/drm-uapi.rst >> index 65fb3036a580..3cbffa25ed93 100644 >> --- a/Documentation/gpu/drm-uapi.rst >> +++ b/Documentation/gpu/drm-uapi.rst >> @@ -285,6 +285,74 @@ for GPU1 and GPU2 from different vendors, and a >> third handler for >>   mmapped regular files. Threads cause additional pain with signal >>   handling as well. >> +Device reset >> +============ >> + >> +The GPU stack is really complex and is prone to errors, from hardware >> bugs, >> +faulty applications and everything in between the many layers. Some >> errors >> +require resetting the device in order to make the device usable >> again. This >> +sections describes the expectations for DRM and usermode drivers when a >> +device resets and how to propagate the reset status. >> + >> +Kernel Mode Driver >> +------------------ >> + >> +The KMD is responsible for checking if the device needs a reset, and >> to perform >> +it as needed. Usually a hang is detected when a job gets stuck >> executing. KMD >> +should keep track of resets, because userspace can query any time >> about the >> +reset stats for an specific context. > > Maybe drop the part "for a specific context". Essentially the reset > query could use global counters instead and we won't need the context > any more here. > Right, I wrote like this to reflect how it's currently implemented. If follow correctly what you meant, KMD could always notify the global count for UMD, and we would move to the UMD the responsibility to manage the reset counters, right? This would also simplify my DRM_IOCTL_GET_RESET proposal. I'll apply your suggestion to the next doc version. > Apart from that this sounds good to me, feel free to add my rb. > > Regards, > Christian. > >