[Intel-gfx] [PATCH] drm/i915/guc: Stop using mutex while sending CTB messages

[Michal Wajdeczko]

On Fri, 31 Jan 2020 17:40:12 +0100, Matthew Brost  
<matthew.brost at 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