On Mon, 17 Aug 2026 16:21:25 +0100 Steven Price <[email protected]> wrote:
> > + /** > > + * @events_lock: Lock taken when processing events. > > + * > > + * This also needs to be taken when csg_slots are updated, to make sure > > + * the event processing logic doesn't touch groups that have left the > > CSG > > + * slot. > > + */ > > + spinlock_t events_lock; > > + > > /** > > * @csg_slots: FW command stream group slots. > > + * > > + * Updates to these slots must happen with both panthor_scheduler::lock > > and > > + * panthor_scheduler::events_lock held. As a result, reads can happen > > with > > + * either of these locks held. > > Technically this isn't quite true - priority can be changed with only > sched->lock. Perhaps the following would be slightly more accurate wording? > > * Updates to the group binding must happen with both > * panthor_scheduler::lock and panthor_scheduler::events_lock held. > * The group binding may therefore be read while holding either lock. > * Other slot fields are protected by panthor_scheduler::lock. I'll go for your suggestion in v7.
