On Mon, Jul 12, 2021 at 1:01 PM Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > > This is a very confusingly named function, because not just does it > init an object, it arms it and provides a point of no return for > pushing a job into the scheduler. It would be nice if that's a bit > clearer in the interface. > > But the real reason is that I want to push the dependency tracking > helpers into the scheduler code, and that means drm_sched_job_init > must be called a lot earlier, without arming the job. > > v2: > - don't change .gitignore (Steven) > - don't forget v3d (Emma) > > v3: Emma noticed that I leak the memory allocated in > drm_sched_job_init if we bail out before the point of no return in > subsequent driver patches. To be able to fix this change > drm_sched_job_cleanup() so it can handle being called both before and > after drm_sched_job_arm(). > > Also improve the kerneldoc for this. > > v4: > - Fix the drm_sched_job_cleanup logic, I inverted the booleans, as > usual (Melissa) > > - Christian pointed out that drm_sched_entity_select_rq() also needs > to be moved into drm_sched_job_arm, which made me realize that the > job->id definitely needs to be moved too. > > Shuffle things to fit between job_init and job_arm. > > v5: > Reshuffle the split between init/arm once more, amdgpu abuses > drm_sched.ready to signal gpu reset failures. Also document this > somewhat. (Christian) Ack from me for the changes I was Cced on. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx