Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Em 27/06/2023 18:17, André Almeida escreveu:
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 <pekka.paalanen@xxxxxxxxxxxxx>
Signed-off-by: André Almeida <andrealmeid@xxxxxxxxxx>
---

v4: https://lore.kernel.org/lkml/20230626183347.55118-1-andrealmeid@xxxxxxxxxx/

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.


Actually, if we drop the context identifier we would lose the ability to track which is the guilty context. Vulkan API doesn't seem to care about this, but OpenGL does.

Apart from that this sounds good to me, feel free to add my rb.

Regards,
Christian.





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux