On Wed, May 04, 2016 at 12:35:09PM +0100, Dave Gordon wrote:
>On 29/04/2016 09:49, Chris Wilson wrote:
>
> On Fri, Apr 29, 2016 at 09:36:37AM +0100, Tvrtko Ursulin wrote:
>
> On 28/04/16 17:24, Chris Wilson wrote:
>
> With the introduction of a distinct engine->id vs the hardware id, we n
On 29/04/2016 09:49, Chris Wilson wrote:
On Fri, Apr 29, 2016 at 09:36:37AM +0100, Tvrtko Ursulin wrote:
On 28/04/16 17:24, Chris Wilson wrote:
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a
On Fri, Apr 29, 2016 at 09:36:37AM +0100, Tvrtko Ursulin wrote:
>
> On 28/04/16 17:24, Chris Wilson wrote:
> >With the introduction of a distinct engine->id vs the hardware id, we need
> >to fix up the value we use for selecting the target engine when signaling
> >a semaphore. Note that these valu
On 28/04/16 17:24, Chris Wilson wrote:
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.
So I broke something more with the
With the introduction of a distinct engine->id vs the hardware id, we need
to fix up the value we use for selecting the target engine when signaling
a semaphore. Note that these values can be merged with engine->guc_id.
Fixes: de1add360522c876c25ef2ab1c94bdb509ab
Signed-off-by: Chris Wilson
C