On Sat, 2017-06-17 at 01:31 -0700, Dhinakaran Pandiyan wrote:
> On Friday, June 16, 2017 10:18:28 PM PDT Vivi, Rodrigo wrote:
> > On Fri, 2017-06-16 at 21:54 +0000, Navare, Manasi D wrote:
> >
> > > On Fri, 2017-06-16 at 21:26 +0000, Vivi, Rodrigo wrote:
> > >
> > > > On Fri, 2017-06-16 at 21:21 +0000, Pandiyan, Dhinakaran wrote:
> > > >
> > > > > On Fri, 2017-06-16 at 14:12 -0700, Manasi Navare wrote:
> > > > >
> > > > > > On Fri, Jun 16, 2017 at 08:58:25PM +0000, Pandiyan,
> > > > > > Dhinakaran
> > > > > > wrote:
> > > > > >
> > > > > > > On Fri, 2017-06-16 at 13:20 -0700, Rodrigo Vivi wrote:
> > > > > > >
> > > > > > > > This missing case could be reached out on missing type
> > > > > > > > or missing voltage.
> > > > > > >
> > > > > > >
> > > > > > > Should we even reach this far with a missing DDI type?
> > > > > > >
> > > > > > > -DK
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Yes it is possible that we get into this situation if
> > > > > > reading of the vccio voltage from PORT_COMP_DW3 returns a
> > > > > > garbage value due to some corruption
> > > > >
> > > > >
> > > > > MISSING_CASE already logs that.
> > > > >
> > > > >
> > > > > > or lets say the type is something that is not supported on
> > > > > > this platform.
> > > > > >
> > > > >
> > > > > But my question is, should we even be trying to program vswing
> > > > > without knowing the ddi type or for an invalid type?
> > > >
> > > >
> > > > we will reach the return; and avoid vswing programming.
> > > > And logs will give us some information of what failed during modeset.
> > > >
> > >
> > >
> > > Correct me if I am wrong, the only callers I could see are
> > > intel_dp_set_signal_levels() and intel_ddi_pre_enable_hdmi(). In
> > > both cases, the encoder type should have been set appropriately.
> > > My concern is that if we are seeing some other type, we should be
> > > handling that before calling cnl_ddi_vswing_program()
> >
> > this is why I didn't get the missing case on the type if/else ;)
> >
> > we should never reach that case, but in case there is the missing
> > case an extra debug message doesn't hurt...
> >
>
> We should not be writing to registers in the caller for invalid encoder types.
> And also debug log a bit sooner. How about?
I liked it, with one bikeshed below:
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/
> intel_ddi.c index db80938..81cdffb 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1858,14 +1858,18 @@ static void cnl_ddi_vswing_sequence(struct
> intel_encoder *encoder, u32 level)
> u32 val;
> int ln = 0;
>
> - if ((intel_dp) && (type == INTEL_OUTPUT_EDP || type ==
> INTEL_OUTPUT_DP)) {
> + if (intel_dp && (type == INTEL_OUTPUT_EDP || type ==
> + INTEL_OUTPUT_DP))
> {
> width = intel_dp->lane_count;
> rate = intel_dp->link_rate;
> - } else {
> + } else if (type == INTEL_OUTPUT_HDMI){
> width = 4;
> /* Rate is always < than 6GHz for HDMI */
> + } else {
> + DRM_DEBUG_KMS("vswing sequence undefined for encoder
> + type %d
> \n", type);
this should be
MISSING_CASE(type);
instead.
> + return;
> }
>
> +
> /*
> * 1. If port type is eDP or DP,
> * set PORT_PCS_DW1 cmnkeeper_enable to 1b,
>
> -DK
I think it is your patch now ;)
But let me know if you want me to do anything here..
I still think that there is a chance of running into a situation where the combination of the type
And the read vccio voltage is invalid and where we would need the debug print.
Also because I hate to sprinkle debug prints after a bug is filed would rather have it there
Making the debug easier. That is just my 2 cents....but if some people are too opinionated about
The debug print then go ahead remove it.
Manasi
>
> >
> > >
> > >
> > > But this debug message catches the condition where the type is
> > > correct but the type and corresponding vccio voltage Combination
> > > is wrong and the ddi tables are not present for that combination.
> > > I definitely think it is a good idea to have this Debug print here in the missing case.
> > > Manasi
> > >
> > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > > > So let's add a debug
> > > > > > > >
> > > > > > > > message to make our lives easier whenever this might happen.
> > > > > > > >
> > > > > > > > Cc: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx>
> > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx>
> > > > > > > > ---
> > > > > > > >
> > > > > > > > drivers/gpu/drm/i915/intel_ddi.c | 1 +
> > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > index e66947a..c96c8d0 100644
> > > > > > > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > > > > > > @@ -1802,6 +1802,7 @@ static void
> > > > > > > > cnl_ddi_vswing_program(struct drm_i915_private
> > > > > > > > *dev_priv,
> > > > > > >
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > if (ddi_translations == NULL) {
> > > > > > > >
> > > > > > > > + DRM_DEBUG_KMS("Missing DDI translation table for type
> > > > > > > > +%d with voltage %d\n", type, voltage);
> > > > > > > >
> > > > > > > > MISSING_CASE(voltage);
> > > > > > > > return;
> > > > > > > >
> > > > > > > > }
> > > > > >
> > > > > >
> > > > > > Like Paulo suggested it would be better to use a switch
> > > > > > statement for different vccio voltages and then have this in
> > > > > > the default. What do you think?
> > >
> > > >
> > > > we don't need to iterate on voltages... and the switch for type
> > > > wouldn't catch failures happening inside the functions where we
> > > > actually pick the table.
> > > >
> > > >
> > > > > >
> > > > > > Manasi
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Intel-gfx mailing list
> > > > > > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > >
> > > > > > _______________________________________________
> > > > > > Intel-gfx mailing list
> > > > > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > >
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
