[Intel-xe] [PATCH 01/21] drm/xe/uapi: Introduce OA (observability architecture) uapi

[Dixit, Ashutosh]

On Tue, 19 Sep 2023 09:10:29 -0700, Ashutosh Dixit wrote:
>

Hi Umesh,

> +struct drm_xe_oa_record_header {
> +	__u32 type;
> +	__u16 pad;
> +	__u16 size;
> +};
> +
> +enum drm_xe_oa_record_type {
> +	/**
> +	 * Samples are the work horse record type whose contents are
> +	 * extensible and defined when opening an xe oa stream based on the
> +	 * given properties.
> +	 *
> +	 * Boolean properties following the naming convention
> +	 * DRM_XE_OA_SAMPLE_xyz_PROP request the inclusion of 'xyz' data in
> +	 * every sample.
> +	 *
> +	 * The order of these sample properties given by userspace has no
> +	 * affect on the ordering of data within a sample. The order is
> +	 * documented here.
> +	 *
> +	 * struct {
> +	 *     struct drm_xe_oa_record_header header;
> +	 *
> +	 *     { u32 oa_report[]; } && DRM_XE_OA_PROP_SAMPLE_OA
> +	 * };
> +	 */
> +	DRM_XE_OA_RECORD_SAMPLE = 1,
> +
> +	/**
> +	 * Indicates that one or more OA reports were not written by the
> +	 * hardware. This can happen for example if an MI_REPORT_PERF_COUNT
> +	 * command collides with periodic sampling - which would be more likely
> +	 * at higher sampling frequencies.
> +	 */
> +	DRM_XE_OA_RECORD_OA_REPORT_LOST = 2,
> +
> +	/**
> +	 * An error occurred that resulted in all pending OA reports being lost.
> +	 */
> +	DRM_XE_OA_RECORD_OA_BUFFER_LOST = 3,
> +
> +	DRM_XE_OA_RECORD_MAX /* non-ABI */

Rather than maintain these statuses in the uapi, how about just returning
oa_status register (from which these statuses come) directly to
userland. Basically the 32 bit type can directly be the oa_status register
directly. We can steal bit 31 (or something like that) to indicate a real
SAMPLE vs a status header. This way only bit 31 gets into
xe_drm.h. Thoughts?

Thanks.
--
Ashutosh