On 01/07/2019 01:35 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-01-07 21:28:48)
On 01/07/2019 10:50 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52)
Were you already
planning/working on something along the lines of the possible solution
mentione
Quoting Daniele Ceraolo Spurio (2019-01-07 21:28:48)
>
> On 01/07/2019 10:50 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52)
> >>
> >> Were you already
> >> planning/working on something along the lines of the possible solution
> >> mentioned in the commit message?
On 01/07/2019 10:50 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52)
On 01/02/2019 01:41 AM, Chris Wilson wrote:
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here i
Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52)
>
>
> On 01/02/2019 01:41 AM, Chris Wilson wrote:
> > The guc (and huc) currently inexcruitably depend on struct_mutex for
> > device reinitialisation from inside the reset, and indeed taking any
> > mutex here is verboten (as we must be able t
On 01/02/2019 01:41 AM, Chris Wilson wrote:
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering th
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving c
