On Mon, 11 Sep 2023 19:16:08 -0700 Matthew Brost <matthew.brost@xxxxxxxxx> wrote: > Add generic schedule message interface which sends messages to backend > from the drm_gpu_scheduler main submission thread. The idea is some of > these messages modify some state in drm_sched_entity which is also > modified during submission. By scheduling these messages and submission > in the same thread their is not race changing states in > drm_sched_entity. > > This interface will be used in Xe, new Intel GPU driver, to cleanup, > suspend, resume, and change scheduling properties of a drm_sched_entity. > > The interface is designed to be generic and extendable with only the > backend understanding the messages. I didn't follow the previous discussions closely enough, but it seemed to me that the whole point of this 'ordered-wq for scheduler' approach was so you could interleave your driver-specific work items in the processing without changing the core. This messaging system looks like something that could/should be entirely driver-specific to me, and I'm not convinced this thin 'work -> generic_message_callback' layer is worth it. You can simply have your own xe_msg_process work, and a xe_msg_send helper that schedules this work. Assuming other drivers need this messaging API, they'll probably have their own message ids and payloads, and the automation done here is simple enough that it can be duplicated. That's just my personal opinion, of course, and if others see this message interface as valuable, I fine with it.
