Re: [Intel-gfx] I messed up drm-intel-next-queued!

2018-12-24 Thread Vivi, Rodrigo
Hi Hans,

I’m traveling on vacation and didn’t bring my laptop. I believe Joonas and Jani 
are out this week as well.

I’m in favor of the forced push if you are sure you have the latest one with 
you.

In case you are not sure about the latest sabe head:
I had done a drm-intel-next tag last Friday... so worst case we could reator to 
the drive-update-date commit and ask around to see if someone had merged other 
patches after that and re-push.

Merry Christmas,
Rodrigo.


> On Dec 24, 2018, at 8:39 PM, Hans de Goede  wrote:
> 
> Hi,
> 
> Ugh, I just messed up drm-intel-next-queued big time.
> 
> I somehow rebased my work on top of drm-tip (I believe I did the rebase
> in the wrong dir) and then after running a bunch of tests I
> did a "dim push-branch drm-intel-next-queued" which pushed the
> patches I intended to push rebased on top of drm-tip
> pushing drm-tip to dinq :(
> 
> I'm so sorry about this.
> 
> I just checked my reflog and the last commit before me messing
> up is commit d4de753526f4d99f541f1b6ed1d963005c09700c
> ("drm/i915: Unwind failure on pinning the gen7 ppgtt")
> 
> I think we should do a forced push to restore this, but
> I don't want to make things worse, so hence this email.
> 
> Regards,
> 
> Hans
> 
> 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] I messed up drm-intel-next-queued!

2018-12-24 Thread Hans de Goede

Hi,

Ugh, I just messed up drm-intel-next-queued big time.

I somehow rebased my work on top of drm-tip (I believe I did the rebase
in the wrong dir) and then after running a bunch of tests I
did a "dim push-branch drm-intel-next-queued" which pushed the
patches I intended to push rebased on top of drm-tip
pushing drm-tip to dinq :(

I'm so sorry about this.

I just checked my reflog and the last commit before me messing
up is commit d4de753526f4d99f541f1b6ed1d963005c09700c
("drm/i915: Unwind failure on pinning the gen7 ppgtt")

I think we should do a forced push to restore this, but
I don't want to make things worse, so hence this email.

Regards,

Hans




___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: DDI: call intel_psr_ and _edp_drrs_enable() on pipe updates (v2)

2018-12-24 Thread Daniel Vetter
On Fri, Dec 21, 2018 at 8:42 PM Dhinakaran Pandiyan
 wrote:
>
> On Thu, 2018-12-20 at 15:13 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-12-20 at 09:10 -0800, Rodrigo Vivi wrote:
> > > On Thu, Dec 20, 2018 at 02:21:20PM +0100, Hans de Goede wrote:
> > > > Call intel_psr_enable() and intel_edp_drrs_enable() on pipe
> > > > updates
> > > > to make
> > > > sure that we enable PSR / DRRS (when applicable) on fastsets.
> >
> > I am probably missing something, doesn't intel_pipe_config_compare()
> > need to check for pipe_config->has_psr? And also read the hardware
> > PSR
> > state at boot?
> Answering my own question here, pipe_config_compare() returns true
> lacking a comparison for ->has_psr. And we assume the bios does not
> enable PSR, so no need to read the hardware state.

pipe_config_compare is also a validation tool, ensuring that all the
various fastboot (and other modeset) transitions work. Not reading out
& not comparing state reduces validation coverage. Some exceptions
apply, but generally they should be justified with other test
coverage, not with "it works without that". Everything is supposed to
work without the validation tools/tests :-)
-Daniel

> > > >
> > > > Note calling these functions when PSR / DRRS has already been
> > > > enabled is a
> > > > no-op, so it is safe to do this on every encoder->update_pipe
> > > > callback.
> > > >
> > > > Changes in v2:
> > > > -Merge the patches adding the intel_psr_enable() and
> > > > intel_edp_drrs_enable()
> > > >  calls into a single patch
> > > >
> > > > Reviewed-by: Maarten Lankhorst  > > > >
> > > > Signed-off-by: Hans de Goede 
> > >
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: José Roberto de Souza 
> > >
> > > Acked-by: Rodrigo Vivi 
> > >
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_ddi.c | 19 +++
> > > >  1 file changed, 19 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > index e3cc19e19199..fdf57f451b72 100644
> > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > @@ -3537,6 +3537,24 @@ static void intel_disable_ddi(struct
> > > > intel_encoder *encoder,
> > > >   intel_disable_ddi_dp(encoder, old_crtc_state,
> > > > old_conn_state);
> > > >  }
> > > >
> > > > +static void intel_ddi_update_pipe_dp(struct intel_encoder
> > > > *encoder,
> > > > +  const struct intel_crtc_state
> > > > *crtc_state,
> > > > +  const struct drm_connector_state
> > > > *conn_state)
> > > > +{
> > > > + struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > > > +
> > > > + intel_psr_enable(intel_dp, crtc_state);
> > > > + intel_edp_drrs_enable(intel_dp, crtc_state);
> > > > +}
> > > > +
> > > > +static void intel_ddi_update_pipe(struct intel_encoder *encoder,
> > > > +   const struct intel_crtc_state
> > > > *crtc_state,
> > > > +   const struct drm_connector_state
> > > > *conn_state)
> > > > +{
> > > > + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
> >
> > We could restrict this to eDP outputs as both PSR and DRRS are eDP
> > features.
> >
> > > > + intel_ddi_update_pipe_dp(encoder, crtc_state,
> > > > conn_state);
> > > > +}
> > > > +
> > > >  static void intel_ddi_set_fia_lane_count(struct intel_encoder
> > > > *encoder,
> > > >const struct intel_crtc_state
> > > > *pipe_config,
> > > >enum port port)
> > > > @@ -4169,6 +4187,7 @@ void intel_ddi_init(struct drm_i915_private
> > > > *dev_priv, enum port port)
> > > >   intel_encoder->pre_enable = intel_ddi_pre_enable;
> > > >   intel_encoder->disable = intel_disable_ddi;
> > > >   intel_encoder->post_disable = intel_ddi_post_disable;
> > > > + intel_encoder->update_pipe = intel_ddi_update_pipe;
> > > >   intel_encoder->get_hw_state = intel_ddi_get_hw_state;
> > > >   intel_encoder->get_config = intel_ddi_get_config;
> > > >   intel_encoder->suspend = intel_ddi_encoder_suspend;
> > > > --
> > > > 2.20.1
> > > >
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915/psr: simplify enable_psr handling

2018-12-24 Thread Daniel Vetter
On Fri, Dec 21, 2018 at 8:53 PM Ross Zwisler  wrote:
>
> On Fri, Dec 21, 2018 at 11:23:07AM -0800, Dhinakaran Pandiyan wrote:
> > On Fri, 2018-12-21 at 10:23 -0700, Ross Zwisler wrote:
> > > The following commit:
> > >
> > > commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be
> > > enabled.")
> > >
> > > added some code with no usable functionality.  Regardless of how the
> > > psr
> > > default is set up in the BDB_DRIVER_FEATURES section, if the
> > > enable_psr
> > > module parameter isn't specified it defaults to 0.
> > Right, that was intentional and the commit message even makes a note of
> > it
> > " Note: The feature currently remains disabled by default for all
> > platforms irrespective of what VBT says."
> >
> >
> > Anyway, we've enabled the feature by default now and the current code
> > should take into account the VBT flag if the module parameter is left
> > to a default value. Please check git://anongit.freedesktop.org/drm-tip
> > drm-tip.
>
> Fair enough.  It's a bad pattern to introduce dead code as a placeholder for
> some future work, though.  This code has been in the tree for three major
> kernel releases (v4.{18,19,20}) without providing any useful functionality.

Getting PSR enabled by default on at least a few platforms took years.
Insisting that we do not ever merge such code also doesn't work.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx