On Fri, 31 Jan 2020 16:33:55 +0100, Chris Wilson
<ch...@chris-wilson.co.uk> wrote:
Quoting Michal Wajdeczko (2020-01-31 14:58:34)
While we are always using CT "send" buffer to send request messages
to GuC, we usually don't ask GuC to use CT "receive" buffer to send
back response messages, since almost all returned data can fit into
reserved bits in status dword inside CT descriptor. However, relying
on data modifications inside CT descriptor requires use of mutex to
allow only single CT request in flight, until we read back that status
dword from the CT descriptor.
Q. do we need the same lock for ct_read() and ct_write()?
No. And additionally I missed that ct_read() was already implicitly locked
with gt->irq_lock by gen11_gt_irq_handler and with i915->irq_lock by
guc_enable_communication() - need to fix that too ;(
Could ct_read() use a lock-free ringbuffer, and then if I've read it
right, you wouldn't have any overlapping spinlock between the interrupt
handler and the rest (thus avoiding the interrupt-off).
Not sure if can go lock-free with two callers, will look for gt->irq_lock
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
