[PATCH v2 4/7] drm/panfrost: Add the ability to create submit queues
Boris Brezillon
boris.brezillon at collabora.com
Fri Jul 2 11:01:42 UTC 2021
On Fri, 2 Jul 2021 11:58:34 +0100
Steven Price <steven.price at arm.com> wrote:
> On 02/07/2021 11:52, Boris Brezillon wrote:
> > On Fri, 2 Jul 2021 11:08:58 +0100
> > Steven Price <steven.price at arm.com> wrote:
> >
> >> On 01/07/2021 10:12, Boris Brezillon wrote:
> >>> Needed to keep VkQueues isolated from each other.
> >>
> >> One more comment I noticed when I tried this out:
> >>
> >> [...]
> >>> +struct panfrost_submitqueue *
> >>> +panfrost_submitqueue_create(struct panfrost_file_priv *ctx,
> >>> + enum panfrost_submitqueue_priority priority,
> >>> + u32 flags)
> >>> +{
> >>> + struct panfrost_submitqueue *queue;
> >>> + enum drm_sched_priority sched_prio;
> >>> + int ret, i;
> >>> +
> >>> + if (flags || priority >= PANFROST_SUBMITQUEUE_PRIORITY_COUNT)
> >>> + return ERR_PTR(-EINVAL);
> >>> +
> >>> + queue = kzalloc(sizeof(*queue), GFP_KERNEL);
> >>> + if (!queue)
> >>> + return ERR_PTR(-ENOMEM);
> >>> +
> >>> + queue->pfdev = ctx->pfdev;
> >>> + sched_prio = to_sched_prio(priority);
> >>> + for (i = 0; i < NUM_JOB_SLOTS; i++) {
> >>> + struct drm_gpu_scheduler *sched;
> >>> +
> >>> + sched = panfrost_job_get_sched(ctx->pfdev, i);
> >>> + ret = drm_sched_entity_init(&queue->sched_entity[i],
> >>> + sched_prio, &sched, 1, NULL);
> >>> + if (ret)
> >>> + break;
> >>> + }
> >>> +
> >>> + if (ret) {
> >>> + for (i--; i >= 0; i--)
> >>> + drm_sched_entity_destroy(&queue->sched_entity[i]);
> >>> +
> >>> + return ERR_PTR(ret);
> >>> + }
> >>> +
> >>> + kref_init(&queue->refcount);
> >>> + idr_lock(&ctx->queues);
> >>> + ret = idr_alloc(&ctx->queues, queue, 0, INT_MAX, GFP_KERNEL);
> >>
> >> This makes lockdep complain. idr_lock() is a spinlock and GFP_KERNEL can
> >> sleep. So either we need to bring our own mutex here or not use GFP_KERNEL.
> >>
> >
> > Ouch! I wonder why I don't see that (I have lockdep enabled, and the
> > igt tests should have exercised this path).
>
> Actually I'm not sure it technically lockdep - have you got
> CONFIG_DEBUG_ATOMIC_SLEEP set?
Nope, I was missing that one :-/.
More information about the dri-devel
mailing list