| Message ID | 1446672017-24497-28-git-send-email-ville.syrjala@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Nov 04, 2015 at 11:20:15PM +0200, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > No idea if we might want these. Perhaps there is a "keep your paws off > my GPU" bit in there somewhere to avoid BIOS crap? Hmm. "These registers are used as scratch pad data storage space and have no direct effect on hardware operation. The use of these registers is defined by the software architecture." Not sure. But I do know that some of that scratch space was repurposed for use by the hardware (but the ones I know about don't need to be restored). Do you have anything more definite than a hunch? If you have a good reason, Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (as in I checked that those registers do exist as a 36x32bit block) -Chris
On Fri, Nov 06, 2015 at 01:14:33PM +0000, Chris Wilson wrote: > On Wed, Nov 04, 2015 at 11:20:15PM +0200, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > No idea if we might want these. Perhaps there is a "keep your paws off > > my GPU" bit in there somewhere to avoid BIOS crap? > > Hmm. "These registers are used as scratch pad data storage space and > have no direct effect on hardware operation. The use of these > registers is defined by the software architecture." > > Not sure. But I do know that some of that scratch space was repurposed > for use by the hardware (but the ones I know about don't need to be > restored). > > Do you have anything more definite than a hunch? If you have a good reason, > Acked-by: Chris Wilson <chris@chris-wilson.co.uk> > (as in I checked that those registers do exist as a 36x32bit block) Basically I have nothing. I have pondered about what the BIOS might be doing with these, and there are certainly interesting bits in there (eg. "driver loaded", "driver does display switch instead of bios", "choose between apm vs. acpi vs. acpi+extension", etc.). So I've been thinking that maybe we could get rid of the lid notify stuff if we set the right bit, and/or maybe find something for the D3 vs. hibernate issue as well. I think there was some bit about GTT restore too. Another interesting thing I just noticed is that according to some docs VLV/CHV might have both the GMCH registers, and the ILK+ registers (just housed in the Gunit on VLV/CHV). No real idea which set of registers those platforms would actually use.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index cfac5c3..88ab00b 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1016,9 +1016,16 @@ struct i915_suspend_saved_registers { u32 saveFBC_CONTROL; u32 saveCACHE_MODE_0; u32 saveMI_ARB_STATE; - u32 saveSWF0[16]; - u32 saveSWF1[16]; - u32 saveSWF3[3]; + union { + struct { + u32 saveSWF0[16]; + u32 saveSWF1[16]; + u32 saveSWF3[3]; + }; + struct { + u32 saveSWF_ILK[36]; + }; + }; uint64_t saveFENCE[I915_MAX_NUM_FENCES]; u32 savePCH_PORT_HOTPLUG; u16 saveGCDGMBUS; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 2478267..96fd0f5 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -5030,6 +5030,7 @@ enum skl_disp_power_wells { #define SWF0(i) (dev_priv->info.display_mmio_offset + 0x70410 + (i) * 4) #define SWF1(i) (dev_priv->info.display_mmio_offset + 0x71410 + (i) * 4) #define SWF3(i) (dev_priv->info.display_mmio_offset + 0x72414 + (i) * 4) +#define SWF_ILK(i) (0x4F000 + (i) * 4) /* Pipe B */ #define _PIPEBDSL (dev_priv->info.display_mmio_offset + 0x71000) diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c index 2d91821..297afe9 100644 --- a/drivers/gpu/drm/i915/i915_suspend.c +++ b/drivers/gpu/drm/i915/i915_suspend.c @@ -139,6 +139,9 @@ int i915_save_state(struct drm_device *dev) } for (i = 0; i < 3; i++) dev_priv->regfile.saveSWF3[i] = I915_READ(SWF3(i)); + } else { + for (i = 0; i < 36; i++) + dev_priv->regfile.saveSWF_ILK[i] = I915_READ(SWF_ILK(i)); } mutex_unlock(&dev->struct_mutex); @@ -186,6 +189,9 @@ int i915_restore_state(struct drm_device *dev) } for (i = 0; i < 3; i++) I915_WRITE(SWF3(i), dev_priv->regfile.saveSWF3[i]); + } else { + for (i = 0; i < 36; i++) + I915_WRITE(SWF_ILK(i), dev_priv->regfile.saveSWF_ILK[i]); } mutex_unlock(&dev->struct_mutex);