Message ID | 6654058.C6O5gEn43q@dk-thinkpad-x260 (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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.. > > > > > > > > > > > > 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@intel.com> > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > > > > > > --- > > > > > > > > > > > > > > > > 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@lists.freedesktop.org > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > > > > > > > _______________________________________________ > > > > > > Intel-gfx mailing list > > > > > > Intel-gfx@lists.freedesktop.org > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Intel-gfx mailing list > > > > Intel-gfx@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > > > > _______________________________________________ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >
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@intel.com> > > > > > > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> > > > > > > > > --- > > > > > > > > > > > > > > > > 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@lists.freedesktop.org > > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > > > > > > > _______________________________________________ > > > > > > Intel-gfx mailing list > > > > > > Intel-gfx@lists.freedesktop.org > > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Intel-gfx mailing list > > > > Intel-gfx@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > > > > _______________________________________________ > > > Intel-gfx mailing list > > > Intel-gfx@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > >
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); + return; }