On Fri, 31 Jan 2020 17:40:12 +0100, Matthew Brost
<matthew.br...@intel.com> wrote:
On Fri, Jan 31, 2020 at 03:33:55PM +0000, Chris Wilson 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()?
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).
-Chris
Agree with Chris, it would nice if ct_read() didn't need a lock. At a
minimum I
think it needs a different lock than the write path.
two options:
1) reuse gt->irq_lock for ct_read() and use ct->lock for ct_write()
2) define lock as part of ct->ctbs[] for dedicated use by ct_read()/write()
I guess 2 is clearer
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
