On Thu, Sep 10, 2020 at 12:52:27PM +0300, Jani Nikula wrote:
> Logically part of the display restore.
>
> Note: This has been in place since the introduction of gmbus
> support. The gmbus code also does the resets before transfers. Is this
> really needed, or a historical accident?
I suspect we could just remove this one.
Either way, this is display stuff so the move makes sense.
Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
>
> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx>
> ---
> drivers/gpu/drm/i915/i915_suspend.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_suspend.c b/drivers/gpu/drm/i915/i915_suspend.c
> index 4a93247942b7..09026c4db7d0 100644
> --- a/drivers/gpu/drm/i915/i915_suspend.c
> +++ b/drivers/gpu/drm/i915/i915_suspend.c
> @@ -69,6 +69,8 @@ static void i915_restore_display(struct drm_i915_private *dev_priv)
> I915_WRITE(FBC_CONTROL, dev_priv->regfile.saveFBC_CONTROL);
>
> intel_vga_redisable(dev_priv);
> +
> + intel_gmbus_reset(dev_priv);
> }
>
> int i915_save_state(struct drm_i915_private *dev_priv)
> @@ -141,7 +143,5 @@ int i915_restore_state(struct drm_i915_private *dev_priv)
> I915_WRITE(SWF3(i), dev_priv->regfile.saveSWF3[i]);
> }
Sidenote: I think the ^ scratch registers are also part of the display
block, so could probably move those too. The other option would be to
try to nuke that stuff entirely since I don't think anyone knows
whether it actually does something useful.
If we do move/nuke this then I think afte my earlier
MI_ARB_STATE/CACHE_MODE_0 nuke patches i915_{save,restore}_state() actually
just become pointless wrappers for i915_{save,restore}_display().
>
> - intel_gmbus_reset(dev_priv);
> -
> return 0;
> }
> --
> 2.20.1
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
