[Intel-gfx] [PATCH 10/10] drm/i915/cnl: Fix DP max rate for Cannonlake with port F.
Rodrigo Vivi
rodrigo.vivi at intel.com
Tue Jan 30 20:42:12 UTC 2018
On Tue, Jan 30, 2018 at 07:45:03AM +0000, Jani Nikula wrote:
> On Mon, 29 Jan 2018, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
> > On CNL SKUs that uses port F, max DP rate is 8.1G for all
> > ports when we have the elevated voltage (higher than 0.85V).
> >
> > v2: Make commit message more generic.
> > v3: Move conditions to a helper to get easier to read. (Ville).
> > v4: Add a mention to the numerical voltage on commit
> > message per Manasi request.
> > v5: Thanks CI! "error: control reaches end of non-void function"
> >
> > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > Cc: Lucas De Marchi <lucas.demarchi at intel.com>
> > Cc: Manasi Navare <manasi.d.navare at intel.com>
> > Signed-off-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
> > Reviewed-by: Manasi Navare <manasi.d.navare at intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 31 ++++++++++++++++++++++++-------
> > 1 file changed, 24 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 86a5e8bfe2a6..1f10bdb855e7 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -220,15 +220,36 @@ intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
> > return max_dotclk;
> > }
> >
> > +static int cnl_adjusted_max_rate(struct intel_dp *intel_dp, int size)
> > +{
> > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > + enum port port = dig_port->base.port;
> > +
> > + u32 voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
> > +
> > + /* Low voltage SKUs are limited to max of 5.4G */
> > + if (voltage == VOLTAGE_INFO_0_85V)
> > + return size - 2;
> > +
> > + /* For this SKU 8.1G is supported in all ports */
> > + if(IS_CNL_WITH_PORT_F(dev_priv))
> > + return size;
> > +
> > + /* For other SKUs, max rate on ports A and B is 5.4G */
> > + if (port == PORT_A || port == PORT_D)
> > + return size - 2;
> > +
> > + return size;
>
ops, I had missed this email. Since I had resent the series, the old one
was on top of my inbox.
> IMO this splits the ARRAY_SIZE() and the (size - 2) adjustments too
> much. They were tolerable within one function, but looking at this
> function alone, the (size - 2) is a big WTF.
>
> I'd just put this all in the same function.
I just split per Ville request to make conditions more readable.
I now agree that size outside of the context get uglier.
What about changing:
int num_source_rates
const int *source_rates
into:
struct {
int num;
const int *list;
int max_available;
} source_rates;
So that function or whenever we need like reading from new VBT field
we set a max_available, and when going through the list for finding
the common rate instead of relying only on num we also check max_available?
Agree?
Thoughts?
>
> BR,
> Jani.
>
>
> > +}
> > +
> > static void
> > intel_dp_set_source_rates(struct intel_dp *intel_dp)
> > {
> > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > - enum port port = dig_port->base.port;
> > const int *source_rates;
> > int size;
> > - u32 voltage;
> >
> > /* This should only be done once */
> > WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates);
> > @@ -238,11 +259,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp)
> > size = ARRAY_SIZE(bxt_rates);
> > } else if (IS_CANNONLAKE(dev_priv)) {
> > source_rates = cnl_rates;
> > - size = ARRAY_SIZE(cnl_rates);
> > - voltage = I915_READ(CNL_PORT_COMP_DW3) & VOLTAGE_INFO_MASK;
> > - if (port == PORT_A || port == PORT_D ||
> > - voltage == VOLTAGE_INFO_0_85V)
> > - size -= 2;
> > + size = cnl_adjusted_max_rate(intel_dp, ARRAY_SIZE(cnl_rates));
> > } else if (IS_GEN9_BC(dev_priv)) {
> > source_rates = skl_rates;
> > size = ARRAY_SIZE(skl_rates);
>
> --
> Jani Nikula, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list