> You can extend ioctl structs safely. When older userspace passes theirs
> in, it has the shorter length encoded in the cmd. The kernel allocates
> the newest version's space, copies in the shorter struct, and
> zero-extends the rest.
Understood, thank you!
__
Alyssa Rosenzweig writes:
>> @@ -55,6 +63,15 @@ struct drm_panfrost_submit {
>>
>> /** A combination of PANFROST_JD_REQ_* */
>> __u32 requirements;
>> +
>> +/** Pointer to a u32 array of perfmons that should be attached to the
>> job. */
>> +__u64 perfmon_handles;
>> +
>> +
> memcmp() does not account for the case where 2 jobs contain exactly the
> same perfmons but in a different order. This being said, it's rather
> unlikely to happen, so maybe we can accept the perf penalty for that
> case.
If you say so!
> Yes, all numbers above 0xfff are bifrost GPUs. I'll add
> + /*
> + * In v4 HW we have one tiler per core group, with the number
> + * of core groups being equal to the number of L2 caches. Other
> + * HW versions just have one tiler and the number of L2 caches
> + * can be extracted from the mem_features field.
> + */
Norma
On Thu, 4 Apr 2019 08:41:29 -0700
Alyssa Rosenzweig wrote:
> > +/*
> > + * Returns true if the 2 jobs have exactly the same perfcnt context, false
> > + * otherwise.
> > + */
> > +static bool panfrost_perfcnt_job_ctx_cmp(struct panfrost_perfcnt_job_ctx
> > *a,
> > +
