On 11/09/2015 02:15 AM, Chris Wilson wrote:
On Fri, Nov 06, 2015 at 03:18:37PM -0800, Yu Dai wrote:
>
>
> On 11/06/2015 02:07 PM, Chris Wilson wrote:
> >On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> >> From: Alex Dai
> >>
> >> We keep a copy of GuC fw in a GEM obj. Howeve
On Fri, Nov 06, 2015 at 03:18:37PM -0800, Yu Dai wrote:
>
>
> On 11/06/2015 02:07 PM, Chris Wilson wrote:
> >On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> >> From: Alex Dai
> >>
> >> We keep a copy of GuC fw in a GEM obj. However its content is lost
> >> if the GEM obj is e
On 11/06/2015 02:07 PM, Chris Wilson wrote:
On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> We keep a copy of GuC fw in a GEM obj. However its content is lost
> if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
> fw loading during GPU rese
On Fri, Nov 06, 2015 at 01:55:27PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> We keep a copy of GuC fw in a GEM obj. However its content is lost
> if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
> fw loading during GPU reset will fail.
No, it's not. The bug is in sg_co
From: Alex Dai
We keep a copy of GuC fw in a GEM obj. However its content is lost
if the GEM obj is evicted (igt/gem_evict_*). Therefore, the later
fw loading during GPU reset will fail.
Now we keep the copy in a memory block rather than a GEM objet.
During fw loading, we will wrap up a GEM obj
