Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-09-28 Thread Oscar Mateo
On 09/28/2017 01:56 PM, Oscar Mateo wrote: On 09/28/2017 02:46 AM, Chris Wilson wrote: Stealing the thread for another gem_workarounds conundrum. After a reset, we lose the RING_FORCE_TO_NONPRIV registers. If they where in the context image as we presumed, the values would be retained and

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-09-28 Thread Oscar Mateo
On 09/28/2017 02:46 AM, Chris Wilson wrote: Stealing the thread for another gem_workarounds conundrum. After a reset, we lose the RING_FORCE_TO_NONPRIV registers. If they where in the context image as we presumed, the values would be retained and they can be read back from before reset, so

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-09-28 Thread Chris Wilson
Stealing the thread for another gem_workarounds conundrum. After a reset, we lose the RING_FORCE_TO_NONPRIV registers. If they where in the context image as we presumed, the values would be retained and they can be read back from before reset, so it's not the case of write-only register! So are

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-09-27 Thread Chris Wilson
Quoting Oscar Mateo (2017-09-27 18:37:07) > > > On 09/27/2017 03:37 AM, Mika Kuoppala wrote: > > Chris Wilson writes: > > > >> Quoting Rodrigo Vivi (2017-08-23 00:27:15) > >>> To avoid a potential hang condition with TLB invalidation > >>> we need to enable masked bit

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-09-27 Thread Oscar Mateo
On 09/27/2017 03:37 AM, Mika Kuoppala wrote: Chris Wilson writes: Quoting Rodrigo Vivi (2017-08-23 00:27:15) To avoid a potential hang condition with TLB invalidation we need to enable masked bit 5 of MMIO 0xE5F0 at boot. Same workaround was in place for previous

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-09-27 Thread Mika Kuoppala
Chris Wilson writes: > Quoting Rodrigo Vivi (2017-08-23 00:27:15) >> To avoid a potential hang condition with TLB invalidation >> we need to enable masked bit 5 of MMIO 0xE5F0 at boot. >> >> Same workaround was in place for previous platforms, >> but the change for CNL

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-09-27 Thread Chris Wilson
Quoting Rodrigo Vivi (2017-08-23 00:27:15) > To avoid a potential hang condition with TLB invalidation > we need to enable masked bit 5 of MMIO 0xE5F0 at boot. > > Same workaround was in place for previous platforms, > but the change for CNL is more on the register offset. > But also BSpec

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-08-23 Thread Rodrigo Vivi
patch merged to dinq. thanks for the review and suggestion. On Wed, Aug 23, 2017 at 1:35 PM, Rodrigo Vivi wrote: > To avoid a potential hang condition with TLB invalidation > we need to enable masked bit 5 of MMIO 0xE5F0 at boot. > > Same workaround was in place for

[Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-08-23 Thread Rodrigo Vivi
To avoid a potential hang condition with TLB invalidation we need to enable masked bit 5 of MMIO 0xE5F0 at boot. Same workaround was in place for previous platforms, but the register offset has changed for CNL. But also BSpec doesn't mention the bit 15 as set on gen9 platforms and mark bit as

Re: [Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-08-23 Thread Oscar Mateo
On 08/22/2017 04:27 PM, Rodrigo Vivi wrote: To avoid a potential hang condition with TLB invalidation we need to enable masked bit 5 of MMIO 0xE5F0 at boot. Same workaround was in place for previous platforms, but the change for CNL is more on the register offset. "but the register offset

[Intel-gfx] [PATCH] drm/i915/cnl: WaForceContextSaveRestoreNonCoherent

2017-08-22 Thread Rodrigo Vivi
To avoid a potential hang condition with TLB invalidation we need to enable masked bit 5 of MMIO 0xE5F0 at boot. Same workaround was in place for previous platforms, but the change for CNL is more on the register offset. But also BSpec doesn't mention the bit 15 as set on gen9 platforms and mark