Hi Am 21.09.23 um 10:23 schrieb Javier Martinez Canillas: [...]
Both options have cons and pros (e.g: quickly figuring out to what struct callback is associated as you said), but the reason I posted this patch is to attempt making the driver more consistent with the rest of the drivers.Perhaps the real question is whether the structures should have "helper" in their name in the first place?Indeed. I never fully understood why the DRM/KMS objects callbacks are split in drm_$object_funcs and drm_$object_helper_funcs structs. AFAIU is because the former is the minimum required and the latter is to add additional custom behavior ?
The drm_<object>_funcs is an interface that is being called from DRM userspace/clients/ioctls. It's the interface that we present to the outside world. Implement them in each hardware's driver.
But most graphics hardware is similar to each other. The differences are in the way how things are done, but not so much what is being done. Hence, a good number of drm_$object_funcs can be provided in hardware-independent helpers. drm_object_helper_funcs are callback for these helpers. In the places where the helpers need the driver to do something with the hardware, they refer to _helper_funcs.
IIRC, there are a few outliers, but that's the overall idea. Best regards Thomas
I read this section of the documentation but still isn't clear to me: https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.htmlJust my 2€c as a DRM novice...
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg)
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
