On 3/9/2022 8:47 AM, Simon Ser wrote:
Hi,
Maybe it would be a good idea to state the intended use-case in the
commit message?
It was added in the second patch, but yeah, it makes more sense to add a
cover-letter probably.
And explain why the current (driver-specific IIRC) APIs
aren't enough?
As you mentioned, we also started with a driver specific API, and then
realized that most of the drivers can benefit from this infrastructure,
as most of them would be more or less interested in the similar
information.
Since this introduces new uAPI, can you point to a user-space patch
which uses the new uAPI? See this link for more info on DRM user-space
requirements:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdri.freedesktop.org%2Fdocs%2Fdrm%2Fgpu%2Fdrm-uapi.html%23open-source-userspace-requirements&data=04%7C01%7Cshashank.sharma%40amd.com%7C85e8e40c84524f3272e908da01a11b1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637824088716047386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BMTzBIfl3FGHdAv%2BSx%2F83a86x8eksbOhdQVqdrJ2Rq0%3D&reserved=0
The userspace work is in progress, this was to get a general feedback
from the community and the interest.
Please use drm_dbg_* and drm_warn_* helpers instead of DRM_DEBUG and
DRM_WARN. This allows identifying on which device the uevent happens.
Well, I don't want to break the consistency across the file, as other
functions seems to be using DRM_DEBUG family of prints.
On Tuesday, March 8th, 2022 at 19:04, Shashank Sharma
<contactshashanksha...@gmail.com> wrote:
+void drm_sysfs_reset_event(struct drm_device *dev, struct drm_reset_event
*reset_info)
reset_info can be const.
Sure.
- Shashank
