Re: [Intel-gfx] [PATCH v5 1/8] drm/i915: Cache current cdclk frequency in dev_priv
On Tue, 2015-06-02 at 18:17 +0300, Jani Nikula wrote:
> On Tue, 02 Jun 2015, Mika Kahola wrote:
> > From: Ville Syrjälä
> >
> > Rather that extracting the current cdclk freuqncy every time someone
> > wants to know it, cache the current value and use that. VLV/CHV already
> > stored a cached value there so just expand that to cover all platforms.
>
> All of the below:
>
> > Signed-off-by: Ville Syrjälä
> >
> > v2: Rebased to the latest
> > v3: Rebased to the latest
> > v4: Rebased to the latest
> >
> > Signed-off-by: Mika Kahola
> >
> > Author:Ville Syrjälä
>
> Should be turned into:
>
> > v2: Rebased to the latest
> > v3: Rebased to the latest
> > v4: Rebased to the latest
> >
> > Signed-off-by: Ville Syrjälä
> > Signed-off-by: Mika Kahola
>
> to conform to existing style. See git log for examples.
>
> Damien had a comment to the previous version of this patch [1], but I
> don't see it addressed either in the patch or in reply to his mail. You
> should do one or the other.
>
> BR,
> Jani.
>
>
> [1] http://mid.gmane.org/20150528182433.gj24...@strange.ger.corp.intel.com
>
Ok. I'll revise the patches and resend them.
Cheers,
Mika
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 26 +-
> > 1 file changed, 17 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 16e159d..4dd00a5 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5747,7 +5747,7 @@ static int valleyview_get_vco(struct drm_i915_private
> > *dev_priv)
> > return vco_freq[hpll_freq] * 1000;
> > }
> >
> > -static void vlv_update_cdclk(struct drm_device *dev)
> > +static void intel_update_cdclk(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > @@ -5760,7 +5760,14 @@ static void vlv_update_cdclk(struct drm_device *dev)
> > * BSpec erroneously claims we should aim for 4MHz, but
> > * in fact 1MHz is the correct frequency.
> > */
> > - I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq, 1000));
> > + if (IS_VALLEYVIEW(dev)) {
> > + /*
> > +* Program the gmbus_freq based on the cdclk frequency.
> > +* BSpec erroneously claims we should aim for 4MHz, but
> > +* in fact 1MHz is the correct frequency.
> > +*/
> > + I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq,
> > 1000));
> > + }
> > }
> >
> > /* Adjust CDclk dividers to allow high res or save power if possible */
> > @@ -5826,7 +5833,7 @@ static void valleyview_set_cdclk(struct drm_device
> > *dev, int cdclk)
> >
> > mutex_unlock(&dev_priv->sb_lock);
> >
> > - vlv_update_cdclk(dev);
> > + intel_update_cdclk(dev);
> > }
> >
> > static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
> > @@ -5867,7 +5874,7 @@ static void cherryview_set_cdclk(struct drm_device
> > *dev, int cdclk)
> > }
> > mutex_unlock(&dev_priv->rps.hw_lock);
> >
> > - vlv_update_cdclk(dev);
> > + intel_update_cdclk(dev);
> > }
> >
> > static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
> > @@ -6056,6 +6063,8 @@ static void
> > valleyview_modeset_global_resources(struct drm_atomic_state *old_sta
> >
> > intel_display_power_put(dev_priv, POWER_DOMAIN_PIPE_A);
> > }
> > +
> > + intel_update_cdclk(dev);
> > }
> >
> > static void valleyview_crtc_enable(struct drm_crtc *crtc)
> > @@ -9479,6 +9488,7 @@ static void hsw_restore_lcpll(struct drm_i915_private
> > *dev_priv)
> > }
> >
> > intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> > + intel_update_cdclk(dev_priv->dev);
> > }
> >
> > /*
> > @@ -13273,6 +13283,8 @@ static void intel_shared_dpll_init(struct
> > drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> >
> > + intel_update_cdclk(dev);
> > +
> > if (HAS_DDI(dev))
> > intel_ddi_pll_init(dev);
> > else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
> > @@ -14848,13 +14860,9 @@ static void i915_disable_vga(struct drm_device
> > *dev)
> >
> > void intel_modeset_init_hw(struct drm_device *dev)
> > {
> > + intel_update_cdclk(dev);
> > intel_prepare_ddi(dev);
> > -
> > - if (IS_VALLEYVIEW(dev))
> > - vlv_update_cdclk(dev);
> > -
> > intel_init_clock_gating(dev);
> > -
> > intel_enable_gt_powersave(dev);
> > }
> >
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/24] drm/i915: Add a simple atomic crtc check function.
Op 03-06-15 om 03:28 schreef Matt Roper:
> On Mon, Jun 01, 2015 at 03:27:10PM +0200, Maarten Lankhorst wrote:
>> Move the check for encoder cloning here.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_atomic.c | 5 +-
>> drivers/gpu/drm/i915/intel_display.c | 131
>> ---
>> 2 files changed, 80 insertions(+), 56 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 156df1b59ddd..1edd1651c045 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -100,7 +100,10 @@ int intel_atomic_check(struct drm_device *dev,
>> if (ret)
>> return ret;
>>
>> -/* FIXME: move to crtc atomic check function once it is ready */
>> +/*
>> + * FIXME: move to crtc atomic check function once this is
>> + * more atomic friendly.
>> + */
>> ret = intel_atomic_setup_scalers(dev, nuclear_crtc, crtc_state);
>> if (ret)
>> return ret;
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 6f3e96930da5..0060784525dc 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -11404,11 +11404,87 @@ out_hang:
>> return ret;
>> }
>>
>> +static bool encoders_cloneable(const struct intel_encoder *a,
>> + const struct intel_encoder *b)
>> +{
>> +/* masks could be asymmetric, so check both ways */
>> +return a == b || (a->cloneable & (1 << b->type) &&
>> + b->cloneable & (1 << a->type));
>> +}
>> +
>> +static bool check_single_encoder_cloning(struct drm_atomic_state *state,
>> + struct intel_crtc *crtc,
>> + struct intel_encoder *encoder)
>> +{
>> +struct intel_encoder *source_encoder;
>> +struct drm_connector *connector;
>> +struct drm_connector_state *connector_state;
>> +int i;
>> +
>> +for_each_connector_in_state(state, connector, connector_state, i) {
>> +if (connector_state->crtc != &crtc->base)
>> +continue;
>> +
>> +source_encoder =
>> +to_intel_encoder(connector_state->best_encoder);
>> +if (!encoders_cloneable(encoder, source_encoder))
>> +return false;
>> +}
>> +
>> +return true;
>> +}
>> +
>> +static bool check_encoder_cloning(struct drm_atomic_state *state,
>> + struct intel_crtc *crtc)
>> +{
>> +struct intel_encoder *encoder;
>> +struct drm_connector *connector;
>> +struct drm_connector_state *connector_state;
>> +int i;
>> +
>> +for_each_connector_in_state(state, connector, connector_state, i) {
>> +if (connector_state->crtc != &crtc->base)
>> +continue;
>> +
>> +encoder = to_intel_encoder(connector_state->best_encoder);
>> +if (!check_single_encoder_cloning(state, crtc, encoder))
>> +return false;
>> +}
>> +
>> +return true;
>> +}
>> +
>> +static int intel_atomic_check_crtc(struct drm_crtc *crtc,
>> + struct drm_crtc_state *crtc_state)
> The plane equivalent is 'intel_plane_atomic_check'...it would be nice if
> we could keep the naming consistent (intel_crtc_atomic_check).
>
> Not sure if this should go in intel_display.c or intel_atomic.c. Maybe
> a future patch can shuffle a bunch of stuff around so things are a bit
> more consistent than they are today.
That's my intention. But for now keeping everything in 1 place is a lot easier.
After it's hooked up as
atomic_check/atomic_commit I can move it to intel_atomic.c, but for now
maintaining such a patch
would be busywork since it would break down every time I make an adjustment.
>
>> +{
>> +struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>> +struct drm_atomic_state *state = crtc_state->state;
>> +int idx = crtc->base.id;
>> +bool is_crtc_enabled = crtc_state->active;
>> +bool was_crtc_enabled = crtc->state->active;
>> +bool mode_changed = needs_modeset(crtc_state);
>> +
>> +if (mode_changed && !check_encoder_cloning(state, intel_crtc)) {
>> +DRM_DEBUG_KMS("rejecting invalid cloning configuration\n");
>> +return -EINVAL;
>> +}
>> +
>> +I915_STATE_WARN(crtc->state->active != intel_crtc->active,
>> +"[CRTC:%i] mismatch between state->active(%i) and
>> crtc->active(%i)\n",
>> +idx, crtc->state->active, intel_crtc->active);
>> +
>> +DRM_DEBUG_ATOMIC("Crtc %i was enabled %i now enabled: %i\n",
>> + idx, was_crtc_enabled, is_crtc_enabled);
> Maybe just print this debug message when the values aren't equal (i.e.,
> an actual change) to cut down on a little spam when it isn't
> interesting?
I think it's not interesting to keep t
Re: [Intel-gfx] [PATCH 04/24] drm/i915: Update power domains only on affected crtc's.
Op 03-06-15 om 03:27 schreef Matt Roper: > On Mon, Jun 01, 2015 at 03:27:07PM +0200, Maarten Lankhorst wrote: >> Use for_each_crtc_state to only touch affected crtc's. >> In order to make sure that the initial power is still set >> correctly we make sure modeset_update_crtc_power_domains is called >> during the initial modeset. >> >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/i915_drv.c | 3 --- >> drivers/gpu/drm/i915/intel_display.c | 41 >> +++- >> 2 files changed, 26 insertions(+), 18 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_drv.c >> b/drivers/gpu/drm/i915/i915_drv.c >> index d3632c56fdf7..78ef0bb53c36 100644 >> --- a/drivers/gpu/drm/i915/i915_drv.c >> +++ b/drivers/gpu/drm/i915/i915_drv.c >> @@ -634,9 +634,6 @@ static int i915_drm_suspend(struct drm_device *dev) >> intel_display_suspend(dev); >> drm_modeset_unlock_all(dev); >> >> -/* suspending displays will unsets init power */ >> -intel_display_set_init_power(dev_priv, true); >> - >> intel_dp_mst_suspend(dev); >> >> intel_runtime_pm_disable_interrupts(dev_priv); >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index 8e9afc55c284..4dc07602248b 100644 >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++ b/drivers/gpu/drm/i915/intel_display.c >> @@ -5188,42 +5188,49 @@ static unsigned long get_crtc_power_domains(struct >> drm_crtc *crtc) >> return mask; >> } >> >> -static void modeset_update_crtc_power_domains(struct drm_atomic_state >> *state) >> +static void modeset_update_crtc_power_domains(struct drm_atomic_state >> *state, bool gr) > What does 'gr' stand for and what does the parameter signify? It seems > to just gate whether we call display.modeset_global_resources, but it's > unclear to me from the commit message above in which situations we > would/wouldn't want to do this and why. > Well there's no point if no modeset is done to call display.modeset_global_resources. But I guess calling it power_only might be better. I wish I knew why modeset_global_resources was done in the middle, I think there's no point to do so. But I'll split it up in 2 functions, modeset_get_crtc_power_domains and modeset_put_crtc_power_domains, so I can fold it into the crtc modeset loop. ! Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/24] drm/i915: clean up intel_sanitize_crtc
Op 03-06-15 om 03:27 schreef Matt Roper: > On Mon, Jun 01, 2015 at 03:27:06PM +0200, Maarten Lankhorst wrote: >> Apply force if needed. > It's not clear to me what this means; can you elaborate? It seems that > 'force' in the context of intel_crtc_control() means we're updating the > 'enable' field as well, not just the 'active' field. > >> During boot pipe_config->active will be false. >> On resume no separate modeset is needed when the state gets restored >> with the sw state anyway. > If I understand the git history correctly, there's also a special case > where intel_modeset_setup_hw_state() gets called on lid status change > because some BIOS silently change hardware state behind our back. Are > we still covered in that case? Sure why not? At the point we swapped our previous sw state to the atomic struct, which we don't touch here. But looking some closer I think manually setting enable might not be enough, we should probably call drm_atomic_set_mode_for_crtc and remove all connectors ourself, I think I may add some helper for that, if it's useful for others too. I was looking if crtc_state->enable == !num_connectors was enforced, that seems to be done by drm_atomic_helper_check_modeset fortunately. So I think right now this patch would fail to do what it says.. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Implement WaBarrierPerformanceFixDisable (again)
On Wed, 03 Jun 2015, Ben Widawsky wrote: > in > commit 65ca7514e21adbee25b8175fc909759c735d00ff > Author: Damien Lespiau > Date: Mon Feb 9 19:33:22 2015 + > > drm/i915/skl: Implement WaBarrierPerformanceFixDisable > > The workaround ended up in the chv workarounds. Not sure what the reason or > history of that is, but it /seems/ wrong. Don't know if this fixes anything > since I have many other problems with my platform. > > Cc: Damien Lespiau > Cc: Nick Hoath > Signed-off-by: Ben Widawsky Ville beat you to it [1]. However he put it in skl workarounds, not gen9, so I'm presuming this does not apply to bxt. BR, Jani. [1] http://mid.gmane.org/1433248657-4509-1-git-send-email-ville.syrj...@linux.intel.com > --- > drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index d934f85..0fd6033d 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -901,13 +901,6 @@ static int chv_init_workarounds(struct intel_engine_cs > *ring) > GEN6_WIZ_HASHING_MASK, > GEN6_WIZ_HASHING_16x4); > > - if (INTEL_REVID(dev) == SKL_REVID_C0 || > - INTEL_REVID(dev) == SKL_REVID_D0) > - /* WaBarrierPerformanceFixDisable:skl */ > - WA_SET_BIT_MASKED(HDC_CHICKEN0, > - HDC_FENCE_DEST_SLM_DISABLE | > - HDC_BARRIER_PERFORMANCE_DISABLE); > - > return 0; > } > > @@ -972,6 +965,13 @@ static int gen9_init_workarounds(struct intel_engine_cs > *ring) > tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE; > WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp); > > + if (INTEL_REVID(dev) == SKL_REVID_C0 || > + INTEL_REVID(dev) == SKL_REVID_D0) > + /* WaBarrierPerformanceFixDisable:skl */ > + WA_SET_BIT_MASKED(HDC_CHICKEN0, > + HDC_FENCE_DEST_SLM_DISABLE | > + HDC_BARRIER_PERFORMANCE_DISABLE); > + > return 0; > } > > -- > 2.4.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FAILED: patch "[PATCH] drm/i915: Avoid GPU hang when coming out of s3 or s4" failed to apply to 4.0-stable tree
+intel-gfx, anyone up for a backport?
BR,
Jani.
On Wed, 03 Jun 2015, gre...@linuxfoundation.org wrote:
> The patch below does not apply to the 4.0-stable tree.
> If someone wants it applied there, or to any other stable or longterm
> tree, then please email the backport, including the original git commit
> id to .
>
> thanks,
>
> greg k-h
>
> -- original commit in Linus's tree --
>
> From 364aece01a2dd748fc36a1e8bf52ef639b0857bd Mon Sep 17 00:00:00 2001
> From: Peter Antoine
> Date: Mon, 11 May 2015 08:50:45 +0100
> Subject: [PATCH] drm/i915: Avoid GPU hang when coming out of s3 or s4
>
> This patch fixes a timing issue that causes a GPU hang when the system
> comes out of power saving.
>
> During pm_resume, We are submitting batchbuffers before enabling
> Interrupts this is causing us to miss the context switch interrupt,
> and in consequence intel_execlists_handle_ctx_events is not triggered.
>
> This patch is based on a patch from Deepak S
> from another platform.
>
> The patch fixes an issue introduced by:
> commit e7778be1eab918274f79603d7c17b3ec8be77386
> drm/i915: Fix startup failure in LRC mode after recent init changes
>
> The above patch added a call to init_context() to fix an issue introduced
> by a previous patch. But, it then opened up a small timing window for the
> batches being added by the init_context (basically setting up the context)
> to complete before the interrupts have been turned on, thus hanging the
> GPU.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89600
> Cc: sta...@vger.kernel.org # 4.0+
> Signed-off-by: Peter Antoine
> Reviewed-by: Daniel Vetter
> [Jani: fixed typo in subject, massaged the comments a bit]
> Signed-off-by: Jani Nikula
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index c302ffb5a168..a19d2c71e205 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -699,6 +699,16 @@ static int i915_drm_resume(struct drm_device *dev)
> intel_init_pch_refclk(dev);
> drm_mode_config_reset(dev);
>
> + /*
> + * Interrupts have to be enabled before any batches are run. If not the
> + * GPU will hang. i915_gem_init_hw() will initiate batches to
> + * update/restore the context.
> + *
> + * Modeset enabling in intel_modeset_init_hw() also needs working
> + * interrupts.
> + */
> + intel_runtime_pm_enable_interrupts(dev_priv);
> +
> mutex_lock(&dev->struct_mutex);
> if (i915_gem_init_hw(dev)) {
> DRM_ERROR("failed to re-initialize GPU, declaring wedged!\n");
> @@ -706,9 +716,6 @@ static int i915_drm_resume(struct drm_device *dev)
> }
> mutex_unlock(&dev->struct_mutex);
>
> - /* We need working interrupts for modeset enabling ... */
> - intel_runtime_pm_enable_interrupts(dev_priv);
> -
> intel_modeset_init_hw(dev);
>
> spin_lock_irq(&dev_priv->irq_lock);
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: edp1.4 Intermediate Freq support
On 5/26/2015 5:50 PM, Sonika Jindal wrote:
BXT supports following intermediate link rates for edp:
2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz.
Adding support for programming the intermediate rates.
v2: Adding clock in bxt_clk_div struct and then look for the entry with
required rate (Ville)
v3: 'clock' has the selected value, no need to use link_bw or rate_select
for selecting pll(Ville)
v4: Make bxt_dp_clk_val const and remove size (Ville)
v5: Rebased
v6: Removed setting of vco while rebasing in v5, adding it back
Signed-off-by: Sonika Jindal
Reviewed-by: Ville Syrjälä (v4)
---
drivers/gpu/drm/i915/intel_ddi.c | 39 --
drivers/gpu/drm/i915/intel_dp.c |7 ++-
2 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cacb07b..2a2518d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1334,6 +1334,7 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
/* bxt clock parameters */
struct bxt_clk_div {
+ int clock;
uint32_t p1;
uint32_t p2;
uint32_t m2_int;
@@ -1343,14 +1344,14 @@ struct bxt_clk_div {
};
/* pre-calculated values for DP linkrates */
-static struct bxt_clk_div bxt_dp_clk_val[7] = {
- /* 162 */ {4, 2, 32, 1677722, 1, 1},
- /* 270 */ {4, 1, 27, 0, 0, 1},
- /* 540 */ {2, 1, 27, 0, 0, 1},
- /* 216 */ {3, 2, 32, 1677722, 1, 1},
- /* 243 */ {4, 1, 24, 1258291, 1, 1},
- /* 324 */ {4, 1, 32, 1677722, 1, 1},
- /* 432 */ {3, 1, 32, 1677722, 1, 1}
+static const struct bxt_clk_div bxt_dp_clk_val[] = {
+ {162000, 4, 2, 32, 1677722, 1, 1},
+ {27, 4, 1, 27, 0, 0, 1},
+ {54, 2, 1, 27, 0, 0, 1},
+ {216000, 3, 2, 32, 1677722, 1, 1},
+ {243000, 4, 1, 24, 1258291, 1, 1},
+ {324000, 4, 1, 32, 1677722, 1, 1},
+ {432000, 3, 1, 32, 1677722, 1, 1}
};
static bool
@@ -1390,22 +1391,14 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
vco = best_clock.vco;
} else if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
intel_encoder->type == INTEL_OUTPUT_EDP) {
- struct drm_encoder *encoder = &intel_encoder->base;
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ int i;
- switch (intel_dp->link_bw) {
- case DP_LINK_BW_1_62:
- clk_div = bxt_dp_clk_val[0];
- break;
- case DP_LINK_BW_2_7:
- clk_div = bxt_dp_clk_val[1];
- break;
- case DP_LINK_BW_5_4:
- clk_div = bxt_dp_clk_val[2];
- break;
- default:
- clk_div = bxt_dp_clk_val[0];
- DRM_ERROR("Unknown link rate\n");
+ clk_div = bxt_dp_clk_val[0];
+ for (i = 0; i < ARRAY_SIZE(bxt_dp_clk_val); ++i) {
+ if (bxt_dp_clk_val[i].clock == clock) {
+ clk_div = bxt_dp_clk_val[i];
+ break;
+ }
}
vco = clock * 10 / 2 * clk_div.p1 * clk_div.p2;
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index abd442a..bd0f958 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -91,6 +91,8 @@ static const struct dp_link_dpll chv_dpll[] = {
{ .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
};
+static const int bxt_rates[] = { 162000, 216000, 243000, 27,
+ 324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
static const int chv_rates[] = { 162000, 202500, 21, 216000,
@@ -1170,7 +1172,10 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int
**sink_rates)
static int
intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
{
- if (IS_SKYLAKE(dev)) {
+ if (IS_BROXTON(dev)) {
+ *source_rates = bxt_rates;
+ return ARRAY_SIZE(bxt_rates);
+ } else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
} else if (IS_CHERRYVIEW(dev)) {
Reviewed-by: Vandana Kannan
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Implement WaBarrierPerformanceFixDisable (again)
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6527 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bxt: edp1.4 Intermediate Freq support
Hi Vandana,
Can you please review the v6 of this patch?
This was rebased recently on top of your patch:
commit b6dc71f38a84e36c5445b95f9f7a2dac6b25636f
Author: Vandana Kannan
Date: Wed May 13 12:18:52 2015 +0530
drm/i915/bxt: Port PLL programming BUN
Thanks,
Sonika
On 5/26/2015 5:50 PM, Sonika Jindal wrote:
BXT supports following intermediate link rates for edp:
2.16GHz, 2.43GHz, 3.24GHz, 4.32GHz.
Adding support for programming the intermediate rates.
v2: Adding clock in bxt_clk_div struct and then look for the entry with
required rate (Ville)
v3: 'clock' has the selected value, no need to use link_bw or rate_select
for selecting pll(Ville)
v4: Make bxt_dp_clk_val const and remove size (Ville)
v5: Rebased
v6: Removed setting of vco while rebasing in v5, adding it back
Signed-off-by: Sonika Jindal
Reviewed-by: Ville Syrjälä (v4)
---
drivers/gpu/drm/i915/intel_ddi.c | 39 --
drivers/gpu/drm/i915/intel_dp.c |7 ++-
2 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cacb07b..2a2518d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1334,6 +1334,7 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
/* bxt clock parameters */
struct bxt_clk_div {
+ int clock;
uint32_t p1;
uint32_t p2;
uint32_t m2_int;
@@ -1343,14 +1344,14 @@ struct bxt_clk_div {
};
/* pre-calculated values for DP linkrates */
-static struct bxt_clk_div bxt_dp_clk_val[7] = {
- /* 162 */ {4, 2, 32, 1677722, 1, 1},
- /* 270 */ {4, 1, 27, 0, 0, 1},
- /* 540 */ {2, 1, 27, 0, 0, 1},
- /* 216 */ {3, 2, 32, 1677722, 1, 1},
- /* 243 */ {4, 1, 24, 1258291, 1, 1},
- /* 324 */ {4, 1, 32, 1677722, 1, 1},
- /* 432 */ {3, 1, 32, 1677722, 1, 1}
+static const struct bxt_clk_div bxt_dp_clk_val[] = {
+ {162000, 4, 2, 32, 1677722, 1, 1},
+ {27, 4, 1, 27, 0, 0, 1},
+ {54, 2, 1, 27, 0, 0, 1},
+ {216000, 3, 2, 32, 1677722, 1, 1},
+ {243000, 4, 1, 24, 1258291, 1, 1},
+ {324000, 4, 1, 32, 1677722, 1, 1},
+ {432000, 3, 1, 32, 1677722, 1, 1}
};
static bool
@@ -1390,22 +1391,14 @@ bxt_ddi_pll_select(struct intel_crtc *intel_crtc,
vco = best_clock.vco;
} else if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
intel_encoder->type == INTEL_OUTPUT_EDP) {
- struct drm_encoder *encoder = &intel_encoder->base;
- struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ int i;
- switch (intel_dp->link_bw) {
- case DP_LINK_BW_1_62:
- clk_div = bxt_dp_clk_val[0];
- break;
- case DP_LINK_BW_2_7:
- clk_div = bxt_dp_clk_val[1];
- break;
- case DP_LINK_BW_5_4:
- clk_div = bxt_dp_clk_val[2];
- break;
- default:
- clk_div = bxt_dp_clk_val[0];
- DRM_ERROR("Unknown link rate\n");
+ clk_div = bxt_dp_clk_val[0];
+ for (i = 0; i < ARRAY_SIZE(bxt_dp_clk_val); ++i) {
+ if (bxt_dp_clk_val[i].clock == clock) {
+ clk_div = bxt_dp_clk_val[i];
+ break;
+ }
}
vco = clock * 10 / 2 * clk_div.p1 * clk_div.p2;
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index abd442a..bd0f958 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -91,6 +91,8 @@ static const struct dp_link_dpll chv_dpll[] = {
{ .p1 = 2, .p2 = 1, .n = 1, .m1 = 2, .m2 = 0x6c0 } }
};
+static const int bxt_rates[] = { 162000, 216000, 243000, 27,
+ 324000, 432000, 54 };
static const int skl_rates[] = { 162000, 216000, 27,
324000, 432000, 54 };
static const int chv_rates[] = { 162000, 202500, 21, 216000,
@@ -1170,7 +1172,10 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int
**sink_rates)
static int
intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
{
- if (IS_SKYLAKE(dev)) {
+ if (IS_BROXTON(dev)) {
+ *source_rates = bxt_rates;
+ return ARRAY_SIZE(bxt_rates);
+ } else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
} else if (IS_CHERRYVIEW(dev)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Initialize HWS page address after GPU reset
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6526 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/24] drm/i915: Do not add planes from intel_atomic_setup_scalers.
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, June 02, 2015 6:30 PM
> To: Maarten Lankhorst
> Cc: intel-gfx@lists.freedesktop.org; Konduru, Chandra
> Subject: Re: [Intel-gfx] [PATCH 08/24] drm/i915: Do not add planes from
> intel_atomic_setup_scalers.
>
> On Mon, Jun 01, 2015 at 03:27:11PM +0200, Maarten Lankhorst wrote:
> > This may postpone going to HQ mode until the plane is in the
> > drm_atomic_state if it's not using scaler 0, but it does allow moving
> > intel_atomic_setup_scalers to the crtc check function.
> >
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/i915/intel_atomic.c | 41
> > ++
> --
> > drivers/gpu/drm/i915/intel_display.c | 27 +++-
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 3 files changed, 39 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> > index 1edd1651c045..a8202fa0daa8 100644
> > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > @@ -100,14 +100,6 @@ int intel_atomic_check(struct drm_device *dev,
> > if (ret)
> > return ret;
> >
> > - /*
> > -* FIXME: move to crtc atomic check function once this is
> > -* more atomic friendly.
> > -*/
> > - ret = intel_atomic_setup_scalers(dev, nuclear_crtc, crtc_state);
> > - if (ret)
> > - return ret;
> > -
> > return ret;
> > }
> >
> > @@ -336,21 +328,10 @@ int intel_atomic_setup_scalers(struct drm_device
> *dev,
> > /* find the plane that set the bit as scaler_user */
> > plane = drm_state->planes[i];
> >
> > - /*
> > -* to enable/disable hq mode, add planes that are using
> scaler
> > -* into this transaction
> > -*/
> > if (!plane) {
> > - struct drm_plane_state *state;
> > - plane = drm_plane_from_index(dev, i);
> > - state =
> drm_atomic_get_plane_state(drm_state, plane);
> > - if (IS_ERR(state)) {
> > - DRM_DEBUG_KMS("Failed to add
> [PLANE:%d] to drm_state\n",
> > - plane->base.id);
> > - return PTR_ERR(state);
> > - }
> > + DRM_DEBUG_KMS("Failed to find [PLANE:%d]
> in drm_state\n", plane->base.id);
> > + continue;
> > }
> > -
> > intel_plane = to_intel_plane(plane);
> >
> > /* plane on different crtc cannot be a scaler user of
> > this
> crtc */
> > @@ -396,6 +377,24 @@ int intel_atomic_setup_scalers(struct drm_device
> *dev,
> > }
> > }
> >
> > + /* plane not part of mask must leave hq mode? */
> > + if (num_scalers_need > 1 && scaler_state->scalers[0].in_use &&
> > + scaler_state->scalers[0].mode == PS_SCALER_MODE_HQ) {
> > + scaler_state->scalers[0].mode = PS_SCALER_MODE_DYN;
> > +
> > + intel_crtc->atomic.skl_update_scaler0 =
> > + PS_SCALER_EN | PS_SCALER_MODE_DYN;
> > + }
> > +
> > + /* plane not part of mask can enter hq mode? */
> > + if (num_scalers_need == 1 && scaler_state->scalers[0].in_use &&
> > + intel_crtc->pipe != PIPE_C && scaler_state->scalers[0].mode !=
> PS_SCALER_MODE_HQ) {
> > + scaler_state->scalers[0].mode = PS_SCALER_MODE_HQ;
> > +
> > + intel_crtc->atomic.skl_update_scaler0 =
> > + PS_SCALER_EN | PS_SCALER_MODE_HQ;
> > + }
> > +
>
> I don't have access to the hw spec at the moment; is scaler #0 the only
> one that can ever go into HQ mode?
Yes
> If there isn't a hardware
> requirement about this, then it seems like we're missing the case where
> planes A and B get scalers 0 and 1. Then plane A (and thus scaler 0) is
> disabled, which should allow scaler 1 to go into HQ mode.
In this case, scaler 0 to be allocated to plane B to operate in HQ mode.
>
> I guess it's not immediately clear to me why we need to not pull the
> other planes into the transaction. Is this just to avoid doing some
> extra work for a plane that hasn't changed, or does it cause a problem
> somehow?
Per atomic design, unchanged planes can be added to transaction.
And scaler implementation is using this design feature.
Not sure what the issue here, but we need this feature continue
to available.
>
> Chandra should probably take a look at this patch as well since he's the
> scaler expert; adding him to the Cc.
>
>
> Matt
>
> > return 0;
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> > index 0060784525dc..94101d1f784c 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drive
Re: [Intel-gfx] [PATCH 08/24] drm/i915: Do not add planes from intel_atomic_setup_scalers.
On Mon, Jun 01, 2015 at 03:27:11PM +0200, Maarten Lankhorst wrote:
> This may postpone going to HQ mode until the plane is in the
> drm_atomic_state if it's not using scaler 0, but it does allow moving
> intel_atomic_setup_scalers to the crtc check function.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 41
> ++--
> drivers/gpu/drm/i915/intel_display.c | 27 +++-
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 3 files changed, 39 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 1edd1651c045..a8202fa0daa8 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -100,14 +100,6 @@ int intel_atomic_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> - /*
> - * FIXME: move to crtc atomic check function once this is
> - * more atomic friendly.
> - */
> - ret = intel_atomic_setup_scalers(dev, nuclear_crtc, crtc_state);
> - if (ret)
> - return ret;
> -
> return ret;
> }
>
> @@ -336,21 +328,10 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
> /* find the plane that set the bit as scaler_user */
> plane = drm_state->planes[i];
>
> - /*
> - * to enable/disable hq mode, add planes that are using
> scaler
> - * into this transaction
> - */
> if (!plane) {
> - struct drm_plane_state *state;
> - plane = drm_plane_from_index(dev, i);
> - state = drm_atomic_get_plane_state(drm_state,
> plane);
> - if (IS_ERR(state)) {
> - DRM_DEBUG_KMS("Failed to add [PLANE:%d]
> to drm_state\n",
> - plane->base.id);
> - return PTR_ERR(state);
> - }
> + DRM_DEBUG_KMS("Failed to find [PLANE:%d] in
> drm_state\n", plane->base.id);
> + continue;
> }
> -
> intel_plane = to_intel_plane(plane);
>
> /* plane on different crtc cannot be a scaler user of
> this crtc */
> @@ -396,6 +377,24 @@ int intel_atomic_setup_scalers(struct drm_device *dev,
> }
> }
>
> + /* plane not part of mask must leave hq mode? */
> + if (num_scalers_need > 1 && scaler_state->scalers[0].in_use &&
> + scaler_state->scalers[0].mode == PS_SCALER_MODE_HQ) {
> + scaler_state->scalers[0].mode = PS_SCALER_MODE_DYN;
> +
> + intel_crtc->atomic.skl_update_scaler0 =
> + PS_SCALER_EN | PS_SCALER_MODE_DYN;
> + }
> +
> + /* plane not part of mask can enter hq mode? */
> + if (num_scalers_need == 1 && scaler_state->scalers[0].in_use &&
> + intel_crtc->pipe != PIPE_C && scaler_state->scalers[0].mode !=
> PS_SCALER_MODE_HQ) {
> + scaler_state->scalers[0].mode = PS_SCALER_MODE_HQ;
> +
> + intel_crtc->atomic.skl_update_scaler0 =
> + PS_SCALER_EN | PS_SCALER_MODE_HQ;
> + }
> +
I don't have access to the hw spec at the moment; is scaler #0 the only
one that can ever go into HQ mode? If there isn't a hardware
requirement about this, then it seems like we're missing the case where
planes A and B get scalers 0 and 1. Then plane A (and thus scaler 0) is
disabled, which should allow scaler 1 to go into HQ mode.
I guess it's not immediately clear to me why we need to not pull the
other planes into the transaction. Is this just to avoid doing some
extra work for a plane that hasn't changed, or does it cause a problem
somehow?
Chandra should probably take a look at this patch as well since he's the
scaler expert; adding him to the Cc.
Matt
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0060784525dc..94101d1f784c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6530,7 +6530,6 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_display_mode *adjusted_mode =
> &pipe_config->base.adjusted_mode;
> - int ret;
>
> /* FIXME should check pixel clock limits on all platforms */
> if (INTEL_INFO(dev)->gen < 4) {
> @@ -6577,14 +6576,7 @@ static int intel_crtc_compute_config(struct intel_crtc
> *crtc,
> if (pipe_config->has_pch_encoder)
> return ironlake_fdi_compute_config(crtc, pipe_config);
>
> - /* FIX
Re: [Intel-gfx] [PATCH 04/24] drm/i915: Update power domains only on affected crtc's.
On Mon, Jun 01, 2015 at 03:27:07PM +0200, Maarten Lankhorst wrote:
> Use for_each_crtc_state to only touch affected crtc's.
> In order to make sure that the initial power is still set
> correctly we make sure modeset_update_crtc_power_domains is called
> during the initial modeset.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 ---
> drivers/gpu/drm/i915/intel_display.c | 41
> +++-
> 2 files changed, 26 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index d3632c56fdf7..78ef0bb53c36 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -634,9 +634,6 @@ static int i915_drm_suspend(struct drm_device *dev)
> intel_display_suspend(dev);
> drm_modeset_unlock_all(dev);
>
> - /* suspending displays will unsets init power */
> - intel_display_set_init_power(dev_priv, true);
> -
> intel_dp_mst_suspend(dev);
>
> intel_runtime_pm_disable_interrupts(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8e9afc55c284..4dc07602248b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5188,42 +5188,49 @@ static unsigned long get_crtc_power_domains(struct
> drm_crtc *crtc)
> return mask;
> }
>
> -static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
> +static void modeset_update_crtc_power_domains(struct drm_atomic_state
> *state, bool gr)
What does 'gr' stand for and what does the parameter signify? It seems
to just gate whether we call display.modeset_global_resources, but it's
unclear to me from the commit message above in which situations we
would/wouldn't want to do this and why.
Matt
> {
> struct drm_device *dev = state->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - unsigned long pipe_domains[I915_MAX_PIPES] = { 0, };
> - struct intel_crtc *crtc;
> + unsigned long pipe_domains[I915_MAX_PIPES] = { 0, }, domains;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc *crtc;
> + int i;
>
> /*
>* First get all needed power domains, then put all unneeded, to avoid
>* any unnecessary toggling of the power wells.
>*/
> - for_each_intel_crtc(dev, crtc) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> enum intel_display_power_domain domain;
> + enum pipe pipe = to_intel_crtc(crtc)->pipe;
>
> - if (!crtc->base.state->enable)
> + if (!crtc->state->active)
> continue;
>
> - pipe_domains[crtc->pipe] = get_crtc_power_domains(&crtc->base);
> + domains = pipe_domains[pipe] = get_crtc_power_domains(crtc);
> + domains &= ~to_intel_crtc(crtc)->enabled_power_domains;
>
> - for_each_power_domain(domain, pipe_domains[crtc->pipe])
> + for_each_power_domain(domain, domains)
> intel_display_power_get(dev_priv, domain);
> }
>
> - if (dev_priv->display.modeset_global_resources)
> + if (gr && dev_priv->display.modeset_global_resources)
> dev_priv->display.modeset_global_resources(state);
>
> - for_each_intel_crtc(dev, crtc) {
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> enum intel_display_power_domain domain;
>
> - for_each_power_domain(domain, crtc->enabled_power_domains)
> - intel_display_power_put(dev_priv, domain);
> + domains = intel_crtc->enabled_power_domains;
> + domains &= ~pipe_domains[pipe];
>
> - crtc->enabled_power_domains = pipe_domains[crtc->pipe];
> - }
> + intel_crtc->enabled_power_domains = pipe_domains[pipe];
>
> - intel_display_set_init_power(dev_priv, false);
> + for_each_power_domain(domain, domains)
> + intel_display_power_put(dev_priv, domain);
> + }
> }
>
> void broxton_set_cdclk(struct drm_device *dev, int frequency)
> @@ -12698,7 +12705,7 @@ static int __intel_set_mode(struct drm_atomic_state
> *state)
> /* The state has been swaped above, so state actually contains the
>* old state now. */
>
> - modeset_update_crtc_power_domains(state);
> + modeset_update_crtc_power_domains(state, true);
>
> /* Now enable the clocks, plane, pipe, and connectors that we set up. */
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> @@ -15280,12 +15287,16 @@ void intel_modeset_setup_hw_state(struct drm_device
> *dev,
> ret = intel_set_mode(state);
> if (ret) {
> DRM_ERROR("Failed to restore previo
Re: [Intel-gfx] [PATCH 07/24] drm/i915: Add a simple atomic crtc check function.
On Mon, Jun 01, 2015 at 03:27:10PM +0200, Maarten Lankhorst wrote:
> Move the check for encoder cloning here.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic.c | 5 +-
> drivers/gpu/drm/i915/intel_display.c | 131
> ---
> 2 files changed, 80 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 156df1b59ddd..1edd1651c045 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -100,7 +100,10 @@ int intel_atomic_check(struct drm_device *dev,
> if (ret)
> return ret;
>
> - /* FIXME: move to crtc atomic check function once it is ready */
> + /*
> + * FIXME: move to crtc atomic check function once this is
> + * more atomic friendly.
> + */
> ret = intel_atomic_setup_scalers(dev, nuclear_crtc, crtc_state);
> if (ret)
> return ret;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6f3e96930da5..0060784525dc 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11404,11 +11404,87 @@ out_hang:
> return ret;
> }
>
> +static bool encoders_cloneable(const struct intel_encoder *a,
> +const struct intel_encoder *b)
> +{
> + /* masks could be asymmetric, so check both ways */
> + return a == b || (a->cloneable & (1 << b->type) &&
> + b->cloneable & (1 << a->type));
> +}
> +
> +static bool check_single_encoder_cloning(struct drm_atomic_state *state,
> + struct intel_crtc *crtc,
> + struct intel_encoder *encoder)
> +{
> + struct intel_encoder *source_encoder;
> + struct drm_connector *connector;
> + struct drm_connector_state *connector_state;
> + int i;
> +
> + for_each_connector_in_state(state, connector, connector_state, i) {
> + if (connector_state->crtc != &crtc->base)
> + continue;
> +
> + source_encoder =
> + to_intel_encoder(connector_state->best_encoder);
> + if (!encoders_cloneable(encoder, source_encoder))
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static bool check_encoder_cloning(struct drm_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + struct intel_encoder *encoder;
> + struct drm_connector *connector;
> + struct drm_connector_state *connector_state;
> + int i;
> +
> + for_each_connector_in_state(state, connector, connector_state, i) {
> + if (connector_state->crtc != &crtc->base)
> + continue;
> +
> + encoder = to_intel_encoder(connector_state->best_encoder);
> + if (!check_single_encoder_cloning(state, crtc, encoder))
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static int intel_atomic_check_crtc(struct drm_crtc *crtc,
> +struct drm_crtc_state *crtc_state)
The plane equivalent is 'intel_plane_atomic_check'...it would be nice if
we could keep the naming consistent (intel_crtc_atomic_check).
Not sure if this should go in intel_display.c or intel_atomic.c. Maybe
a future patch can shuffle a bunch of stuff around so things are a bit
more consistent than they are today.
> +{
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + struct drm_atomic_state *state = crtc_state->state;
> + int idx = crtc->base.id;
> + bool is_crtc_enabled = crtc_state->active;
> + bool was_crtc_enabled = crtc->state->active;
> + bool mode_changed = needs_modeset(crtc_state);
> +
> + if (mode_changed && !check_encoder_cloning(state, intel_crtc)) {
> + DRM_DEBUG_KMS("rejecting invalid cloning configuration\n");
> + return -EINVAL;
> + }
> +
> + I915_STATE_WARN(crtc->state->active != intel_crtc->active,
> + "[CRTC:%i] mismatch between state->active(%i) and
> crtc->active(%i)\n",
> + idx, crtc->state->active, intel_crtc->active);
> +
> + DRM_DEBUG_ATOMIC("Crtc %i was enabled %i now enabled: %i\n",
> + idx, was_crtc_enabled, is_crtc_enabled);
Maybe just print this debug message when the values aren't equal (i.e.,
an actual change) to cut down on a little spam when it isn't
interesting?
Matt
> +
> + return 0;
> +}
> +
> static const struct drm_crtc_helper_funcs intel_helper_funcs = {
> .mode_set_base_atomic = intel_pipe_set_base_atomic,
> .load_lut = intel_crtc_load_lut,
> .atomic_begin = intel_begin_crtc_commit,
> .atomic_flush = intel_finish_crtc_commit,
> + .atomic_check = intel_atomic_check_crtc,
> };
>
> /* Transitional helper to copy current connector/encod
Re: [Intel-gfx] [PATCH 03/24] drm/i915: clean up intel_sanitize_crtc
On Mon, Jun 01, 2015 at 03:27:06PM +0200, Maarten Lankhorst wrote:
> Apply force if needed.
It's not clear to me what this means; can you elaborate? It seems that
'force' in the context of intel_crtc_control() means we're updating the
'enable' field as well, not just the 'active' field.
> During boot pipe_config->active will be false.
> On resume no separate modeset is needed when the state gets restored
> with the sw state anyway.
If I understand the git history correctly, there's also a special case
where intel_modeset_setup_hw_state() gets called on lid status change
because some BIOS silently change hardware state behind our back. Are
we still covered in that case?
Matt
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 8 ++--
> drivers/gpu/drm/i915/intel_display.c | 84
> +++-
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 3 files changed, 29 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 51fe0fbcd00c..db23916c1875 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3637,7 +3637,7 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct
> drm_device *dev)
> bool active = pipe_config->base.active;
>
> if (active) {
> - intel_crtc_control(&crtc->base, false);
> + intel_crtc_control(&crtc->base, false, false);
> pipe_config = to_intel_crtc_state(crtc->base.state);
> }
>
> @@ -3647,7 +3647,7 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct
> drm_device *dev)
> POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
>
> if (active)
> - intel_crtc_control(&crtc->base, true);
> + intel_crtc_control(&crtc->base, true, false);
> }
> drm_modeset_unlock_all(dev);
> }
> @@ -3671,7 +3671,7 @@ static void hsw_undo_trans_edp_pipe_A_crc_wa(struct
> drm_device *dev)
> bool active = pipe_config->base.active;
>
> if (active) {
> - intel_crtc_control(&crtc->base, false);
> + intel_crtc_control(&crtc->base, false, false);
> pipe_config = to_intel_crtc_state(crtc->base.state);
> }
>
> @@ -3681,7 +3681,7 @@ static void hsw_undo_trans_edp_pipe_A_crc_wa(struct
> drm_device *dev)
> POWER_DOMAIN_PIPE_PANEL_FITTER(PIPE_A));
>
> if (active)
> - intel_crtc_control(&crtc->base, true);
> + intel_crtc_control(&crtc->base, true, false);
> }
> drm_modeset_unlock_all(dev);
> }
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0f031658a297..8e9afc55c284 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6192,7 +6192,7 @@ free:
> }
>
> /* Master function to enable/disable CRTC and corresponding power wells */
> -int intel_crtc_control(struct drm_crtc *crtc, bool enable)
> +int intel_crtc_control(struct drm_crtc *crtc, bool active, bool force)
> {
> struct drm_device *dev = crtc->dev;
> struct drm_mode_config *config = &dev->mode_config;
> @@ -6202,10 +6202,13 @@ int intel_crtc_control(struct drm_crtc *crtc, bool
> enable)
> struct drm_atomic_state *state;
> int ret;
>
> - if (enable == intel_crtc->active)
> + if (WARN_ON(active && force))
> + return -EINVAL;
> +
> + if (active == intel_crtc->active)
> return 0;
>
> - if (enable && !crtc->state->enable)
> + if (active && !crtc->state->enable)
> return 0;
>
> /* this function should be called with drm_modeset_lock_all for now */
> @@ -6225,7 +6228,9 @@ int intel_crtc_control(struct drm_crtc *crtc, bool
> enable)
> ret = PTR_ERR(pipe_config);
> goto err;
> }
> - pipe_config->base.active = enable;
> + pipe_config->base.active = active;
> + if (force)
> + pipe_config->base.enable = false;
>
> ret = intel_set_mode(state);
> if (!ret)
> @@ -6249,7 +6254,7 @@ void intel_crtc_update_dpms(struct drm_crtc *crtc)
> for_each_encoder_on_crtc(dev, crtc, intel_encoder)
> enable |= intel_encoder->connectors_active;
>
> - intel_crtc_control(crtc, enable);
> + intel_crtc_control(crtc, enable, false);
> }
>
> void intel_encoder_destroy(struct drm_encoder *encoder)
> @@ -14812,11 +14817,14 @@ intel_check_plane_mapping(struct intel_crtc *crtc)
> return true;
> }
>
> -static void intel_sanitize_crtc(struct intel_crtc *crtc)
> +static void intel_sanitize_crtc(struct intel_crtc *crtc,
> + struct intel_crtc_state *pipe_config)
> {
> struct drm_d
Re: [Intel-gfx] [PATCH v5] drm/i915: Fix DDC probe for passive adapters
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6525 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW -1 321/321 320/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x *BDW igt@gem_gtt_hog PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#assert_plane[i915]()@WARNING:.* at .* assert_plane assertion_failure@assertion failure WARNING:at_drivers/gpu/drm/drm_irq.c:#drm_wait_one_vblank[drm]()@WARNING:.* at .* drm_wait_one_vblank+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl: Implement WaBarrierPerformanceFixDisable (again)
in commit 65ca7514e21adbee25b8175fc909759c735d00ff Author: Damien Lespiau Date: Mon Feb 9 19:33:22 2015 + drm/i915/skl: Implement WaBarrierPerformanceFixDisable The workaround ended up in the chv workarounds. Not sure what the reason or history of that is, but it /seems/ wrong. Don't know if this fixes anything since I have many other problems with my platform. Cc: Damien Lespiau Cc: Nick Hoath Signed-off-by: Ben Widawsky --- drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index d934f85..0fd6033d 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -901,13 +901,6 @@ static int chv_init_workarounds(struct intel_engine_cs *ring) GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4); - if (INTEL_REVID(dev) == SKL_REVID_C0 || - INTEL_REVID(dev) == SKL_REVID_D0) - /* WaBarrierPerformanceFixDisable:skl */ - WA_SET_BIT_MASKED(HDC_CHICKEN0, - HDC_FENCE_DEST_SLM_DISABLE | - HDC_BARRIER_PERFORMANCE_DISABLE); - return 0; } @@ -972,6 +965,13 @@ static int gen9_init_workarounds(struct intel_engine_cs *ring) tmp |= HDC_FORCE_CSR_NON_COHERENT_OVR_DISABLE; WA_SET_BIT_MASKED(HDC_CHICKEN0, tmp); + if (INTEL_REVID(dev) == SKL_REVID_C0 || + INTEL_REVID(dev) == SKL_REVID_D0) + /* WaBarrierPerformanceFixDisable:skl */ + WA_SET_BIT_MASKED(HDC_CHICKEN0, + HDC_FENCE_DEST_SLM_DISABLE | + HDC_BARRIER_PERFORMANCE_DISABLE); + return 0; } -- 2.4.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Apply WaDisableAsyncFlipPerfMode via LRIs on gen8
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6524 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] perf/x86/intel/pt: Fix lockdep interaction
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6523 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Initialize HWS page address after GPU reset
After GPU reset, HW is losing the address of HWS page in the register.
The page itself is valid except that HW is not aware of its location.
[ 64.368623] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address =
0x
[ 64.368655] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address =
0x
[ 64.368681] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address =
0x
[ 64.368704] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address =
0x
This patch reloads this value into the register during ring init.
Change-Id: Ibdd1e4645921b4deb02dfc8d0d8e6ba993ce7371
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0413b8f..73033f5 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1085,6 +1085,12 @@ static int gen8_init_common_ring(struct intel_engine_cs
*ring)
I915_WRITE_IMR(ring, ~(ring->irq_enable_mask | ring->irq_keep_mask));
I915_WRITE(RING_HWSTAM(ring->mmio_base), 0x);
+ if (ring->status_page.obj) {
+ I915_WRITE(RING_HWS_PGA(ring->mmio_base),
+ (u32)ring->status_page.gfx_addr);
+ POSTING_READ(RING_HWS_PGA(ring->mmio_base));
+ }
+
I915_WRITE(RING_MODE_GEN7(ring),
_MASKED_BIT_DISABLE(GFX_REPLAY_MODE) |
_MASKED_BIT_ENABLE(GFX_RUN_LIST_ENABLE));
--
2.3.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep color HDMI sinks
> > > @@ -541,6 +541,66 @@ static void g4x_set_infoframes(struct drm_encoder
> > > *encoder,
> > > intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode); }
> > >
> > > +static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder) {
> >
> > Some static functions are prefixed but this isn't. Can you add prefix?
>
> Is there any benefit from a prefix?
Personally, I am fine either way. But based on review feedback seen so far,
this is being looked at and asked to follow. From that perspective I mentioned
that.
If this is something optional and tied to benefit, then no issue here.
>
> >
> > > + struct drm_device *dev = encoder->dev;
> > > + struct drm_connector *connector;
> > > +
> > > + WARN_ON(!drm_modeset_is_locked(&dev-
> > > >mode_config.connection_mutex));
> > > +
> > > + /*
> > > + * HDMI cloning is only supported on g4x which doesn't
> > > + * support deep color or GCP infoframes anyway so no
> > > + * need to worry about multiple HDMI sinks here.
> > > + */
> >
> > There isn't any code specific for HDMI cloning or multiple HDMI sinks here,
> > any relevance of above comment. Or am I missing something here?
>
> In a cloned setup we'd feed multiple sinks from the same transcoder, so
> we'd need to basically check that connector->encoder->crtc matches our crtc
> here, and only return true if all the relevant connectors were deep color
> capable. But since we can ignore cloning we can stop looking once we
> find the connector for our current encoder (ie. HDMI port).
OK, makes sense. Thanks for the background info.
Not sure if you are spinning another version to fix the typo below or prefix
above,
otherwise, this gets
Reviewed-by: Chandra Konduru
>
> >
> > > + list_for_each_entry(connector, &dev->mode_config.connector_list,
> > > head)
> > > + if (connector->encoder == encoder)
> > > + return connector->display_info.bpc > 8;
> > > +
> > > + return false;
> > > +}
> > > +
> > > +static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder) {
> > > + struct drm_i915_private *dev_priv = encoder->dev->dev_private;
> > > + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > > + u32 reg, val = 0;
> > > +
> > > + if (HAS_DDI(dev_priv))
> > > + reg = HSW_TVIDEO_DIP_GCP(crtc->config->cpu_transcoder);
> > > + else if (IS_VALLEYVIEW(dev_priv))
> > > + reg = VLV_TVIDEO_DIP_GCP(crtc->pipe);
> > > + else if (HAS_PCH_SPLIT(dev_priv->dev))
> > > + reg = TVIDEO_DIP_GCP(crtc->pipe);
> > > + else
> > > + return false;
> > > +
> > > + /* Indicate color depth wheneven the sink supports deep color */
> >
> > Typo
> >
> > > + if (hdmi_sink_is_deep_color(encoder))
> > > + val |= GCP_COLOR_INDICATION;
> > > +
> > > + I915_WRITE(reg, val);
> > > +
> > > + return val != 0;
> > > +}
> > > +
> > > +static void intel_disable_gcp_infoframe(struct intel_crtc *crtc) {
> > > + struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> > > + u32 reg;
> > > +
> > > + if (HAS_DDI(dev_priv))
> > > + reg = HSW_TVIDEO_DIP_CTL(crtc->config->cpu_transcoder);
> > > + else if (IS_VALLEYVIEW(dev_priv))
> > > + reg = VLV_TVIDEO_DIP_CTL(crtc->pipe);
> > > + else if (HAS_PCH_SPLIT(dev_priv->dev))
> > > + reg = TVIDEO_DIP_CTL(crtc->pipe);
> > > + else
> > > + return;
> > > +
> > > + I915_WRITE(reg, I915_READ(reg) & ~VIDEO_DIP_ENABLE_GCP); }
> > > +
> > > static void ibx_set_infoframes(struct drm_encoder *encoder,
> > > bool enable,
> > > struct drm_display_mode *adjusted_mode) @@ -
> > > 581,6 +641,9 @@ static void ibx_set_infoframes(struct drm_encoder
> *encoder,
> > > val &= ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
> > >VIDEO_DIP_ENABLE_GCP);
> > >
> > > + if (intel_hdmi_set_gcp_infoframe(encoder))
> > > + val |= VIDEO_DIP_ENABLE_GCP;
> > > +
> > > I915_WRITE(reg, val);
> > > POSTING_READ(reg);
> > >
> > > @@ -618,6 +681,9 @@ static void cpt_set_infoframes(struct drm_encoder
> > > *encoder,
> > > val &= ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
> > >VIDEO_DIP_ENABLE_GCP);
> > >
> > > + if (intel_hdmi_set_gcp_infoframe(encoder))
> > > + val |= VIDEO_DIP_ENABLE_GCP;
> > > +
> > > I915_WRITE(reg, val);
> > > POSTING_READ(reg);
> > >
> > > @@ -666,6 +732,9 @@ static void vlv_set_infoframes(struct drm_encoder
> > > *encoder,
> > > val &= ~(VIDEO_DIP_ENABLE_AVI | VIDEO_DIP_ENABLE_VENDOR |
> > >VIDEO_DIP_ENABLE_GAMUT | VIDEO_DIP_ENABLE_GCP);
> > >
> > > + if (intel_hdmi_set_gcp_infoframe(encoder))
> > > + val |= VIDEO_DIP_ENABLE_GCP;
> > > +
> >
> > There is a comment in the code that
> > "Note that g4x/vlv don't support 12bpc hdmi outputs."
> > Is above call still required for vlv? Or need an update to that comment.
>
> VLV/CHV support the GCP infoframe even though they don't support
> 12bpc output. The way I decided to do things is to send the GCP
> infoframe whenever
Re: [Intel-gfx] [PATCH v2 1/7] drm/i915/gen8: Add infrastructure to initialize WA batch buffers
On 02/06/15 19:36, Siluvery, Arun wrote: > On 01/06/2015 11:22, Daniel, Thomas wrote: >>> >>> Indeed, allocating an extra scratch page in the context would simplify >>> vma/mm management. A trick might be to allocate the scratch page at the >>> start, then offset the lrc regs etc - that would then be consistent >>> amongst gen and be easy enough to extend if we need more per-context >>> scratch space in future. >>> -Chris >> >> Yes, I think we already have another use for more per-context space at >> the start. The GuC is planning to do this. Arun, you probably should >> work with Alex Dai and Dave Gordon to avoid conflicts here. >> >> Thomas. >> > > Thanks for the heads-up Thomas. > I have discussed with Dave and agreed to share this page; > GuC probably doesn't need whole page so first half is reserved for it's > use and second half is used for WA. > > I have modified my patches to use context page for applying these WA and > don't see any issues. > > During the discussions Dave proposed another approach. Even though these > WA are called per context they are only initialized once and not changed > afterwards, same set of WA are applied for each context so instead of > adding them in each context, does it make sense to create a separate > page and share across all contexts? but of course GuC will anyway add a > new page to context so I might as well share that page. > > Chris/Dave, do you see any problems with sharing page with GuC or you > prefer to allocate a separate page for these WA and share across all > contexts? Please give your comments. > > regards > Arun I think we have to consider which is more future-proof i.e. which is least likely: (1) the area shared with the GuC grows (definitely still in flux), or (2) workarounds need to be context-specific (possible, but unlikely) So I'd prefer a single area set up just once to contain the pre- and post-context restore workaround batches. If necessary, the one area could contain multiple batches at different offsets, so we could point different contexts at different (shared) batches as required. I think they're unlikely to actually need per-context customisation[*], but there might be a need for different workarounds according to workload type or privilege level or some other criterion ... ? .Dave. [*] unless they need per-context memory addresses coded into them? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/7] drm/i915/gen8: Add infrastructure to initialize WA batch buffers
On 01/06/2015 11:22, Daniel, Thomas wrote: Indeed, allocating an extra scratch page in the context would simplify vma/mm management. A trick might be to allocate the scratch page at the start, then offset the lrc regs etc - that would then be consistent amongst gen and be easy enough to extend if we need more per-context scratch space in future. -Chris Yes, I think we already have another use for more per-context space at the start. The GuC is planning to do this. Arun, you probably should work with Alex Dai and Dave Gordon to avoid conflicts here. Thomas. Thanks for the heads-up Thomas. I have discussed with Dave and agreed to share this page; GuC probably doesn't need whole page so first half is reserved for it's use and second half is used for WA. I have modified my patches to use context page for applying these WA and don't see any issues. During the discussions Dave proposed another approach. Even though these WA are called per context they are only initialized once and not changed afterwards, same set of WA are applied for each context so instead of adding them in each context, does it make sense to create a separate page and share across all contexts? but ofcourse GuC will anyway add a new page to context so I might as well share that page. Chris/Dave, do you see any problems with sharing page with GuC or you prefer to allocate a separate page for these WA and share across all contexts? Please give your comments. regards Arun ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 54/55] drm/i915: Remove the now obsolete 'i915_gem_check_olr()'
On 29/05/2015 17:44, john.c.harri...@intel.com wrote:
From: John Harrison
As there is no OLR to check, the check_olr() function is now a no-op and can be
removed.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |1 -
drivers/gpu/drm/i915/i915_gem.c | 34 +-
drivers/gpu/drm/i915/intel_display.c |6 --
3 files changed, 1 insertion(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 18bfc84..cb5bb4a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2825,7 +2825,6 @@ bool i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_requests_ring(struct intel_engine_cs *ring);
int __must_check i915_gem_check_wedge(struct i915_gpu_error *error,
bool interruptible);
-int __must_check i915_gem_check_olr(struct drm_i915_gem_request *req);
static inline bool i915_reset_in_progress(struct i915_gpu_error *error)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b8fe931..f825942 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1149,17 +1149,6 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
return 0;
}
-/*
- * Compare arbitrary request against outstanding lazy request. Emit on match.
- */
-int
-i915_gem_check_olr(struct drm_i915_gem_request *req)
-{
- WARN_ON(!mutex_is_locked(&req->ring->dev->struct_mutex));
-
- return 0;
-}
-
static void fake_irq(unsigned long data)
{
wake_up_process((struct task_struct *)data);
@@ -1440,10 +1429,6 @@ i915_wait_request(struct drm_i915_gem_request *req)
if (ret)
return ret;
- ret = i915_gem_check_olr(req);
- if (ret)
- return ret;
-
ret = __i915_wait_request(req,
atomic_read(&dev_priv->gpu_error.reset_counter),
interruptible, NULL, NULL);
@@ -1543,10 +1528,6 @@ i915_gem_object_wait_rendering__nonblocking(struct
drm_i915_gem_object *obj,
if (req == NULL)
return 0;
- ret = i915_gem_check_olr(req);
- if (ret)
- goto err;
-
requests[n++] = i915_gem_request_reference(req);
} else {
for (i = 0; i < I915_NUM_RINGS; i++) {
@@ -1556,10 +1537,6 @@ i915_gem_object_wait_rendering__nonblocking(struct
drm_i915_gem_object *obj,
if (req == NULL)
continue;
- ret = i915_gem_check_olr(req);
- if (ret)
- goto err;
-
requests[n++] = i915_gem_request_reference(req);
}
}
@@ -1570,7 +1547,6 @@ i915_gem_object_wait_rendering__nonblocking(struct
drm_i915_gem_object *obj,
NULL, rps);
mutex_lock(&dev->struct_mutex);
-err:
for (i = 0; i < n; i++) {
if (ret == 0)
i915_gem_object_retire_request(obj, requests[i]);
@@ -2987,7 +2963,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
static int
i915_gem_object_flush_active(struct drm_i915_gem_object *obj)
{
- int ret, i;
+ int i;
if (!obj->active)
return 0;
@@ -3002,10 +2978,6 @@ i915_gem_object_flush_active(struct drm_i915_gem_object
*obj)
if (list_empty(&req->list))
goto retire;
- ret = i915_gem_check_olr(req);
- if (ret)
- return ret;
-
if (i915_gem_request_completed(req, true)) {
__i915_gem_request_retire__upto(req);
retire:
@@ -3121,10 +3093,6 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
if (i915_gem_request_completed(from_req, true))
return 0;
- ret = i915_gem_check_olr(from_req);
- if (ret)
- return ret;
-
if (!i915_semaphore_is_enabled(obj->base.dev)) {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
ret = __i915_wait_request(from_req,
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 91e19d0..aca2215 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11243,12 +11243,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
i915_gem_request_assign(&work->flip_queued_req,
obj->last_write_req);
} else {
- if (obj->last_write_req) {
- ret = i915_gem_check_olr(obj->last_write_req);
- if (ret)
- goto cleanup_unpin;
- }
-
Re: [Intel-gfx] [PATCH 55/55] drm/i915: Rename the somewhat reduced i915_gem_object_flush_active()
On 29/05/2015 17:44, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_gem_object_flush_active() call used to do lots. Over time it has done
less and less. Now all it does check the various associated requests to see if
they can be retired. Hence this patch renames the function and updates the
comments around it to match the current operation.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f825942..081cbbf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2956,12 +2956,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
}
/**
- * Ensures that an object will eventually get non-busy by flushing any required
- * write domains, emitting any outstanding lazy request and retiring and
- * completed requests.
+ * Check an object to see if any of it's associated requests can be retired.
*/
static int
-i915_gem_object_flush_active(struct drm_i915_gem_object *obj)
+i915_gem_object_retire(struct drm_i915_gem_object *obj)
{
int i;
@@ -3034,8 +3032,8 @@ i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
return -ENOENT;
}
- /* Need to make sure the object gets inactive eventually. */
- ret = i915_gem_object_flush_active(obj);
+ /* Check if the object is pending clean up. */
+ ret = i915_gem_object_retire(obj);
if (ret)
goto out;
@@ -4526,12 +4524,8 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
goto unlock;
}
- /* Count all active objects as busy, even if they are currently not used
-* by the gpu. Users of this interface expect objects to eventually
-* become non-busy without any further actions, therefore emit any
-* necessary flushes here.
-*/
- ret = i915_gem_object_flush_active(obj);
+ /* Check if the object is pending clean up. */
+ ret = i915_gem_object_retire(obj);
if (ret)
goto unref;
Reviewed-by: Tomas Elf
Thanks,
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/55] drm/i915: Update i915_gem_object_sync() to take a request structure
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
v2: Much more complex patch to share a single request between the sync and the
page flip. The _sync() function now supports lazy allocation of the request
structure. That is, if one is passed in then that will be used. If one is not,
then a request will be allocated and passed back out. Note that the _sync() code
does not necessarily require a request. Thus one will only be created until
certain situations. The reason the lazy allocation must be done within the
_sync() code itself is because the decision to need one or not is not really
something that code above can second guess (except in the case where one is
definitely not required because no ring is passed in).
The call chains above _sync() now support passing a request through which most
callers passing in NULL and assuming that no request will be required (because
they also pass in NULL for the ring and therefore can't be generating any ring
code).
The exeception is intel_crtc_page_flip() which now supports having a request
1. "The exeception" -> "The exception"
returned from _sync(). If one is, then that request is shared by the page flip
(if the page flip is of a type to need a request). If _sync() does not generate
a request but the page flip does need one, then the page flip path will create
its own request.
v3: Updated comment description to be clearer about 'to_req' parameter (Tomas
Elf review request). Rebased onto newer tree that significantly changed the
synchronisation code.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h|4 ++-
drivers/gpu/drm/i915/i915_gem.c| 48 +---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/intel_display.c | 17 +++---
drivers/gpu/drm/i915/intel_drv.h |3 +-
drivers/gpu/drm/i915/intel_fbdev.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
drivers/gpu/drm/i915/intel_overlay.c |2 +-
8 files changed, 58 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64a10fa..f69e9cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2778,7 +2778,8 @@ static inline void i915_gem_object_unpin_pages(struct
drm_i915_gem_object *obj)
int __must_check i915_mutex_lock_interruptible(struct drm_device *dev);
int i915_gem_object_sync(struct drm_i915_gem_object *obj,
-struct intel_engine_cs *to);
+struct intel_engine_cs *to,
+struct drm_i915_gem_request **to_req);
void i915_vma_move_to_active(struct i915_vma *vma,
struct intel_engine_cs *ring);
int i915_gem_dumb_create(struct drm_file *file_priv,
@@ -2889,6 +2890,7 @@ int __must_check
i915_gem_object_pin_to_display_plane(struct drm_i915_gem_object *obj,
u32 alignment,
struct intel_engine_cs *pipelined,
+struct drm_i915_gem_request
**pipelined_request,
const struct i915_ggtt_view *view);
void i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view
*view);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b7d66aa..db90043 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3098,25 +3098,26 @@ out:
static int
__i915_gem_object_sync(struct drm_i915_gem_object *obj,
struct intel_engine_cs *to,
- struct drm_i915_gem_request *req)
+ struct drm_i915_gem_request *from_req,
+ struct drm_i915_gem_request **to_req)
{
struct intel_engine_cs *from;
int ret;
- from = i915_gem_request_get_ring(req);
+ from = i915_gem_request_get_ring(from_req);
if (to == from)
return 0;
- if (i915_gem_request_completed(req, true))
+ if (i915_gem_request_completed(from_req, true))
return 0;
- ret = i915_gem_check_olr(req);
+ ret = i915_gem_check_olr(from_req);
if (ret)
return ret;
if (!i915_semaphore_is_enabled(obj->base.dev)) {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
- ret = __i915_wait_request(req,
+ ret = __i915_wait_request(from_req,
atomic_read(&i915->gpu_error.reset_counter),
i915->mm.interruptible,
Re: [Intel-gfx] [PATCH 22/55] drm/i915: Update deferred context creation to do explicit request management
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, context initialisation is deferred until first use of the
given context. This is because execlist mode has per ring context state and thus
many more context storage objects than legacy mode and many are never actually
used. Previously, the initialisation commands were written to the ring and
tagged with some random request structure via the OLR. This seemed to be causing
a null pointer deference bug under certain circumstances (BZ:88865).
This patch adds explicit request creation and submission to the deferred
initialisation code path. Thus removing any reliance on or randomness caused by
the OLR.
Note that it should be possible to move the deferred context creation until even
later - when the context is actually switched to rather than when it is merely
validated. This would allow the initialisation to be done within the request of
the work that is wanting to use the context. Hence, the extra request that is
created, used and retired just for the context init could be removed completely.
However, this is left for a follow up patch.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_lrc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 37efa93..2730efd 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1971,13 +1971,22 @@ int intel_lr_context_deferred_create(struct
intel_context *ctx,
lrc_setup_hardware_status_page(ring, ctx_obj);
else if (ring->id == RCS && !ctx->rcs_initialized) {
if (ring->init_context) {
- ret = ring->init_context(ring, ctx);
+ struct drm_i915_gem_request *req;
+
+ ret = i915_gem_request_alloc(ring, ctx, &req);
+ if (ret)
+ return ret;
+
+ ret = ring->init_context(req->ring, ctx);
if (ret) {
DRM_ERROR("ring init context: %d\n", ret);
+ i915_gem_request_cancel(req);
ctx->engine[ring->id].ringbuf = NULL;
ctx->engine[ring->id].state = NULL;
goto error;
}
+
+ i915_add_request_no_flush(req->ring);
}
ctx->rcs_initialized = true;
Reviewed-by: Tomas Elf
Thanks,
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/9] drm/i915: Enable default_phase in GCP when possible
> > > @@ -560,6 +560,49 @@ static bool hdmi_sink_is_deep_color(struct
> > > drm_encoder *encoder)
> > > return false;
> > > }
> > >
> > > +/*
> > > + * Determine if default_phase=1 can be indicated in the GCP infoframe.
> > > + *
> > > + * From HDMI specification 1.4a:
> > > + * - The first pixel of each Video Data Period shall always have a
> > > +pixel packing phase of 0
> > > + * - The first pixel following each Video Data Period shall have a
> > > +pixel packing phase of 0
> > > + * - The PP bits shall be constant for all GCPs and will be equal to
> > > +the last packing phase
> > > + * - The first pixel following every transition of HSYNC or VSYNC shall
> > > have a
> > > pixel packing
> > > + * phase of 0
> > > + */
> > > +static bool gcp_default_phase_possible(int pipe_bpp,
> > > +const struct drm_display_mode *mode) {
> > > + unsigned int pixels_per_group;
> > > +
> > > + switch (pipe_bpp) {
> > > + case 30:
> > > + /* 4 pixels in 5 clocks */
> > > + pixels_per_group = 4;
> > > + break;
> > > + case 36:
> > > + /* 2 pixels in 3 clocks */
> > > + pixels_per_group = 2;
> > > + break;
> > > + case 48:
> > > + /* 1 pixel in 2 clocks */
> > > + pixels_per_group = 1;
> > > + break;
> > > + default:
> > > + /* phase information not relevant for 8bpc */
> > > + return false;
> > > + }
> > > +
> > > + return mode->crtc_hdisplay % pixels_per_group == 0 &&
> > > + mode->crtc_htotal % pixels_per_group == 0 &&
> > > + mode->crtc_hblank_start % pixels_per_group == 0 &&
> > > + mode->crtc_hblank_end % pixels_per_group == 0 &&
> > > + mode->crtc_hsync_start % pixels_per_group == 0 &&
> > > + mode->crtc_hsync_end % pixels_per_group == 0 &&
> >
> > For hsync, bspec says Hsync is an even number.
> > Isn't it above check should be something like (hsync_end - hsync_start) % 2
> > ==
> 0?
> > And similarly for front & back porches, right?
>
> If X and Y are even then (X - Y) is even too. Also the text in bspec is
> less informative than the text in HDMI spec, which is why I quited the
> HDMI spec instead.
Sure, if X and Y are even X - Y is even, but it is more restrictive check than
needed. Because if both X and Y are odd, X - Y is even, and in that case
above code doesn't allow to use default phase. Which may be OK, but
it didn't truly allow default phase when possible.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/55] drm/i915: Add explicit request management to i915_gem_init_hw()
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable call
eventually ends up within *_render_state_init() and this does its own private
_i915_add_request() call.
This patch adds explicit request creation and submission to the top level loop
and removes the add_request() from deep within the sub-functions.
v2: Updated for removal of batch_obj from add_request call in previous patch.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |3 ++-
drivers/gpu/drm/i915/i915_gem.c | 12
drivers/gpu/drm/i915/i915_gem_render_state.c |2 --
drivers/gpu/drm/i915/intel_lrc.c |5 -
4 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 69c8f56..21045e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2154,7 +2154,8 @@ struct drm_i915_gem_request {
struct intel_context *ctx;
struct intel_ringbuffer *ringbuf;
- /** Batch buffer related to this request if any */
+ /** Batch buffer related to this request if any (used for
+ error state dump only) */
struct drm_i915_gem_object *batch_obj;
/** Time at which this request was emitted, in jiffies. */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a2712a6..1960e30 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5073,8 +5073,16 @@ i915_gem_init_hw(struct drm_device *dev)
/* Now it is safe to go back round and do everything else: */
for_each_ring(ring, dev_priv, i) {
+ struct drm_i915_gem_request *req;
+
WARN_ON(!ring->default_context);
+ ret = i915_gem_request_alloc(ring, ring->default_context, &req);
+ if (ret) {
+ i915_gem_cleanup_ringbuffer(dev);
+ goto out;
+ }
+
if (ring->id == RCS) {
for (i = 0; i < NUM_L3_SLICES(dev); i++)
i915_gem_l3_remap(ring, i);
@@ -5083,6 +5091,7 @@ i915_gem_init_hw(struct drm_device *dev)
ret = i915_ppgtt_init_ring(ring);
if (ret && ret != -EIO) {
DRM_ERROR("PPGTT enable ring #%d failed %d\n", i, ret);
+ i915_gem_request_cancel(req);
i915_gem_cleanup_ringbuffer(dev);
goto out;
}
@@ -5090,9 +5099,12 @@ i915_gem_init_hw(struct drm_device *dev)
ret = i915_gem_context_enable(ring);
if (ret && ret != -EIO) {
DRM_ERROR("Context enable ring #%d failed %d\n", i,
ret);
+ i915_gem_request_cancel(req);
i915_gem_cleanup_ringbuffer(dev);
goto out;
}
+
+ i915_add_request_no_flush(ring);
}
out:
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index a32a4b9..a07b4ee 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -173,8 +173,6 @@ int i915_gem_render_state_init(struct intel_engine_cs *ring)
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
- __i915_add_request(ring, NULL, NULL, true);
- /* __i915_add_request moves object to inactive if it fails */
out:
i915_gem_render_state_fini(&so);
return ret;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c744362..37efa93 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1351,8 +1351,6 @@ static int intel_lr_context_render_state_init(struct
intel_engine_cs *ring,
{
struct intel_ringbuffer *ringbuf = ctx->engine[ring->id].ringbuf;
struct render_state so;
- struct drm_i915_file_private *file_priv = ctx->file_priv;
- struct drm_file *file = file_priv ? file_priv->file : NULL;
int ret;
ret = i915_gem_render_state_prepare(ring, &so);
@@ -1371,9 +1369,6 @@ static int intel_lr_context_render_state_init(struct
intel_engine_cs *ring,
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
- __i915_add_request(ring, file, NULL, true);
- /* intel_logical_ring_add_request moves object to inactive if it
-* fails */
out:
i915_gem_render_state_fini(&so);
return ret;
Reviewed-by: Tomas Elf
Thanks,
Tomas
___
Intel-gfx mailing list
Intel-gfx@lists.freedes
Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Disable all infoframes when turning off the HDMI port
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Tuesday, June 02, 2015 4:11 AM
> To: Konduru, Chandra
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Disable all infoframes when
> turning off the HDMI port
>
> On Mon, Jun 01, 2015 at 10:48:03PM +, Konduru, Chandra wrote:
> >
> >
> > > -Original Message-
> > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of
> > > ville.syrj...@linux.intel.com
> > > Sent: Tuesday, May 05, 2015 7:06 AM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] [PATCH v2 6/9] drm/i915: Disable all infoframes when
> > > turning off the HDMI port
> > >
> > > From: Ville Syrjälä
> > >
> > > Currently we just disable the GCP infoframe when turning off the port.
> > > That means if the same transcoder is used on a DP port next, we might
> > > end up pushing infoframes over DP, which isn't intended. Just disable
> >
> > Wonder how it is working. May be it is ok, or never hit using a previously
> > used transcoder for HDMI port for DP.
> >
> > By the way, you mean end up pushing "other" infoframes over DP?
>
> We don't send infoframes over DP at all currently. Or I should say we
> never intended to send them. After this patch that should even be true.
> Well, unless the BIOS already enables them and we just fire up a DP port
> using the transcoder in question. So I suppose we should really have the
> DP code clear the infoframe settings explicitly, or we should clear them
> during the sanitize phase.
Agree that DP code path should clear the infoframe settings explicitly.
As you are already touching this code, will you plan to handle it?
Once it is taken care, it gets
Reviewed-by: Chandra Konduru
>
> >
> > > all the infoframes when turning off the port.
> > >
> > > Also protect against two ports stomping on each other on g4x due to
> > > the single video DIP instance. Now only the first port to enable
> > > gets to send infoframes.
> >
> > So is, 2nd port doesn't gets to send infoframes, the expected behavior
> > when two ports trying with a single DIP?
>
> I'm not sure what's the best behaviour here. Either we somehow pick one
> of the ports to send infoframes (first come first serve in this patch),
> or we could just disable infoframes entirely for cloned cases. But it's
> probably a rare configuration anyway since HDMI cloning is only allowed
> on g4x.
I am fine with what you outlined above. If anything come up, this can be
revisited.
>
> >
> > Seems like a corner case to test thoroughly. Is this path exercised in your
> testing?
>
> I tested it long ago. Although I must admit that the patch looked a bit
> different back then.
>
> >
> > >
> > > v2: Rebase
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/intel_hdmi.c | 85
> > > ++-
>
> > > 1 file changed, 40 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 766bdb1..03b4759 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -514,7 +514,13 @@ static void g4x_set_infoframes(struct drm_encoder
> > > *encoder,
> > > if (!enable) {
> > > if (!(val & VIDEO_DIP_ENABLE))
> > > return;
> > > - val &= ~VIDEO_DIP_ENABLE;
> > > + if (port != (val & VIDEO_DIP_PORT_MASK)) {
> > > + DRM_DEBUG_KMS("video DIP still enabled on port
> > > %c\n",
> > > + (val & VIDEO_DIP_PORT_MASK) >> 29);
> > > + return;
> > > + }
> > > + val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI |
> > > + VIDEO_DIP_ENABLE_VENDOR |
> > > VIDEO_DIP_ENABLE_SPD);
> > > I915_WRITE(reg, val);
> > > POSTING_READ(reg);
> > > return;
> > > @@ -522,16 +528,17 @@ static void g4x_set_infoframes(struct
> drm_encoder
> > > *encoder,
> > >
> > > if (port != (val & VIDEO_DIP_PORT_MASK)) {
> > > if (val & VIDEO_DIP_ENABLE) {
> > > - val &= ~VIDEO_DIP_ENABLE;
> > > - I915_WRITE(reg, val);
> > > - POSTING_READ(reg);
> > > + DRM_DEBUG_KMS("video DIP already enabled on port
> > > %c\n",
> > > + (val & VIDEO_DIP_PORT_MASK) >> 29);
> > > + return;
> > > }
> > > val &= ~VIDEO_DIP_PORT_MASK;
> > > val |= port;
> > > }
> > >
> > > val |= VIDEO_DIP_ENABLE;
> > > - val &= ~VIDEO_DIP_ENABLE_VENDOR;
> > > + val &= ~(VIDEO_DIP_ENABLE_AVI |
> > > + VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
> > >
> > > I915_WRITE(reg, val);
> > > POSTING_READ(reg);
> > > @@ -632,23 +639,6 @@ static bool intel_hdmi_set_gcp_infoframe(struct
> > > drm_encoder *encoder)
> > > return val != 0;
> > > }
> > >
> > >
Re: [Intel-gfx] [PATCH 13/55] drm/i915: Add flag to i915_add_request() to skip the cache flush
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
In order to explcitly track all GPU work (and completely remove the outstanding
lazy request), it is necessary to add extra i915_add_request() calls to various
places. Some of these do not need the implicit cache flush done as part of the
standard batch buffer submission process.
This patch adds a flag to _add_request() to specify whether the flush is
required or not.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |7 +--
drivers/gpu/drm/i915/i915_gem.c | 17 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/i915_gem_render_state.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
5 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cc2c45c..f5a733b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2863,9 +2863,12 @@ int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_suspend(struct drm_device *dev);
void __i915_add_request(struct intel_engine_cs *ring,
struct drm_file *file,
- struct drm_i915_gem_object *batch_obj);
+ struct drm_i915_gem_object *batch_obj,
+ bool flush_caches);
#define i915_add_request(ring) \
- __i915_add_request(ring, NULL, NULL)
+ __i915_add_request(ring, NULL, NULL, true)
+#define i915_add_request_no_flush(ring) \
+ __i915_add_request(ring, NULL, NULL, false)
int __i915_wait_request(struct drm_i915_gem_request *req,
unsigned reset_counter,
bool interruptible,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ba2e7f7..458b54e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2470,7 +2470,8 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
*/
void __i915_add_request(struct intel_engine_cs *ring,
struct drm_file *file,
- struct drm_i915_gem_object *obj)
+ struct drm_i915_gem_object *obj,
+ bool flush_caches)
{
struct drm_i915_private *dev_priv = ring->dev->dev_private;
struct drm_i915_gem_request *request;
@@ -2502,12 +2503,14 @@ void __i915_add_request(struct intel_engine_cs *ring,
* is that the flush _must_ happen before the next request, no matter
* what.
*/
- if (i915.enable_execlists)
- ret = logical_ring_flush_all_caches(ringbuf, request->ctx);
- else
- ret = intel_ring_flush_all_caches(ring);
- /* Not allowed to fail! */
- WARN(ret, "*_ring_flush_all_caches failed: %d!\n", ret);
+ if (flush_caches) {
+ if (i915.enable_execlists)
+ ret = logical_ring_flush_all_caches(ringbuf,
request->ctx);
+ else
+ ret = intel_ring_flush_all_caches(ring);
+ /* Not allowed to fail! */
+ WARN(ret, "*_ring_flush_all_caches failed: %d!\n", ret);
+ }
/* Record the position of the start of the request so that
* should we detect the updated seqno part-way through the
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index a6532db..e27f47f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1058,7 +1058,7 @@ i915_gem_execbuffer_retire_commands(struct
i915_execbuffer_params *params)
params->ring->gpu_caches_dirty = true;
/* Add a breadcrumb for the completion of the batch buffer */
- __i915_add_request(params->ring, params->file, params->batch_obj);
+ __i915_add_request(params->ring, params->file, params->batch_obj, true);
}
static int
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index ce4788f..4418616 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -173,7 +173,7 @@ int i915_gem_render_state_init(struct intel_engine_cs *ring)
i915_vma_move_to_active(i915_gem_obj_to_ggtt(so.obj), ring);
- __i915_add_request(ring, NULL, so.obj);
+ __i915_add_request(ring, NULL, so.obj, true);
/* __i915_add_request moves object to inactive if it fails */
out:
i915_gem_render_state_fini(&so);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 6c0b16f..00bb335 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1371,7 +1371,7 @@ static int intel_lr_context_render_state_init(struct
intel_engine_cs *ring,
i915_vma_move_to_activ
Re: [Intel-gfx] [PATCH 03/55] drm/i915: i915_add_request must not fail
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_add_request() function is called to keep track of work that has been
written to the ring buffer. It adds epilogue commands to track progress (seqno
updates and such), moves the request structure onto the right list and other
such house keeping tasks. However, the work itself has already been written to
the ring and will get executed whether or not the add request call succeeds. So
no matter what goes wrong, there isn't a whole lot of point in failing the call.
At the moment, this is fine(ish). If the add request does bail early on and not
do the housekeeping, the request will still float around in the
ring->outstanding_lazy_request field and be picked up next time. It means
multiple pieces of work will be tagged as the same request and driver can't
actually wait for the first piece of work until something else has been
submitted. But it all sort of hangs together.
This patch series is all about removing the OLR and guaranteeing that each piece
of work gets its own personal request. That means that there is no more
'hoovering up of forgotten requests'. If the request does not get tracked then
it will be leaked. Thus the add request call _must_ not fail. The previous patch
should have already ensured that it _will_ not fail by removing the potential
for running out of ring space. This patch enforces the rule by actually removing
the early exit paths and the return code.
Note that if something does manage to fail and the epilogue commands don't get
written to the ring, the driver will still hang together. The request will be
added to the tracking lists. And as in the old case, any subsequent work will
generate a new seqno which will suffice for marking the old one as complete.
v2: Improved WARNings (Tomas Elf review request).
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |6 ++--
drivers/gpu/drm/i915/i915_gem.c | 43 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/i915_gem_render_state.c |2 +-
drivers/gpu/drm/i915/intel_lrc.c |2 +-
drivers/gpu/drm/i915/intel_overlay.c |8 ++---
drivers/gpu/drm/i915/intel_ringbuffer.c |8 ++---
7 files changed, 31 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eba1857..1be4a52 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2860,9 +2860,9 @@ void i915_gem_init_swizzling(struct drm_device *dev);
void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_suspend(struct drm_device *dev);
-int __i915_add_request(struct intel_engine_cs *ring,
- struct drm_file *file,
- struct drm_i915_gem_object *batch_obj);
+void __i915_add_request(struct intel_engine_cs *ring,
+ struct drm_file *file,
+ struct drm_i915_gem_object *batch_obj);
#define i915_add_request(ring) \
__i915_add_request(ring, NULL, NULL)
int __i915_wait_request(struct drm_i915_gem_request *req,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6f51416..dd39aa5 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1155,15 +1155,12 @@ i915_gem_check_wedge(struct i915_gpu_error *error,
int
i915_gem_check_olr(struct drm_i915_gem_request *req)
{
- int ret;
-
WARN_ON(!mutex_is_locked(&req->ring->dev->struct_mutex));
- ret = 0;
if (req == req->ring->outstanding_lazy_request)
- ret = i915_add_request(req->ring);
+ i915_add_request(req->ring);
- return ret;
+ return 0;
}
i915_gem_check_olr never returns anything but 0. How about making it void?
Thanks,
Tomas
static void fake_irq(unsigned long data)
@@ -2466,9 +2463,14 @@ i915_gem_get_seqno(struct drm_device *dev, u32 *seqno)
return 0;
}
-int __i915_add_request(struct intel_engine_cs *ring,
- struct drm_file *file,
- struct drm_i915_gem_object *obj)
+/*
+ * NB: This function is not allowed to fail. Doing so would mean the the
+ * request is not being tracked for completion but the work itself is
+ * going to happen on the hardware. This would be a Bad Thing(tm).
+ */
+void __i915_add_request(struct intel_engine_cs *ring,
+ struct drm_file *file,
+ struct drm_i915_gem_object *obj)
{
struct drm_i915_private *dev_priv = ring->dev->dev_private;
struct drm_i915_gem_request *request;
@@ -2478,7 +2480,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
request = ring->outstanding_lazy_request;
if (WARN_ON(request == NULL))
- return -ENOMEM;
Re: [Intel-gfx] [PATCH 02/55] drm/i915: Reserve ring buffer space for i915_add_request() commands
On 29/05/2015 17:43, john.c.harri...@intel.com wrote:
From: John Harrison
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the ring (cache flushing, seqno updates, interrupt signalling). The
reasons for that are mostly down to running out of ring buffer space and the
problems associated with trying to get some more. This patch prevents that
situation from happening in the first place.
When a request is created, it marks sufficient space as reserved for the
epilogue commands. Thus guaranteeing that by the time the epilogue is written,
there will be plenty of space for it. Note that a ring_begin() call is required
to actually reserve the space (and do any potential waiting). However, that is
not currently done at request creation time. This is because the ring_begin()
code can allocate a request. Hence calling begin() from the request allocation
code would lead to infinite recursion! Later patches in this series remove the
need for begin() to do the allocate. At that point, it becomes safe for the
allocate to call begin() and really reserve the space.
Until then, there is a potential for insufficient space to be available at the
point of calling i915_add_request(). However, that would only be in the case
where the request was created and immediately submitted without ever calling
ring_begin() and adding any work to that request. Which should never happen. And
even if it does, and if that request happens to fall down the tiny window of
opportunity for failing due to being out of ring space then does it really
matter because the request wasn't doing anything in the first place?
v2: Updated the 'reserved space too small' warning to include the offending
sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
re-initialisation of tracking state after a buffer wrap to keep the sanity
checks accurate.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_gem.c | 37 +
drivers/gpu/drm/i915/intel_lrc.c|9
drivers/gpu/drm/i915/intel_ringbuffer.c | 68 ++-
drivers/gpu/drm/i915/intel_ringbuffer.h | 10 +
5 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0347eb9..eba1857 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2187,6 +2187,7 @@ struct drm_i915_gem_request {
int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct intel_context *ctx);
+void i915_gem_request_cancel(struct drm_i915_gem_request *req);
void i915_gem_request_free(struct kref *req_ref);
static inline uint32_t
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 68f1d1e..6f51416 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2485,6 +2485,13 @@ int __i915_add_request(struct intel_engine_cs *ring,
} else
ringbuf = ring->buffer;
+ /*
+* To ensure that this call will not fail, space for its emissions
+* should already have been reserved in the ring buffer. Let the ring
+* know that it is time to use that space up.
+*/
+ intel_ring_reserved_space_use(ringbuf);
+
request_start = intel_ring_get_tail(ringbuf);
/*
* Emit any outstanding flushes - execbuf can fail to emit the flush
@@ -2567,6 +2574,9 @@ int __i915_add_request(struct intel_engine_cs *ring,
round_jiffies_up_relative(HZ));
intel_mark_busy(dev_priv->dev);
+ /* Sanity check that the reserved size was large enough. */
+ intel_ring_reserved_space_end(ringbuf);
+
return 0;
}
@@ -2666,6 +2676,26 @@ int i915_gem_request_alloc(struct intel_engine_cs *ring,
if (ret)
goto err;
+ /*
+* Reserve space in the ring buffer for all the commands required to
+* eventually emit this request. This is to guarantee that the
+* i915_add_request() call can't fail. Note that the reserve may need
+* to be redone if the request is not actually submitted straight
+* away, e.g. because a GPU scheduler has deferred it.
+*
+* Note further that this call merely notes the reserve request. A
+* subsequent call to *_ring_begin() is required to actually ensure
+* that the reservation is available. Without the begin, if the
+* request creator immediately submitted the request without adding
+* any commands to it then there might not actually be sufficient
+* room for the submission commands. Unfortunately, the current
+
Re: [Intel-gfx] [PATCH] drm/i915: Include G4X/VLV/CHV in self refresh status
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6522 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Fix DDC probe for passive adapters
On Tue, 02 Jun 2015, Ville Syrjälä wrote:
> On Tue, Jun 02, 2015 at 07:21:15PM +0300, Jani Nikula wrote:
>> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
>> devices, as they do not have a sink device in them to respond to any AUX
>> traffic. When probing these dongles over the DDC, sometimes they will
>> NAK the first attempt even though the transaction is valid and they
>> support the DDC protocol. The retry loop inside of
>> drm_do_probe_ddc_edid() would normally catch this case and try the
>> transaction again, resulting in success.
>>
>> That, however, was thwarted by the fix for [1]:
>>
>> commit 9292f37e1f5c79400254dca46f83313488093825
>> Author: Eugeni Dodonov
>> Date: Thu Jan 5 09:34:28 2012 -0200
>>
>> drm: give up on edid retries when i2c bus is not responding
>>
>> This added code to exit immediately if the return code from the
>> i2c_transfer function was -ENXIO in order to reduce the amount of time
>> spent in waiting for unresponsive or disconnected devices. That was
>> possible because the underlying i2c bit banging algorithm had retries of
>> its own (which, of course, were part of the reason for the bug the
>> commit fixes).
>>
>> Since its introduction in
>>
>> commit f899fc64cda8569d0529452aafc0da31c042df2e
>> Author: Chris Wilson
>> Date: Tue Jul 20 15:44:45 2010 -0700
>>
>> drm/i915: use GMBUS to manage i2c links
>>
>> we've been flipping back and forth enabling the GMBUS transfers, but
>> we've settled since then. The GMBUS implementation does not do any
>> retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
>> on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
>> the retry on -ENXIO.
>>
>> Retry GMBUS once on -ENXIO on first message to mitigate the issues with
>> passive adapters.
>>
>> This patch is based on the work, and commit message, by Todd Previte
>> .
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
>>
>> v2: Don't retry if using bit banging.
>>
>> v3: Move retry within gmbux_xfer, retry only on first message.
>>
>> v4: Initialize GMBUS0 on retry (Ville).
>>
>> v5: Take index reads into account (Ville).
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
>> Cc: Todd Previte
>> Cc: sta...@vger.kernel.org
>> Signed-off-by: Jani Nikula
>
> OK, I think I'm done shooting any more holes into this one:
> Reviewed-by: Ville Syrjälä
\o/
Thanks for all the review. I suck.
> Hopefully it works too. I don't have very good intuition into the gmbus
> hardware. I think one day I need to set up a bit-banged i2c slave and
> play around with it just for fun.
AFAICT it should be functionally equivalent to the v1 patch that got
tested in the referenced bug. I'm hoping to get a test result for this
one too.
>
>> ---
>> drivers/gpu/drm/i915/intel_i2c.c | 20 +---
>> 1 file changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
>> b/drivers/gpu/drm/i915/intel_i2c.c
>> index 92072f56e418..a64f26c670af 100644
>> --- a/drivers/gpu/drm/i915/intel_i2c.c
>> +++ b/drivers/gpu/drm/i915/intel_i2c.c
>> @@ -486,7 +486,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
>> struct intel_gmbus,
>> adapter);
>> struct drm_i915_private *dev_priv = bus->dev_priv;
>> -int i, reg_offset;
>> +int i = 0, inc, try = 0, reg_offset;
>> int ret = 0;
>>
>> intel_aux_display_runtime_get(dev_priv);
>> @@ -499,12 +499,14 @@ gmbus_xfer(struct i2c_adapter *adapter,
>>
>> reg_offset = dev_priv->gpio_mmio_base;
>>
>> +retry:
>> I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
>>
>> -for (i = 0; i < num; i++) {
>> +for (; i < num; i += inc) {
>> +inc = 1;
>> if (gmbus_is_index_read(msgs, i, num)) {
>> ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
>> -i += 1; /* set i to the index of the read xfer */
>> +inc = 2; /* an index read is two msgs */
>> } else if (msgs[i].flags & I2C_M_RD) {
>> ret = gmbus_xfer_read(dev_priv, &msgs[i], 0);
>> } else {
>> @@ -576,6 +578,18 @@ clear_err:
>> adapter->name, msgs[i].addr,
>> (msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
>>
>> +/*
>> + * Passive adapters sometimes NAK the first probe. Retry the first
>> + * message once on -ENXIO for GMBUS transfers; the bit banging algorithm
>> + * has retries internally. See also the retry loop in
>> + * drm_do_probe_ddc_edid, which bails out on the first -ENXIO.
>> + */
>> +if (ret == -ENXIO && i == 0 && try++ == 0) {
>> +DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
>> + adapter->name);
>> +goto retry;
>> +}
>> +
>> goto out;
>>
>> timeout:
>> --
>> 2.1.4
>
Re: [Intel-gfx] [PATCH v5] drm/i915: Fix DDC probe for passive adapters
On Tue, Jun 02, 2015 at 07:21:15PM +0300, Jani Nikula wrote:
> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
> devices, as they do not have a sink device in them to respond to any AUX
> traffic. When probing these dongles over the DDC, sometimes they will
> NAK the first attempt even though the transaction is valid and they
> support the DDC protocol. The retry loop inside of
> drm_do_probe_ddc_edid() would normally catch this case and try the
> transaction again, resulting in success.
>
> That, however, was thwarted by the fix for [1]:
>
> commit 9292f37e1f5c79400254dca46f83313488093825
> Author: Eugeni Dodonov
> Date: Thu Jan 5 09:34:28 2012 -0200
>
> drm: give up on edid retries when i2c bus is not responding
>
> This added code to exit immediately if the return code from the
> i2c_transfer function was -ENXIO in order to reduce the amount of time
> spent in waiting for unresponsive or disconnected devices. That was
> possible because the underlying i2c bit banging algorithm had retries of
> its own (which, of course, were part of the reason for the bug the
> commit fixes).
>
> Since its introduction in
>
> commit f899fc64cda8569d0529452aafc0da31c042df2e
> Author: Chris Wilson
> Date: Tue Jul 20 15:44:45 2010 -0700
>
> drm/i915: use GMBUS to manage i2c links
>
> we've been flipping back and forth enabling the GMBUS transfers, but
> we've settled since then. The GMBUS implementation does not do any
> retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
> on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
> the retry on -ENXIO.
>
> Retry GMBUS once on -ENXIO on first message to mitigate the issues with
> passive adapters.
>
> This patch is based on the work, and commit message, by Todd Previte
> .
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
>
> v2: Don't retry if using bit banging.
>
> v3: Move retry within gmbux_xfer, retry only on first message.
>
> v4: Initialize GMBUS0 on retry (Ville).
>
> v5: Take index reads into account (Ville).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
> Cc: Todd Previte
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula
OK, I think I'm done shooting any more holes into this one:
Reviewed-by: Ville Syrjälä
Hopefully it works too. I don't have very good intuition into the gmbus
hardware. I think one day I need to set up a bit-banged i2c slave and
play around with it just for fun.
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 92072f56e418..a64f26c670af 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -486,7 +486,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
> struct intel_gmbus,
> adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
> - int i, reg_offset;
> + int i = 0, inc, try = 0, reg_offset;
> int ret = 0;
>
> intel_aux_display_runtime_get(dev_priv);
> @@ -499,12 +499,14 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> reg_offset = dev_priv->gpio_mmio_base;
>
> +retry:
> I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
>
> - for (i = 0; i < num; i++) {
> + for (; i < num; i += inc) {
> + inc = 1;
> if (gmbus_is_index_read(msgs, i, num)) {
> ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
> - i += 1; /* set i to the index of the read xfer */
> + inc = 2; /* an index read is two msgs */
> } else if (msgs[i].flags & I2C_M_RD) {
> ret = gmbus_xfer_read(dev_priv, &msgs[i], 0);
> } else {
> @@ -576,6 +578,18 @@ clear_err:
>adapter->name, msgs[i].addr,
>(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
>
> + /*
> + * Passive adapters sometimes NAK the first probe. Retry the first
> + * message once on -ENXIO for GMBUS transfers; the bit banging algorithm
> + * has retries internally. See also the retry loop in
> + * drm_do_probe_ddc_edid, which bails out on the first -ENXIO.
> + */
> + if (ret == -ENXIO && i == 0 && try++ == 0) {
> + DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
> + adapter->name);
> + goto retry;
> + }
> +
> goto out;
>
> timeout:
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5] drm/i915: Fix DDC probe for passive adapters
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC protocol. The retry loop inside of
drm_do_probe_ddc_edid() would normally catch this case and try the
transaction again, resulting in success.
That, however, was thwarted by the fix for [1]:
commit 9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov
Date: Thu Jan 5 09:34:28 2012 -0200
drm: give up on edid retries when i2c bus is not responding
This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time
spent in waiting for unresponsive or disconnected devices. That was
possible because the underlying i2c bit banging algorithm had retries of
its own (which, of course, were part of the reason for the bug the
commit fixes).
Since its introduction in
commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
we've been flipping back and forth enabling the GMBUS transfers, but
we've settled since then. The GMBUS implementation does not do any
retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
the retry on -ENXIO.
Retry GMBUS once on -ENXIO on first message to mitigate the issues with
passive adapters.
This patch is based on the work, and commit message, by Todd Previte
.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
v2: Don't retry if using bit banging.
v3: Move retry within gmbux_xfer, retry only on first message.
v4: Initialize GMBUS0 on retry (Ville).
v5: Take index reads into account (Ville).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
Cc: Todd Previte
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 92072f56e418..a64f26c670af 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -486,7 +486,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct intel_gmbus,
adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
- int i, reg_offset;
+ int i = 0, inc, try = 0, reg_offset;
int ret = 0;
intel_aux_display_runtime_get(dev_priv);
@@ -499,12 +499,14 @@ gmbus_xfer(struct i2c_adapter *adapter,
reg_offset = dev_priv->gpio_mmio_base;
+retry:
I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
- for (i = 0; i < num; i++) {
+ for (; i < num; i += inc) {
+ inc = 1;
if (gmbus_is_index_read(msgs, i, num)) {
ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
- i += 1; /* set i to the index of the read xfer */
+ inc = 2; /* an index read is two msgs */
} else if (msgs[i].flags & I2C_M_RD) {
ret = gmbus_xfer_read(dev_priv, &msgs[i], 0);
} else {
@@ -576,6 +578,18 @@ clear_err:
adapter->name, msgs[i].addr,
(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
+ /*
+* Passive adapters sometimes NAK the first probe. Retry the first
+* message once on -ENXIO for GMBUS transfers; the bit banging algorithm
+* has retries internally. See also the retry loop in
+* drm_do_probe_ddc_edid, which bails out on the first -ENXIO.
+*/
+ if (ret == -ENXIO && i == 0 && try++ == 0) {
+ DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
+ adapter->name);
+ goto retry;
+ }
+
goto out;
timeout:
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Fix DDC probe for passive adapters
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6520 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/8] drm/i915: Cache current cdclk frequency in dev_priv
On Tue, 02 Jun 2015, Mika Kahola wrote:
> From: Ville Syrjälä
>
> Rather that extracting the current cdclk freuqncy every time someone
> wants to know it, cache the current value and use that. VLV/CHV already
> stored a cached value there so just expand that to cover all platforms.
All of the below:
> Signed-off-by: Ville Syrjälä
>
> v2: Rebased to the latest
> v3: Rebased to the latest
> v4: Rebased to the latest
>
> Signed-off-by: Mika Kahola
>
> Author:Ville Syrjälä
Should be turned into:
> v2: Rebased to the latest
> v3: Rebased to the latest
> v4: Rebased to the latest
>
> Signed-off-by: Ville Syrjälä
> Signed-off-by: Mika Kahola
to conform to existing style. See git log for examples.
Damien had a comment to the previous version of this patch [1], but I
don't see it addressed either in the patch or in reply to his mail. You
should do one or the other.
BR,
Jani.
[1] http://mid.gmane.org/20150528182433.gj24...@strange.ger.corp.intel.com
> ---
> drivers/gpu/drm/i915/intel_display.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 16e159d..4dd00a5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5747,7 +5747,7 @@ static int valleyview_get_vco(struct drm_i915_private
> *dev_priv)
> return vco_freq[hpll_freq] * 1000;
> }
>
> -static void vlv_update_cdclk(struct drm_device *dev)
> +static void intel_update_cdclk(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> @@ -5760,7 +5760,14 @@ static void vlv_update_cdclk(struct drm_device *dev)
>* BSpec erroneously claims we should aim for 4MHz, but
>* in fact 1MHz is the correct frequency.
>*/
> - I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq, 1000));
> + if (IS_VALLEYVIEW(dev)) {
> + /*
> + * Program the gmbus_freq based on the cdclk frequency.
> + * BSpec erroneously claims we should aim for 4MHz, but
> + * in fact 1MHz is the correct frequency.
> + */
> + I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq,
> 1000));
> + }
> }
>
> /* Adjust CDclk dividers to allow high res or save power if possible */
> @@ -5826,7 +5833,7 @@ static void valleyview_set_cdclk(struct drm_device
> *dev, int cdclk)
>
> mutex_unlock(&dev_priv->sb_lock);
>
> - vlv_update_cdclk(dev);
> + intel_update_cdclk(dev);
> }
>
> static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
> @@ -5867,7 +5874,7 @@ static void cherryview_set_cdclk(struct drm_device
> *dev, int cdclk)
> }
> mutex_unlock(&dev_priv->rps.hw_lock);
>
> - vlv_update_cdclk(dev);
> + intel_update_cdclk(dev);
> }
>
> static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
> @@ -6056,6 +6063,8 @@ static void valleyview_modeset_global_resources(struct
> drm_atomic_state *old_sta
>
> intel_display_power_put(dev_priv, POWER_DOMAIN_PIPE_A);
> }
> +
> + intel_update_cdclk(dev);
> }
>
> static void valleyview_crtc_enable(struct drm_crtc *crtc)
> @@ -9479,6 +9488,7 @@ static void hsw_restore_lcpll(struct drm_i915_private
> *dev_priv)
> }
>
> intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + intel_update_cdclk(dev_priv->dev);
> }
>
> /*
> @@ -13273,6 +13283,8 @@ static void intel_shared_dpll_init(struct drm_device
> *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> + intel_update_cdclk(dev);
> +
> if (HAS_DDI(dev))
> intel_ddi_pll_init(dev);
> else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
> @@ -14848,13 +14860,9 @@ static void i915_disable_vga(struct drm_device *dev)
>
> void intel_modeset_init_hw(struct drm_device *dev)
> {
> + intel_update_cdclk(dev);
> intel_prepare_ddi(dev);
> -
> - if (IS_VALLEYVIEW(dev))
> - vlv_update_cdclk(dev);
> -
> intel_init_clock_gating(dev);
> -
> intel_enable_gt_powersave(dev);
> }
>
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/21] drm/i915/gtt: Introduce fill_page_dma()
On Tue, Jun 02, 2015 at 03:51:26PM +0100, Michel Thierry wrote:
> On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
> > When we setup page directories and tables, we point the entries
> > to a to the next level scratch structure. Make this generic
> > by introducing a fill_page_dma which maps and flushes. We also
> > need 32 bit variant for legacy gens.
> >
> > v2: Fix flushes and handle valleyview (Ville)
> >
> > Signed-off-by: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 71
> > +++--
> > 1 file changed, 37 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index f747bd3..d020b5e 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -330,6 +330,31 @@ static void cleanup_page_dma(struct drm_device *dev,
> > struct i915_page_dma *p)
> > memset(p, 0, sizeof(*p));
> > }
> >
> > +static void fill_page_dma(struct drm_device *dev, struct i915_page_dma *p,
> > + const uint64_t val)
> > +{
> > + int i;
> > + uint64_t * const vaddr = kmap_atomic(p->page);
> > +
> > + for (i = 0; i < 512; i++)
> > + vaddr[i] = val;
> > +
> > + if (!HAS_LLC(dev) && !IS_VALLEYVIEW(dev))
> > + drm_clflush_virt_range(vaddr, PAGE_SIZE);
>
> Cherryview returns true to IS_VALLEYVIEW().
>
> You can use(!HAS_LLC && IS_CHERRYVIEW) instead to flush in chv, but not
> in vlv... But to make it bxt-proof, (!HAS_LLC && INTEL_INFO(dev)->gen >=
> 8) is probably better.
Has someone actually confirmed that BXT needs the clflush?
>
> > +
> > + kunmap_atomic(vaddr);
> > +}
> > +
> > +static void fill_page_dma_32(struct drm_device *dev, struct i915_page_dma
> > *p,
> > +const uint32_t val32)
> > +{
> > + uint64_t v = val32;
> > +
> > + v = v << 32 | val32;
> > +
> > + fill_page_dma(dev, p, v);
> > +}
> > +
> > static void free_pt(struct drm_device *dev, struct i915_page_table *pt)
> > {
> > cleanup_page_dma(dev, &pt->base);
> > @@ -340,19 +365,11 @@ static void free_pt(struct drm_device *dev, struct
> > i915_page_table *pt)
> > static void gen8_initialize_pt(struct i915_address_space *vm,
> > struct i915_page_table *pt)
> > {
> > - gen8_pte_t *pt_vaddr, scratch_pte;
> > - int i;
> > -
> > - pt_vaddr = kmap_atomic(pt->base.page);
> > - scratch_pte = gen8_pte_encode(vm->scratch.addr,
> > - I915_CACHE_LLC, true);
> > + gen8_pte_t scratch_pte;
> >
> > - for (i = 0; i < GEN8_PTES; i++)
> > - pt_vaddr[i] = scratch_pte;
> > + scratch_pte = gen8_pte_encode(vm->scratch.addr, I915_CACHE_LLC,
> > true);
> >
> > - if (!HAS_LLC(vm->dev))
> > - drm_clflush_virt_range(pt_vaddr, PAGE_SIZE);
> > - kunmap_atomic(pt_vaddr);
> > + fill_page_dma(vm->dev, &pt->base, scratch_pte);
> > }
> >
> > static struct i915_page_table *alloc_pt(struct drm_device *dev)
> > @@ -585,20 +602,13 @@ static void gen8_initialize_pd(struct
> > i915_address_space *vm,
> > struct i915_page_directory *pd)
> > {
> > struct i915_hw_ppgtt *ppgtt =
> > - container_of(vm, struct i915_hw_ppgtt, base);
> > - gen8_pde_t *page_directory;
> > - struct i915_page_table *pt;
> > - int i;
> > + container_of(vm, struct i915_hw_ppgtt, base);
> > + gen8_pde_t scratch_pde;
> >
> > - page_directory = kmap_atomic(pd->base.page);
> > - pt = ppgtt->scratch_pt;
> > - for (i = 0; i < I915_PDES; i++)
> > - /* Map the PDE to the page table */
> > - __gen8_do_map_pt(page_directory + i, pt, vm->dev);
> > + scratch_pde = gen8_pde_encode(vm->dev,
> > ppgtt->scratch_pt->base.daddr,
> > + I915_CACHE_LLC);
> >
> > - if (!HAS_LLC(vm->dev))
> > - drm_clflush_virt_range(page_directory, PAGE_SIZE);
> > - kunmap_atomic(page_directory);
> > + fill_page_dma(vm->dev, &pd->base, scratch_pde);
> > }
> >
> > static void gen8_free_page_tables(struct i915_page_directory *pd, struct
> > drm_device *dev)
> > @@ -1292,22 +1302,15 @@ static void gen6_ppgtt_insert_entries(struct
> > i915_address_space *vm,
> > }
> >
> > static void gen6_initialize_pt(struct i915_address_space *vm,
> > - struct i915_page_table *pt)
> > + struct i915_page_table *pt)
> > {
> > - gen6_pte_t *pt_vaddr, scratch_pte;
> > - int i;
> > + gen6_pte_t scratch_pte;
> >
> > WARN_ON(vm->scratch.addr == 0);
> >
> > - scratch_pte = vm->pte_encode(vm->scratch.addr,
> > - I915_CACHE_LLC, true, 0);
> > -
> > - pt_vaddr = kmap_atomic(pt->base.page);
Re: [Intel-gfx] [PATCH 11/21] drm/i915/gtt: Introduce fill_page_dma()
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
When we setup page directories and tables, we point the entries
to a to the next level scratch structure. Make this generic
by introducing a fill_page_dma which maps and flushes. We also
need 32 bit variant for legacy gens.
v2: Fix flushes and handle valleyview (Ville)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 71 +++--
1 file changed, 37 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index f747bd3..d020b5e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -330,6 +330,31 @@ static void cleanup_page_dma(struct drm_device *dev,
struct i915_page_dma *p)
memset(p, 0, sizeof(*p));
}
+static void fill_page_dma(struct drm_device *dev, struct i915_page_dma *p,
+ const uint64_t val)
+{
+ int i;
+ uint64_t * const vaddr = kmap_atomic(p->page);
+
+ for (i = 0; i < 512; i++)
+ vaddr[i] = val;
+
+ if (!HAS_LLC(dev) && !IS_VALLEYVIEW(dev))
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
Cherryview returns true to IS_VALLEYVIEW().
You can use(!HAS_LLC && IS_CHERRYVIEW) instead to flush in chv, but not
in vlv... But to make it bxt-proof, (!HAS_LLC && INTEL_INFO(dev)->gen >=
8) is probably better.
+
+ kunmap_atomic(vaddr);
+}
+
+static void fill_page_dma_32(struct drm_device *dev, struct i915_page_dma *p,
+const uint32_t val32)
+{
+ uint64_t v = val32;
+
+ v = v << 32 | val32;
+
+ fill_page_dma(dev, p, v);
+}
+
static void free_pt(struct drm_device *dev, struct i915_page_table *pt)
{
cleanup_page_dma(dev, &pt->base);
@@ -340,19 +365,11 @@ static void free_pt(struct drm_device *dev, struct
i915_page_table *pt)
static void gen8_initialize_pt(struct i915_address_space *vm,
struct i915_page_table *pt)
{
- gen8_pte_t *pt_vaddr, scratch_pte;
- int i;
-
- pt_vaddr = kmap_atomic(pt->base.page);
- scratch_pte = gen8_pte_encode(vm->scratch.addr,
- I915_CACHE_LLC, true);
+ gen8_pte_t scratch_pte;
- for (i = 0; i < GEN8_PTES; i++)
- pt_vaddr[i] = scratch_pte;
+ scratch_pte = gen8_pte_encode(vm->scratch.addr, I915_CACHE_LLC, true);
- if (!HAS_LLC(vm->dev))
- drm_clflush_virt_range(pt_vaddr, PAGE_SIZE);
- kunmap_atomic(pt_vaddr);
+ fill_page_dma(vm->dev, &pt->base, scratch_pte);
}
static struct i915_page_table *alloc_pt(struct drm_device *dev)
@@ -585,20 +602,13 @@ static void gen8_initialize_pd(struct i915_address_space
*vm,
struct i915_page_directory *pd)
{
struct i915_hw_ppgtt *ppgtt =
- container_of(vm, struct i915_hw_ppgtt, base);
- gen8_pde_t *page_directory;
- struct i915_page_table *pt;
- int i;
+ container_of(vm, struct i915_hw_ppgtt, base);
+ gen8_pde_t scratch_pde;
- page_directory = kmap_atomic(pd->base.page);
- pt = ppgtt->scratch_pt;
- for (i = 0; i < I915_PDES; i++)
- /* Map the PDE to the page table */
- __gen8_do_map_pt(page_directory + i, pt, vm->dev);
+ scratch_pde = gen8_pde_encode(vm->dev, ppgtt->scratch_pt->base.daddr,
+ I915_CACHE_LLC);
- if (!HAS_LLC(vm->dev))
- drm_clflush_virt_range(page_directory, PAGE_SIZE);
- kunmap_atomic(page_directory);
+ fill_page_dma(vm->dev, &pd->base, scratch_pde);
}
static void gen8_free_page_tables(struct i915_page_directory *pd, struct
drm_device *dev)
@@ -1292,22 +1302,15 @@ static void gen6_ppgtt_insert_entries(struct
i915_address_space *vm,
}
static void gen6_initialize_pt(struct i915_address_space *vm,
- struct i915_page_table *pt)
+ struct i915_page_table *pt)
{
- gen6_pte_t *pt_vaddr, scratch_pte;
- int i;
+ gen6_pte_t scratch_pte;
WARN_ON(vm->scratch.addr == 0);
- scratch_pte = vm->pte_encode(vm->scratch.addr,
- I915_CACHE_LLC, true, 0);
-
- pt_vaddr = kmap_atomic(pt->base.page);
-
- for (i = 0; i < GEN6_PTES; i++)
- pt_vaddr[i] = scratch_pte;
+ scratch_pte = vm->pte_encode(vm->scratch.addr, I915_CACHE_LLC, true, 0);
- kunmap_atomic(pt_vaddr);
+ fill_page_dma_32(vm->dev, &pt->base, scratch_pte);
}
static int gen6_alloc_va_range(struct i915_address_space *vm,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesk
Re: [Intel-gfx] [PATCH 10/21] drm/i915/gtt: Remove superfluous free_pd with gen6/7
On 5/22/2015 6:05 PM, Mika Kuoppala wrote: This has slipped in somewhere but it was harmless as we check the page pointer before teardown. Signed-off-by: Mika Kuoppala Right, free_pd is only for gen8+. Reviewed-by: Michel Thierry --- drivers/gpu/drm/i915/i915_gem_gtt.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index f58aa63..f747bd3 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -1416,7 +1416,6 @@ static void gen6_ppgtt_cleanup(struct i915_address_space *vm) } free_pt(ppgtt->base.dev, ppgtt->scratch_pt); - free_pd(ppgtt->base.dev, &ppgtt->pd); } static int gen6_ppgtt_allocate_page_directories(struct i915_hw_ppgtt *ppgtt) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4] drm/i915: Fix DDC probe for passive adapters
On Tue, Jun 02, 2015 at 01:42:52PM +0300, Jani Nikula wrote:
> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
> devices, as they do not have a sink device in them to respond to any AUX
> traffic. When probing these dongles over the DDC, sometimes they will
> NAK the first attempt even though the transaction is valid and they
> support the DDC protocol. The retry loop inside of
> drm_do_probe_ddc_edid() would normally catch this case and try the
> transaction again, resulting in success.
>
> That, however, was thwarted by the fix for [1]:
>
> commit 9292f37e1f5c79400254dca46f83313488093825
> Author: Eugeni Dodonov
> Date: Thu Jan 5 09:34:28 2012 -0200
>
> drm: give up on edid retries when i2c bus is not responding
>
> This added code to exit immediately if the return code from the
> i2c_transfer function was -ENXIO in order to reduce the amount of time
> spent in waiting for unresponsive or disconnected devices. That was
> possible because the underlying i2c bit banging algorithm had retries of
> its own (which, of course, were part of the reason for the bug the
> commit fixes).
>
> Since its introduction in
>
> commit f899fc64cda8569d0529452aafc0da31c042df2e
> Author: Chris Wilson
> Date: Tue Jul 20 15:44:45 2010 -0700
>
> drm/i915: use GMBUS to manage i2c links
>
> we've been flipping back and forth enabling the GMBUS transfers, but
> we've settled since then. The GMBUS implementation does not do any
> retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
> on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
> the retry on -ENXIO.
>
> Retry GMBUS once on -ENXIO on first message to mitigate the issues with
> passive adapters.
>
> This patch is based on the work, and commit message, by Todd Previte
> .
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
>
> v2: Don't retry if using bit banging.
>
> v3: Move retry within gmbux_xfer, retry only on first message.
>
> v4: Initialize GMBUS0 on retry (Ville).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
> Cc: Todd Previte
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 92072f56e418..5f2e88d39baf 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -486,7 +486,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
> struct intel_gmbus,
> adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
> - int i, reg_offset;
> + int i = 0, try = 0, reg_offset;
> int ret = 0;
>
> intel_aux_display_runtime_get(dev_priv);
> @@ -499,9 +499,10 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> reg_offset = dev_priv->gpio_mmio_base;
>
> +retry:
> I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
>
> - for (i = 0; i < num; i++) {
> + for (; i < num; i++) {
> if (gmbus_is_index_read(msgs, i, num)) {
> ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
> i += 1; /* set i to the index of the read xfer */
This increment means we'll never retry if we decice to use
gmbus_xfer_index_read() for the first two messages. AFAICS that
should always be the case for EDID reads where we don't send the
segment address.
> @@ -576,6 +577,18 @@ clear_err:
>adapter->name, msgs[i].addr,
>(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
>
> + /*
> + * Passive adapters sometimes NAK the first probe. Retry once on -ENXIO
> + * for GMBUS transfers; the bit banging algorithm has retries
> + * internally. See also the retry loop in drm_do_probe_ddc_edid, which
> + * bails out on the first -ENXIO.
> + */
> + if (ret == -ENXIO && i == 0 && try++ == 0) {
> + DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
> + adapter->name);
> + goto retry;
> + }
> +
> goto out;
>
> timeout:
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/21] drm/i915/gtt: Rename unmap_and_free_px to free_px
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
All the paging structures are now similar and mapped for
dma. The unmapping is taken care of by common accessors, so
don't overload the reader with such details.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 1e1a7a1..f58aa63 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -330,8 +330,7 @@ static void cleanup_page_dma(struct drm_device *dev, struct
i915_page_dma *p)
memset(p, 0, sizeof(*p));
}
-static void unmap_and_free_pt(struct i915_page_table *pt,
- struct drm_device *dev)
+static void free_pt(struct drm_device *dev, struct i915_page_table *pt)
{
cleanup_page_dma(dev, &pt->base);
kfree(pt->used_ptes);
@@ -387,8 +386,7 @@ fail_bitmap:
return ERR_PTR(ret);
}
-static void unmap_and_free_pd(struct i915_page_directory *pd,
- struct drm_device *dev)
+static void free_pd(struct drm_device *dev, struct i915_page_directory *pd)
alloc_pd has a goto label with this same name.
Can you change the labels from free_bitmap & free_pd to fail_page_m &
fail_bitmap in this patch? (alloc_pt use these names)
@@ -407,17 +407,17 @@ static struct i915_page_directory *alloc_pd(struct
drm_device *dev)
pd->used_pdes = kcalloc(BITS_TO_LONGS(I915_PDES),
sizeof(*pd->used_pdes), GFP_KERNEL);
if (!pd->used_pdes)
-goto free_pd;
+goto fail_bitmap;
ret = setup_page_dma(dev, &pd->base);
if (ret)
-goto free_bitmap;
+goto fail_page_m;
return pd;
-free_bitmap:
+fail_page_m:
kfree(pd->used_pdes);
-free_pd:
+fail_bitmap:
kfree(pd);
return ERR_PTR(ret);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix DDC probe for passive adapters
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6519 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep color HDMI sinks
On Mon, Jun 01, 2015 at 09:49:40PM +, Konduru, Chandra wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > ville.syrj...@linux.intel.com
> > Sent: Tuesday, May 05, 2015 7:06 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH v2 2/9] drm/i915: Send GCP infoframes for deep
> > color HDMI sinks
> >
> > From: Ville Syrjälä
> >
> > GCP infoframes are required to inform the HDMI sink about the color depth.
> >
> > Send the GCP infoframe whenever the sink supports any deep color modes since
> > such sinks must anyway be capable of receiving them. For sinks that don't
> > support deep color let's skip the GCP in case it might confuse the sink,
> > although
> > HDMI 1.4 spec does say all sinks must be capable of reciving them. In
> > theory we
> > could skip the GCP infoframe for deep color sinks in 8bpc mode as well since
> > sinks must fall back to 8bpc whenever GCP isn't received for some time.
> >
> > BSpec says we should disable GCP after disabling the port, so do that as
> > well.
> >
> > v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
> > Rebased due to crtc->config changes
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 3 ++
> > drivers/gpu/drm/i915/intel_hdmi.c | 74
> > +++
> > 2 files changed, 77 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index e619e41..dcd93b5 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6010,6 +6010,9 @@ enum skl_disp_power_wells {
> > #define _VIDEO_DIP_CTL_A 0xe0200
> > #define _VIDEO_DIP_DATA_A0xe0208
> > #define _VIDEO_DIP_GCP_A 0xe0210
> > +#define GCP_COLOR_INDICATION (1 << 2)
> > +#define GCP_DEFAULT_PHASE_ENABLE (1 << 1)
> > +#define GCP_AV_MUTE (1 << 0)
> >
> > #define _VIDEO_DIP_CTL_B 0xe1200
> > #define _VIDEO_DIP_DATA_B0xe1208
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 79cf445..87c4905 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -541,6 +541,66 @@ static void g4x_set_infoframes(struct drm_encoder
> > *encoder,
> > intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode); }
> >
> > +static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder) {
>
> Some static functions are prefixed but this isn't. Can you add prefix?
Is there any benefit from a prefix?
>
> > + struct drm_device *dev = encoder->dev;
> > + struct drm_connector *connector;
> > +
> > + WARN_ON(!drm_modeset_is_locked(&dev-
> > >mode_config.connection_mutex));
> > +
> > + /*
> > +* HDMI cloning is only supported on g4x which doesn't
> > +* support deep color or GCP infoframes anyway so no
> > +* need to worry about multiple HDMI sinks here.
> > +*/
>
> There isn't any code specific for HDMI cloning or multiple HDMI sinks here,
> any relevance of above comment. Or am I missing something here?
In a cloned setup we'd feed multiple sinks from the same transcoder, so
we'd need to basically check that connector->encoder->crtc matches our crtc
here, and only return true if all the relevant connectors were deep color
capable. But since we can ignore cloning we can stop looking once we
find the connector for our current encoder (ie. HDMI port).
>
> > + list_for_each_entry(connector, &dev->mode_config.connector_list,
> > head)
> > + if (connector->encoder == encoder)
> > + return connector->display_info.bpc > 8;
> > +
> > + return false;
> > +}
> > +
> > +static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder) {
> > + struct drm_i915_private *dev_priv = encoder->dev->dev_private;
> > + struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
> > + u32 reg, val = 0;
> > +
> > + if (HAS_DDI(dev_priv))
> > + reg = HSW_TVIDEO_DIP_GCP(crtc->config->cpu_transcoder);
> > + else if (IS_VALLEYVIEW(dev_priv))
> > + reg = VLV_TVIDEO_DIP_GCP(crtc->pipe);
> > + else if (HAS_PCH_SPLIT(dev_priv->dev))
> > + reg = TVIDEO_DIP_GCP(crtc->pipe);
> > + else
> > + return false;
> > +
> > + /* Indicate color depth wheneven the sink supports deep color */
>
> Typo
>
> > + if (hdmi_sink_is_deep_color(encoder))
> > + val |= GCP_COLOR_INDICATION;
> > +
> > + I915_WRITE(reg, val);
> > +
> > + return val != 0;
> > +}
> > +
> > +static void intel_disable_gcp_infoframe(struct intel_crtc *crtc) {
> > + struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> > + u32 reg;
> > +
> > + if (HAS_DDI(dev_priv))
> > + reg = HSW_TVIDEO_DIP_CTL(crtc->config->cpu_transcoder);
> > + else if (IS_VALLEYVIEW(dev_priv))
> > + reg = VLV_TVIDEO_DIP_CTL
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Move WaBarrierPerformanceFixDisable:skl to skl code from chv code
On Tue, Jun 02, 2015 at 03:37:35PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > commit 65ca7514e21adbee25b8175fc909759c735d00ff > Author: Damien Lespiau > Date: Mon Feb 9 19:33:22 2015 + > > drm/i915/skl: Implement WaBarrierPerformanceFixDisable > > got misapplied and the code landed in chv_init_workarounds() instead of > the intended skl_init_workarounds(). Move it over to the right place. > > Cc: Damien Lespiau > Signed-off-by: Ville Syrjälä > --- Reviewed-by: Damien Lespiau -- Damien > drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c > b/drivers/gpu/drm/i915/intel_ringbuffer.c > index d934f85..edd47ba 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c > @@ -901,13 +901,6 @@ static int chv_init_workarounds(struct intel_engine_cs > *ring) > GEN6_WIZ_HASHING_MASK, > GEN6_WIZ_HASHING_16x4); > > - if (INTEL_REVID(dev) == SKL_REVID_C0 || > - INTEL_REVID(dev) == SKL_REVID_D0) > - /* WaBarrierPerformanceFixDisable:skl */ > - WA_SET_BIT_MASKED(HDC_CHICKEN0, > - HDC_FENCE_DEST_SLM_DISABLE | > - HDC_BARRIER_PERFORMANCE_DISABLE); > - > return 0; > } > > @@ -1041,6 +1034,13 @@ static int skl_init_workarounds(struct intel_engine_cs > *ring) > HDC_FORCE_NON_COHERENT); > } > > + if (INTEL_REVID(dev) == SKL_REVID_C0 || > + INTEL_REVID(dev) == SKL_REVID_D0) > + /* WaBarrierPerformanceFixDisable:skl */ > + WA_SET_BIT_MASKED(HDC_CHICKEN0, > + HDC_FENCE_DEST_SLM_DISABLE | > + HDC_BARRIER_PERFORMANCE_DISABLE); > + > return skl_tune_iz_hashing(ring); > } > > -- > 2.3.6 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] gem_userptr_benchmark: Test overlapping bo mmu notifier performance impact
On Mon, Jun 01, 2015 at 11:11:15AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Current userptr kernel implementation downgrades tracking VMA ranges (real > userspace ones) to an inefficient linear walk for any process which has > instantiated overlapping userptr objects. > > This adds a test which shows the performance cliff on, most visibly, generic > userspace mmap(2) and munmap(2) operations between unsync, non-overlapping > and overlapping userptr objects. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > Cc: Thomas Daniel Looked good, pushed. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/21] drm/i915/gtt: Introduce struct i915_page_dma
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
All our paging structures have struct page and dma address
for that page.
Add struct for page/dma address pairs and use it to make
the setup and teardown for different paging structures
identical.
Include the page directory offset also in the struct for legacy
gens. Rename it to clearly point out that it is offset into the
ggtt.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 120 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 21 ---
3 files changed, 60 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c7a840b..22770aa 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2245,7 +2245,7 @@ static void gen6_ppgtt_info(struct seq_file *m, struct
drm_device *dev)
struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
seq_puts(m, "aliasing PPGTT:\n");
- seq_printf(m, "pd gtt offset: 0x%08x\n", ppgtt->pd.pd_offset);
+ seq_printf(m, "pd gtt offset: 0x%08x\n",
ppgtt->pd.base.ggtt_offset);
ppgtt->debug_dump(ppgtt, m);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 18989f7..1e1a7a1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -301,52 +301,39 @@ static gen6_pte_t iris_pte_encode(dma_addr_t addr,
return pte;
}
-#define i915_dma_unmap_single(px, dev) \
- __i915_dma_unmap_single((px)->daddr, dev)
-
-static void __i915_dma_unmap_single(dma_addr_t daddr,
- struct drm_device *dev)
+static int setup_page_dma(struct drm_device *dev, struct i915_page_dma *p)
{
struct device *device = &dev->pdev->dev;
- dma_unmap_page(device, daddr, 4096, PCI_DMA_BIDIRECTIONAL);
-}
-
-/**
- * i915_dma_map_single() - Create a dma mapping for a page table/dir/etc.
- * @px:Page table/dir/etc to get a DMA map for
- * @dev: drm device
- *
- * Page table allocations are unified across all gens. They always require a
- * single 4k allocation, as well as a DMA mapping. If we keep the structs
- * symmetric here, the simple macro covers us for every page table type.
- *
- * Return: 0 if success.
- */
-#define i915_dma_map_single(px, dev) \
- i915_dma_map_page_single((px)->page, (dev), &(px)->daddr)
+ p->page = alloc_page(GFP_KERNEL);
+ if (!p->page)
+ return -ENOMEM;
-static int i915_dma_map_page_single(struct page *page,
- struct drm_device *dev,
- dma_addr_t *daddr)
-{
- struct device *device = &dev->pdev->dev;
+ p->daddr = dma_map_page(device,
+ p->page, 0, 4096, PCI_DMA_BIDIRECTIONAL);
- *daddr = dma_map_page(device, page, 0, 4096, PCI_DMA_BIDIRECTIONAL);
- if (dma_mapping_error(device, *daddr))
- return -ENOMEM;
+ if (dma_mapping_error(device, p->daddr)) {
+ __free_page(p->page);
+ return -EINVAL;
+ }
return 0;
}
-static void unmap_and_free_pt(struct i915_page_table *pt,
- struct drm_device *dev)
+static void cleanup_page_dma(struct drm_device *dev, struct i915_page_dma *p)
{
- if (WARN_ON(!pt->page))
+ if (WARN_ON(!p->page))
return;
- i915_dma_unmap_single(pt, dev);
- __free_page(pt->page);
+ dma_unmap_page(&dev->pdev->dev, p->daddr, 4096, PCI_DMA_BIDIRECTIONAL);
+ __free_page(p->page);
+ memset(p, 0, sizeof(*p));
+}
+
+static void unmap_and_free_pt(struct i915_page_table *pt,
+ struct drm_device *dev)
+{
+ cleanup_page_dma(dev, &pt->base);
kfree(pt->used_ptes);
kfree(pt);
}
@@ -357,7 +344,7 @@ static void gen8_initialize_pt(struct i915_address_space
*vm,
gen8_pte_t *pt_vaddr, scratch_pte;
int i;
- pt_vaddr = kmap_atomic(pt->page);
+ pt_vaddr = kmap_atomic(pt->base.page);
scratch_pte = gen8_pte_encode(vm->scratch.addr,
I915_CACHE_LLC, true);
@@ -386,19 +373,13 @@ static struct i915_page_table *alloc_pt(struct drm_device
*dev)
if (!pt->used_ptes)
goto fail_bitmap;
- pt->page = alloc_page(GFP_KERNEL);
- if (!pt->page)
- goto fail_page;
-
- ret = i915_dma_map_single(pt, dev);
+ ret = setup_page_dma(dev, &pt->base);
if (ret)
- goto fail_dma;
+ goto fail_page_m;
return pt;
-fail_dma:
- __free_page(pt->page);
-fail_page:
+fail_page_m:
kfree(pt->used_ptes);
fail_bitmap:
kfree(pt);
@@ -409,9 +390,8 @@ fail_bitmap:
static void unmap_
[Intel-gfx] [PATCH 2/3] drm/i915: Set INSTPM_FORCE_ORDERING via LRI on gen8, drop it on gen9+
From: Ville Syrjälä INSTPM is saved in the logical context so we should initialize it using LRIs on gen8. It actually defaults to 1 starting from HSW, but let's keep the write around anyway. Also drop the INSTPM_FORCE_ORDERING setup entirely on gen9+ since it's now a reserved bit. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index edd47ba..06f4b22 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -800,6 +800,8 @@ static int bdw_init_workarounds(struct intel_engine_cs *ring) struct drm_device *dev = ring->dev; struct drm_i915_private *dev_priv = dev->dev_private; + WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING); + /* WaDisablePartialInstShootdown:bdw */ /* WaDisableThreadStallDopClockGating:bdw (pre-production) */ WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, @@ -861,6 +863,8 @@ static int chv_init_workarounds(struct intel_engine_cs *ring) struct drm_device *dev = ring->dev; struct drm_i915_private *dev_priv = dev->dev_private; + WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING); + /* WaDisablePartialInstShootdown:chv */ /* WaDisableThreadStallDopClockGating:chv */ WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, @@ -1132,7 +1136,7 @@ static int init_render_ring(struct intel_engine_cs *ring) _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB)); } - if (INTEL_INFO(dev)->gen >= 6) + if (INTEL_INFO(dev)->gen >= 6 && INTEL_INFO(dev)->gen < 8) I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING)); if (HAS_L3_DPF(dev)) -- 2.3.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: Apply WaDisableAsyncFlipPerfMode via LRIs on gen8
From: Ville Syrjälä MI_MODE is saved in the logical context so WaDisableAsyncFlipPerfMode must be applied using LRIs on gen8. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 06f4b22..b70d25b 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -802,6 +802,9 @@ static int bdw_init_workarounds(struct intel_engine_cs *ring) WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING); + /* WaDisableAsyncFlipPerfMode:bdw */ + WA_SET_BIT_MASKED(MI_MODE, ASYNC_FLIP_PERF_DISABLE); + /* WaDisablePartialInstShootdown:bdw */ /* WaDisableThreadStallDopClockGating:bdw (pre-production) */ WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, @@ -865,6 +868,9 @@ static int chv_init_workarounds(struct intel_engine_cs *ring) WA_SET_BIT_MASKED(INSTPM, INSTPM_FORCE_ORDERING); + /* WaDisableAsyncFlipPerfMode:chv */ + WA_SET_BIT_MASKED(MI_MODE, ASYNC_FLIP_PERF_DISABLE); + /* WaDisablePartialInstShootdown:chv */ /* WaDisableThreadStallDopClockGating:chv */ WA_SET_BIT_MASKED(GEN8_ROW_CHICKEN, @@ -1109,9 +1115,9 @@ static int init_render_ring(struct intel_engine_cs *ring) * to use MI_WAIT_FOR_EVENT within the CS. It should already be * programmed to '1' on all products. * -* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv,bdw,chv +* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv */ - if (INTEL_INFO(dev)->gen >= 6 && INTEL_INFO(dev)->gen < 9) + if (INTEL_INFO(dev)->gen >= 6 && INTEL_INFO(dev)->gen < 8) I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE)); /* Required for the hardware to program scanline values for waiting */ -- 2.3.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915: Move WaBarrierPerformanceFixDisable:skl to skl code from chv code
From: Ville Syrjälä commit 65ca7514e21adbee25b8175fc909759c735d00ff Author: Damien Lespiau Date: Mon Feb 9 19:33:22 2015 + drm/i915/skl: Implement WaBarrierPerformanceFixDisable got misapplied and the code landed in chv_init_workarounds() instead of the intended skl_init_workarounds(). Move it over to the right place. Cc: Damien Lespiau Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index d934f85..edd47ba 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -901,13 +901,6 @@ static int chv_init_workarounds(struct intel_engine_cs *ring) GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4); - if (INTEL_REVID(dev) == SKL_REVID_C0 || - INTEL_REVID(dev) == SKL_REVID_D0) - /* WaBarrierPerformanceFixDisable:skl */ - WA_SET_BIT_MASKED(HDC_CHICKEN0, - HDC_FENCE_DEST_SLM_DISABLE | - HDC_BARRIER_PERFORMANCE_DISABLE); - return 0; } @@ -1041,6 +1034,13 @@ static int skl_init_workarounds(struct intel_engine_cs *ring) HDC_FORCE_NON_COHERENT); } + if (INTEL_REVID(dev) == SKL_REVID_C0 || + INTEL_REVID(dev) == SKL_REVID_D0) + /* WaBarrierPerformanceFixDisable:skl */ + WA_SET_BIT_MASKED(HDC_CHICKEN0, + HDC_FENCE_DEST_SLM_DISABLE | + HDC_BARRIER_PERFORMANCE_DISABLE); + return skl_tune_iz_hashing(ring); } -- 2.3.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] intel_check_page_flip() - WARN_ON(!in_interrupt())
I am seeing the following in the dmesg on 4.0.4 with rt patch [5.720319] [ cut here ] [5.720347] WARNING: CPU: 6 PID: 466 at drivers/gpu/drm/i915/intel_display.c:9748 intel_check_page_flip+0xaa/0xf0 [i915]() [5.720349] WARN_ON(!in_interrupt()) [5.720350] Modules linked in: [5.720376] binfmt_misc rfcomm bnep arc4 eeepc_wmi hid_generic asus_wmi sparse_keymap iwlmvm intel_powerclamp coretemp kvm_intel kvm mac80211 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul dm_multipath glue_helper snd_hda_codec_hdmi scsi_dh ablk_helper cryptd microcode btusb iwlwifi bluetooth serio_raw cfg80211 i915 snd_hda_codec_realtek snd_hda_codec_generic lpc_ich snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi drm_kms_helper snd_seq drm video snd_seq_device mac_hid snd_timer snd mei_me wmi mei shpchp soundcore i2c_algo_bit usbhid hid parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq psmouse dm_mirror r8169 ahci dm_region_hash libahci mii dm_log [5.720379] CPU: 6 PID: 466 Comm: irq/32-i915 Not tainted 4.0.4-rt1+ #8 [5.720380] Hardware name: System76, Inc. Wild Dog Performance/H87-PLUS, BIOS 0705 12/05/2013 [5.720382] 0009 8803ea39bc98 817c0694 0002 [5.720383] 8803ea39bce8 8803ea39bcd8 81073d8a 0001 [5.720384] 8803eb184000 8800d7804800 [5.720385] Call Trace: [5.720390] [] dump_stack+0x4f/0x90 [5.720393] [] warn_slowpath_common+0x8a/0xe0 [5.720395] [] warn_slowpath_fmt+0x46/0x50 [5.720410] [] intel_check_page_flip+0xaa/0xf0 [i915] [5.720420] [] ironlake_irq_handler+0x2e8/0x1000 [i915] [5.720423] [] ? debug_smp_processor_id+0x17/0x20 [5.720424] [] ? pin_current_cpu+0x92/0x1d0 [5.720426] [] ? irq_thread_fn+0x50/0x50 [5.720428] [] irq_forced_thread_fn+0x27/0x80 [5.720429] [] irq_thread+0x10f/0x160 [5.720430] [] ? wake_threads_waitq+0x30/0x30 [5.720432] [] ? irq_thread_check_affinity+0x90/0x90 [5.720433] [] kthread+0xbb/0xe0 [5.720434] [] ? kthread_worker_fn+0x1a0/0x1a0 [5.720436] [] ret_from_fork+0x58/0x90 [5.720437] [] ? kthread_worker_fn+0x1a0/0x1a0 [5.720437] ---[ end trace 0002 ]--- There seem to be few past bug reports on this issue. Has this been fixed? Should I be concerned about this? thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] EDID problem
Hello, I want to use custom EDID for one of my monitors. This because the monitor has a broken EDID structure. I have been trying to use a custom EDID (a binary message was saved before) within Xorg.conf. Is this possible? I have installed the drivers by using : Intel(R) Graphics Installer for Linux* 1.0.7 and the operating system is Ubuntu 14.04 64bit. Regards. -- *Engin FIRAT* Adoniss Yazılım Bilişim Elektronik Araştırma Geliştirme Limited Şirketi +90 506 884 82 07 (Mobile) ODTÜ Teknokent, ODTÜ-Halıcı Yazılımevi İnönü Bulvarı / ANKARA (Address) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Warning: Broadwell/i915: Unclaimed register detected before reading register 0x130040
Hey, this just popped up in the dmesg of my Dell XPS 13 -- the system seems to run well, but still, it asks about being cut and sent, so here it is. It is on 4.1.0-rc4+ (Linus' tree as of May 24th, around 3pm UTC -- don't have the git commit ID anymore). [ cut here ] WARNING: CPU: 0 PID: 1167 at /home/brodo/local/kernel/git/linux/drivers/gpu/drm/i915/intel_uncore.c:566 hsw_unclaimed_reg_debug+0x7d/0xa0() Unclaimed register detected before reading register 0x130040 Modules linked in: CPU: 0 PID: 1167 Comm: Xorg Not tainted 4.1.0-rc4+ #1 Hardware name: Dell Inc. XPS 13 9343/0TM99H, BIOS A03 03/25/2015 b39694d8 88020e14b998 b322906f 8001 88020e14b9e8 88020e14b9d8 b272ca8a 88020e14b9a8 88021519 00130040 880215bfd800 00130040 Call Trace: [] dump_stack+0x4f/0x7b [] warn_slowpath_common+0x8a/0xc0 [] warn_slowpath_fmt+0x46/0x50 [] hsw_unclaimed_reg_debug+0x7d/0xa0 [] gen6_read32+0x56/0x1c0 [] hsw_disable_pc8+0x36/0x2c0 [] intel_runtime_resume+0x160/0x1b0 [] pci_pm_runtime_resume+0x7f/0xc0 [] ? pci_restore_standard_config+0x50/0x50 [] __rpm_callback+0x36/0x90 [] rpm_callback+0x26/0xa0 [] rpm_resume+0x496/0x670 [] ? preempt_count_add+0x79/0xc0 [] __pm_runtime_resume+0x40/0x60 [] intel_runtime_pm_get+0x55/0x80 [] i915_gem_free_object+0x29/0x360 [] drm_gem_object_free+0x27/0x40 [] drm_gem_object_handle_unreference_unlocked+0x118/0x130 [] drm_gem_handle_delete+0xb4/0x100 [] ? sock_recvmsg+0x3b/0x50 [] drm_gem_close_ioctl+0x25/0x30 [] drm_ioctl+0x1a5/0x6a0 [] ? do_readv_writev+0x1b2/0x260 [] ? _raw_spin_unlock_irqrestore+0x2a/0x60 [] ? timerqueue_del+0x24/0x70 [] ? __remove_hrtimer+0x4e/0xe0 [] do_vfs_ioctl+0x2e0/0x4e0 [] ? __fget+0x72/0xb0 [] SyS_ioctl+0x81/0xa0 [] system_call_fastpath+0x12/0x6a ---[ end trace 8ff5864d3e587195 ]--- Best, Dominik signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] Color Manager Implementation
Hi Damien, Yes we are getting the IGT's ready, and already we have a test tool to apply CSC/Gamma already, which we used for ULT. As discussed in the parallel forums, we will finally use Chrome UI to test the end-to-end UI level effects Regards Shashank -Original Message- From: Lespiau, Damien Sent: Tuesday, June 02, 2015 5:31 PM To: Malladi, Kausal Cc: Roper, Matthew D; Barnes, Jesse; Jindal, Sonika; R, Durgadoss; Purushothaman, Vijay A; intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vetter, Daniel; Sharma, Shashank; Kamath, Sunil; Mukherjee, Indranil; annie.j.mather...@intel.com; R, Dhanya p; Palleti, Avinash Reddy Subject: Re: [PATCH 0/7] Color Manager Implementation On Tue, Jun 02, 2015 at 01:22:42AM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch set adds color manager implementation in drm/i915 layer. Is anyone working on tests/test plan? Thanks, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] Color Manager Implementation
On Tue, Jun 02, 2015 at 01:22:42AM +0530, Kausal Malladi wrote: > From: Kausal Malladi > > This patch set adds color manager implementation in drm/i915 layer. Is anyone working on tests/test plan? Thanks, -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Include G4X/VLV/CHV in self refresh status
On Tue, 02 Jun 2015, Ville Syrjälä wrote: > On Tue, Jun 02, 2015 at 02:17:47PM +0300, Ander Conselvan de Oliveira wrote: >> Add all missing platforms handled by intel_set_memory_cxsr() to the >> i915_sr_status debugfs entry. >> >> v2: Add G4X too. (Ville) >> Clarify the change also affects CHV. (Ander) >> >> References: https://bugs.freedesktop.org/show_bug.cgi?id=89792 >> Signed-off-by: Ander Conselvan de Oliveira >> > > It's a good enough white lie for my taste. > Reviewed-by: Ville Syrjälä > > I would also accept removing the entire file, but we can keep it if > people find some use for it. This doesn't do anything for skl, but the bug report is (also) about skl. BR, Jani. > >> --- >> drivers/gpu/drm/i915/i915_debugfs.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c >> b/drivers/gpu/drm/i915/i915_debugfs.c >> index fece922..564a6ba 100644 >> --- a/drivers/gpu/drm/i915/i915_debugfs.c >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c >> @@ -1725,12 +1725,15 @@ static int i915_sr_status(struct seq_file *m, void >> *unused) >> >> if (HAS_PCH_SPLIT(dev)) >> sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN; >> -else if (IS_CRESTLINE(dev) || IS_I945G(dev) || IS_I945GM(dev)) >> +else if (IS_CRESTLINE(dev) || IS_G4X(dev) || >> + IS_I945G(dev) || IS_I945GM(dev)) >> sr_enabled = I915_READ(FW_BLC_SELF) & FW_BLC_SELF_EN; >> else if (IS_I915GM(dev)) >> sr_enabled = I915_READ(INSTPM) & INSTPM_SELF_EN; >> else if (IS_PINEVIEW(dev)) >> sr_enabled = I915_READ(DSPFW3) & PINEVIEW_SELF_REFRESH_EN; >> +else if (IS_VALLEYVIEW(dev)) >> +sr_enabled = I915_READ(FW_BLC_SELF_VLV) & FW_CSPWRDWNEN; >> >> intel_runtime_pm_put(dev_priv); >> >> -- >> 2.1.0 > > -- > Ville Syrjälä > Intel OTC > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Add pipe level Gamma correction for CHV/BSW
Hi,
On 2 June 2015 at 12:38, Jindal, Sonika wrote:
> On 6/2/2015 1:22 AM, Kausal Malladi wrote:
>> +int drm_mode_crtc_update_color_property(struct drm_device *dev,
>> + struct drm_property_blob **blob,
>> + size_t length, const void *color_data,
>> + struct drm_mode_object *obj_holds_id,
>> + struct drm_property *prop_holds_id)
>
> This can be simplified.. No need to pass so many params.
>>
>> +{
>> + int ret;
>> +
>> + ret = drm_property_replace_global_blob(dev,
>> + blob, length, color_data, obj_holds_id,
>> prop_holds_id);
>> +
>> + return ret;
>> +}
>> +
>
> Split the patch to add drm specific changes in a separate patch. Also you
> need to export this function.
Or just remove the function entirely. It literally adds no value, and
is just an alias for drm_property_replace_global_blob. So just use
that directly.
>> +int chv_set_gamma(struct drm_device *dev, uint64_t blob_id,
>> + struct drm_crtc *crtc)
>> +{
>> + struct drm_intel_gamma *gamma_data;
>> + struct drm_i915_private *dev_priv = dev->dev_private;
>> + struct drm_property_blob *blob;
>> + struct drm_mode_config *config = &dev->mode_config;
>> +
>> + u32 cgm_control_reg = 0;
>> + u32 cgm_gamma_reg = 0;
>> + u32 reg, val, pipe;
pipe should be an enum pipe.
>> + u16 red, green, blue;
Isn't this the literal definition of struct rgb_pixel, which you added
separately in this series?
>> + if (gamma_data->gamma_precision == I915_GAMMA_PRECISION_UNKNOWN) {
>> +
>> + /* Disable Gamma functionality on Pipe - CGM Block */
>> + cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
>> + cgm_control_reg &= ~CGM_GAMMA_EN;
>> + I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
>> +
>> + DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
>> + pipe_name(pipe));
>> + ret = 0;
>> + goto release_memory;
>> + }
This branch never updates the property.
>> + if (pipe >= CHV_MAX_PIPES) {
>> + DRM_ERROR("Incorrect Pipe ID\n");
>> + ret = -EFAULT;
>> + goto release_memory;
>> + }
How could this ever happen? This should be a WARN_ON at least.
>> + correction_values = kzalloc(length, GFP_KERNEL);
>> + if (!correction_values) {
>> + DRM_ERROR("Out of Memory\n");
>> + ret = -ENOMEM;
>> + goto release_memory;
>> + }
>> +
>> + ret = copy_from_user((void *)correction_values,
>> + (const void __user *)gamma_data->gamma_ptr, length);
>> + if (ret) {
>> + DRM_ERROR("Error copying user data\n");
>> + ret = -EFAULT;
>> + goto release_memory;
>> + }
I think I've managed to work out the userspace API now:
- allocate drm_intel_gamma structure
- allocate correction values
- insert pointer to correction values into gamma structure
- create blob with pointer to gamma structure
This seems pretty backwards. The correction values - the large data we
need to avoid copying around - is what should be a blob property. With
your approach, the correction data (big) will be copied quite a few
times, where the supporting structure (very small) will never be
copied.
At the very least, the correction data must be a blob property. I
don't think there is much use in having drm_intel_gamma itself be a
blob property, but I can see why you might want it to be.
>> + ret = drm_mode_crtc_update_color_property(dev,
>> + &crtc->gamma_blob, length, (void *) correction_values,
>> + &crtc->base, config->gamma_property);
As discussed, this function is a pure alias, and can be removed.
>> + if (gamma_data->gamma_precision == I915_GAMMA_PRECISION_LEGACY) {
>> +
>> + if (num_samples != CHV_8BIT_GAMMA_MAX_VALS) {
>> + DRM_ERROR("Incorrect number of samples
>> received\n");
>> + goto release_memory;
>> + }
This should be checked before the property is updated.
>> + /* First, disable CGM Gamma, if already set */
>> + cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
>> + cgm_control_reg &= ~CGM_GAMMA_EN;
>> + I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
>> +
>> + /* Enable (Legacy) Gamma on Pipe gamma_data.__obj_id */
>> + palette = _PIPE_GAMMA_BASE(pipe);
The comment is misleading. pipe is calculated from crtc->pipe, not
gamma_data.__obj_id.
Also, should all these operations be performed under vblank evasion?
>> + } else if (gamma_data->gamma_precision ==
>> I915_GAMMA_PRECISION_10BIT) {
>> +
>> + if (num_samples != CHV_10BIT_GAMMA_MAX_VALS) {
>> + DRM_ERROR("Incorrect nu
Re: [Intel-gfx] [PATCH] drm/i915: Include G4X/VLV/CHV in self refresh status
On Tue, Jun 02, 2015 at 02:17:47PM +0300, Ander Conselvan de Oliveira wrote: > Add all missing platforms handled by intel_set_memory_cxsr() to the > i915_sr_status debugfs entry. > > v2: Add G4X too. (Ville) > Clarify the change also affects CHV. (Ander) > > References: https://bugs.freedesktop.org/show_bug.cgi?id=89792 > Signed-off-by: Ander Conselvan de Oliveira > It's a good enough white lie for my taste. Reviewed-by: Ville Syrjälä I would also accept removing the entire file, but we can keep it if people find some use for it. > --- > drivers/gpu/drm/i915/i915_debugfs.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index fece922..564a6ba 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -1725,12 +1725,15 @@ static int i915_sr_status(struct seq_file *m, void > *unused) > > if (HAS_PCH_SPLIT(dev)) > sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN; > - else if (IS_CRESTLINE(dev) || IS_I945G(dev) || IS_I945GM(dev)) > + else if (IS_CRESTLINE(dev) || IS_G4X(dev) || > + IS_I945G(dev) || IS_I945GM(dev)) > sr_enabled = I915_READ(FW_BLC_SELF) & FW_BLC_SELF_EN; > else if (IS_I915GM(dev)) > sr_enabled = I915_READ(INSTPM) & INSTPM_SELF_EN; > else if (IS_PINEVIEW(dev)) > sr_enabled = I915_READ(DSPFW3) & PINEVIEW_SELF_REFRESH_EN; > + else if (IS_VALLEYVIEW(dev)) > + sr_enabled = I915_READ(FW_BLC_SELF_VLV) & FW_CSPWRDWNEN; > > intel_runtime_pm_put(dev_priv); > > -- > 2.1.0 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/9] drm/i915: Enable default_phase in GCP when possible
On Mon, Jun 01, 2015 at 09:49:53PM +, Konduru, Chandra wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > ville.syrj...@linux.intel.com
> > Sent: Tuesday, May 05, 2015 7:06 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH v2 3/9] drm/i915: Enable default_phase in GCP
> > when
> > possible
> >
> > From: Ville Syrjälä
> >
> > When the video timings are suitably aligned so that all different periods
> > start at
> > phase 0 (ie. none of the periods start mid-pixel) we can inform the sink
> > about
> > this. Supposedly the sink can then optimize certain things. Obviously this
> > is only
> > relevant when outputting >8bpc data since otherwise there are no mid-pixel
> > phases.
> >
> > v2: Rebased due to crtc->config changes
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_hdmi.c | 48
> > +++
> > 1 file changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 87c4905..2e98e33 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -560,6 +560,49 @@ static bool hdmi_sink_is_deep_color(struct
> > drm_encoder *encoder)
> > return false;
> > }
> >
> > +/*
> > + * Determine if default_phase=1 can be indicated in the GCP infoframe.
> > + *
> > + * From HDMI specification 1.4a:
> > + * - The first pixel of each Video Data Period shall always have a
> > +pixel packing phase of 0
> > + * - The first pixel following each Video Data Period shall have a
> > +pixel packing phase of 0
> > + * - The PP bits shall be constant for all GCPs and will be equal to
> > +the last packing phase
> > + * - The first pixel following every transition of HSYNC or VSYNC shall
> > have a
> > pixel packing
> > + * phase of 0
> > + */
> > +static bool gcp_default_phase_possible(int pipe_bpp,
> > + const struct drm_display_mode *mode) {
> > + unsigned int pixels_per_group;
> > +
> > + switch (pipe_bpp) {
> > + case 30:
> > + /* 4 pixels in 5 clocks */
> > + pixels_per_group = 4;
> > + break;
> > + case 36:
> > + /* 2 pixels in 3 clocks */
> > + pixels_per_group = 2;
> > + break;
> > + case 48:
> > + /* 1 pixel in 2 clocks */
> > + pixels_per_group = 1;
> > + break;
> > + default:
> > + /* phase information not relevant for 8bpc */
> > + return false;
> > + }
> > +
> > + return mode->crtc_hdisplay % pixels_per_group == 0 &&
> > + mode->crtc_htotal % pixels_per_group == 0 &&
> > + mode->crtc_hblank_start % pixels_per_group == 0 &&
> > + mode->crtc_hblank_end % pixels_per_group == 0 &&
> > + mode->crtc_hsync_start % pixels_per_group == 0 &&
> > + mode->crtc_hsync_end % pixels_per_group == 0 &&
>
> For hsync, bspec says Hsync is an even number.
> Isn't it above check should be something like (hsync_end - hsync_start) % 2
> == 0?
> And similarly for front & back porches, right?
If X and Y are even then (X - Y) is even too. Also the text in bspec is
less informative than the text in HDMI spec, which is why I quited the
HDMI spec instead.
>
> > + ((mode->flags & DRM_MODE_FLAG_INTERLACE) == 0 ||
> > +mode->crtc_htotal/2 % pixels_per_group == 0); }
> > +
> > static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder) {
> > struct drm_i915_private *dev_priv = encoder->dev->dev_private; @@ -
> > 579,6 +622,11 @@ static bool intel_hdmi_set_gcp_infoframe(struct
> > drm_encoder *encoder)
> > if (hdmi_sink_is_deep_color(encoder))
> > val |= GCP_COLOR_INDICATION;
> >
> > + /* Enable default_phase whenever the display mode is suitably aligned
> > */
> > + if (gcp_default_phase_possible(crtc->config->pipe_bpp,
> > + &crtc->config->base.adjusted_mode))
> > + val |= GCP_DEFAULT_PHASE_ENABLE;
> > +
> > I915_WRITE(reg, val);
> >
> > return val != 0;
> > --
> > 2.0.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] perf/x86/intel/pt: Fix lockdep interaction
Oops, didn't mean to send this here since it is not graphics related. But it does happen on SKL so maybe it will be useful for someone. Tvrtko On 06/02/2015 12:37 PM, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Since this drivers creates attributes on the heap, lockdep gets upset and disabled itself. Fix by setting ignore_lockdep flags for problematic attributes. Signed-off-by: Tvrtko Ursulin Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Peter Zijlstra (Intel) Cc: x...@kernel.org Cc: Michał Winiarski --- Not saying this is a right fix but lets say I am trying to force the issue. :) --- arch/x86/kernel/cpu/perf_event_intel_pt.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c b/arch/x86/kernel/cpu/perf_event_intel_pt.c index ffe666c..1cff27b 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_pt.c +++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c @@ -153,9 +153,10 @@ static int __init pt_pmu_hw_init(void) sysfs_attr_init(&de_attrs->attr.attr); - de_attr->attr.attr.mode = S_IRUGO; - de_attr->attr.show = pt_cap_show; - de_attr->var = (void *)i; + de_attr->attr.attr.mode= S_IRUGO; + de_attr->attr.show = pt_cap_show; + de_attr->attr.attr.ignore_lockdep = 1; + de_attr->var = (void *)i; attrs[i] = &de_attr->attr.attr; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Add pipe level Gamma correction for CHV/BSW
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
This patch does the following:
1. Adds the core function to program Gamma correction values for CHV/BSW
platform
2. Adds Gamma correction macros/defines
3. Adds drm_mode_crtc_update_color_property function, which replaces the
old blob for the property with the new one
4. Adds a pointer to hold blob for Gamma property in drm_crtc
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/drm_crtc.c | 14 ++
drivers/gpu/drm/i915/intel_color_manager.c | 194
drivers/gpu/drm/i915/intel_color_manager.h | 61 +
drivers/gpu/drm/i915/intel_display.c |9 +-
include/drm/drm_crtc.h |8 ++
5 files changed, 285 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 77f87b2..50b925b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4691,6 +4691,20 @@ int drm_mode_connector_set_tile_property(struct
drm_connector *connector)
}
EXPORT_SYMBOL(drm_mode_connector_set_tile_property);
+int drm_mode_crtc_update_color_property(struct drm_device *dev,
+ struct drm_property_blob **blob,
+ size_t length, const void *color_data,
+ struct drm_mode_object *obj_holds_id,
+ struct drm_property *prop_holds_id)
This can be simplified.. No need to pass so many params.
+{
+ int ret;
+
+ ret = drm_property_replace_global_blob(dev,
+ blob, length, color_data, obj_holds_id, prop_holds_id);
+
+ return ret;
+}
+
Split the patch to add drm specific changes in a separate patch. Also
you need to export this function.
Will review the rest of the file in some time.
Regards,
Sonika
/**
* drm_mode_connector_update_edid_property - update the edid property of a
connector
* @connector: drm connector
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
index b0eb679..f46857f 100644
--- a/drivers/gpu/drm/i915/intel_color_manager.c
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -27,6 +27,200 @@
#include "intel_color_manager.h"
+int chv_set_gamma(struct drm_device *dev, uint64_t blob_id,
+ struct drm_crtc *crtc)
+{
+ struct drm_intel_gamma *gamma_data;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_property_blob *blob;
+ struct drm_mode_config *config = &dev->mode_config;
+
+ u32 cgm_control_reg = 0;
+ u32 cgm_gamma_reg = 0;
+ u32 reg, val, pipe;
+ u16 red, green, blue;
+ struct rgb_pixel correct_rgb;
+ u32 count = 0;
+ struct rgb_pixel *correction_values = NULL;
+ u32 num_samples;
+ u32 word;
+ u32 palette;
+ int ret = 0, length;
+
+ blob = drm_property_lookup_blob(dev, blob_id);
+ if (!blob) {
+ DRM_ERROR("Invalid Blob ID\n");
+ return -EINVAL;
+ }
+
+ gamma_data = kzalloc(sizeof(struct drm_intel_gamma), GFP_KERNEL);
+ if (!gamma_data) {
+ DRM_ERROR("Memory unavailable\n");
+ return -ENOMEM;
+ }
+ gamma_data = (struct drm_intel_gamma *)blob->data;
+ pipe = to_intel_crtc(crtc)->pipe;
+ num_samples = gamma_data->num_samples;
+ length = num_samples * sizeof(struct rgb_pixel);
+
+ if (gamma_data->gamma_precision == I915_GAMMA_PRECISION_UNKNOWN) {
+
+ /* Disable Gamma functionality on Pipe - CGM Block */
+ cgm_control_reg = I915_READ(_PIPE_CGM_CONTROL(pipe));
+ cgm_control_reg &= ~CGM_GAMMA_EN;
+ I915_WRITE(_PIPE_CGM_CONTROL(pipe), cgm_control_reg);
+
+ DRM_DEBUG_DRIVER("Gamma disabled on Pipe %c\n",
+ pipe_name(pipe));
+ ret = 0;
+ goto release_memory;
+ }
+
+ if (pipe >= CHV_MAX_PIPES) {
+ DRM_ERROR("Incorrect Pipe ID\n");
+ ret = -EFAULT;
+ goto release_memory;
+ }
+
+ correction_values = kzalloc(length, GFP_KERNEL);
+ if (!correction_values) {
+ DRM_ERROR("Out of Memory\n");
+ ret = -ENOMEM;
+ goto release_memory;
+ }
+
+ ret = copy_from_user((void *)correction_values,
+ (const void __user *)gamma_data->gamma_ptr, length);
+ if (ret) {
+ DRM_ERROR("Error copying user data\n");
+ ret = -EFAULT;
+ goto release_memory;
+ }
+
+ ret = drm_mode_crtc_update_color_property(dev,
+ &crtc->gamma_blob, length, (void *) correction_values,
+ &crtc->base, config->gamma_property);
+ if (ret) {
+ DRM_ERROR("Error updating Gamma blob\n");
+ ret = -EFAULT;
+ goto release_memory;
+ }
+
+
[Intel-gfx] [PATCH] perf/x86/intel/pt: Fix lockdep interaction
From: Tvrtko Ursulin Since this drivers creates attributes on the heap, lockdep gets upset and disabled itself. Fix by setting ignore_lockdep flags for problematic attributes. Signed-off-by: Tvrtko Ursulin Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Peter Zijlstra (Intel) Cc: x...@kernel.org Cc: Michał Winiarski --- Not saying this is a right fix but lets say I am trying to force the issue. :) --- arch/x86/kernel/cpu/perf_event_intel_pt.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event_intel_pt.c b/arch/x86/kernel/cpu/perf_event_intel_pt.c index ffe666c..1cff27b 100644 --- a/arch/x86/kernel/cpu/perf_event_intel_pt.c +++ b/arch/x86/kernel/cpu/perf_event_intel_pt.c @@ -153,9 +153,10 @@ static int __init pt_pmu_hw_init(void) sysfs_attr_init(&de_attrs->attr.attr); - de_attr->attr.attr.mode = S_IRUGO; - de_attr->attr.show = pt_cap_show; - de_attr->var= (void *)i; + de_attr->attr.attr.mode = S_IRUGO; + de_attr->attr.show= pt_cap_show; + de_attr->attr.attr.ignore_lockdep = 1; + de_attr->var = (void *)i; attrs[i] = &de_attr->attr.attr; } -- 2.4.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm: Add Gamma correction structure
Hi,
On 2 June 2015 at 12:25, Jindal, Sonika wrote:
> On 6/2/2015 1:22 AM, Kausal Malladi wrote:
>> struct drm_intel_gamma {
>> __u32 flags;
>> (The flag variable will indicate if the property to be set/get
>> is Gamma or DeGamma)
>> __u32 gamma_level;
>> (The gamma_level variable indicates if the Gamma correction is to
>> be
>> applied on Pipe/plane)
>> __u32 gamma_precision;
>> (The Gamma precision indicates the Gamma mode to be applied)
>>
>> Supported precisions are -
>> #define I915_GAMMA_PRECISION_UNKNOWN0
>> #define I915_GAMMA_PRECISION_CURRENT0x
>> #define I915_GAMMA_PRECISION_LEGACY (1 << 0)
>> #define I915_GAMMA_PRECISION_10BIT (1 << 1)
>> #define I915_GAMMA_PRECISION_12BIT (1 << 2)
>> #define I915_GAMMA_PRECISION_14BIT (1 << 3)
>> #define I915_GAMMA_PRECISION_16BIT (1 << 4)
>>
>> __u32 num_samples;
>> (The num_samples indicates the number of Gamma correction
>> coefficients)
>> __u32 reserved;
>> __u64 gamma_ptr;
>> (Points to the raw Gamma color correction values)
>> };
Please use the atomic interface and blob properties for this instead.
A user-created blob property can replace the contents of gamma_ptr,
you can replace gamma_level by choosing whether you apply the
properties to a CRTC (pipe) or plane, and then you just need separate
properties for precision and num_samples.
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/7] drm: Add Gamma correction structure
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
This patch adds a new structure in DRM layer for Gamma color correction.
This structure will be used by all user space agents to configure
appropriate Gamma precision and Gamma level.
struct drm_intel_gamma {
__u32 flags;
(The flag variable will indicate if the property to be set/get
is Gamma or DeGamma)
__u32 gamma_level;
(The gamma_level variable indicates if the Gamma correction is to be
applied on Pipe/plane)
__u32 gamma_precision;
(The Gamma precision indicates the Gamma mode to be applied)
Supported precisions are -
#define I915_GAMMA_PRECISION_UNKNOWN0
#define I915_GAMMA_PRECISION_CURRENT0x
#define I915_GAMMA_PRECISION_LEGACY (1 << 0)
#define I915_GAMMA_PRECISION_10BIT (1 << 1)
#define I915_GAMMA_PRECISION_12BIT (1 << 2)
#define I915_GAMMA_PRECISION_14BIT (1 << 3)
#define I915_GAMMA_PRECISION_16BIT (1 << 4)
__u32 num_samples;
(The num_samples indicates the number of Gamma correction
coefficients)
__u32 reserved;
__u64 gamma_ptr;
(Points to the raw Gamma color correction values)
};
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
include/uapi/drm/drm.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 3801584..fe27e5c 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -829,6 +829,17 @@ struct drm_event_vblank {
__u32 reserved;
};
+/* Color Management structure for Gamma */
+struct drm_intel_gamma {
I suppose, this can be used by other drivers as well? If yes, "intel"
can be removed.
+ __u32 obj_id;
+ __u32 flags;
+ __u32 gamma_level;
+ __u32 gamma_precision;
+ __u32 num_samples;
+ __u32 reserved;
+ __u64 gamma_ptr;
+};
+
/* typedef area */
#ifndef __KERNEL__
typedef struct drm_clip_rect drm_clip_rect_t;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/7] drm/i915: Add Set property interface for CRTC
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
This patch adds set property interface for Intel CRTC. This interface
will be used to set color correction DRM properties.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/intel_display.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f817cea..21e67da 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12978,11 +12978,19 @@ out:
return ret;
}
+static int intel_crtc_set_property(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t val)
+{
+ DRM_DEBUG_KMS("Unknown crtc property '%s'\n", property->name);
+ return -EINVAL;
+}
+
static const struct drm_crtc_funcs intel_crtc_funcs = {
.gamma_set = intel_crtc_gamma_set,
.set_config = intel_crtc_set_config,
.destroy = intel_crtc_destroy,
.page_flip = intel_crtc_page_flip,
+ .set_property = intel_crtc_set_property,
I think it should be done similar to plane set property using atomic
helpers.
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Include G4X/VLV/CHV in self refresh status
Add all missing platforms handled by intel_set_memory_cxsr() to the i915_sr_status debugfs entry. v2: Add G4X too. (Ville) Clarify the change also affects CHV. (Ander) References: https://bugs.freedesktop.org/show_bug.cgi?id=89792 Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_debugfs.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index fece922..564a6ba 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1725,12 +1725,15 @@ static int i915_sr_status(struct seq_file *m, void *unused) if (HAS_PCH_SPLIT(dev)) sr_enabled = I915_READ(WM1_LP_ILK) & WM1_LP_SR_EN; - else if (IS_CRESTLINE(dev) || IS_I945G(dev) || IS_I945GM(dev)) + else if (IS_CRESTLINE(dev) || IS_G4X(dev) || +IS_I945G(dev) || IS_I945GM(dev)) sr_enabled = I915_READ(FW_BLC_SELF) & FW_BLC_SELF_EN; else if (IS_I915GM(dev)) sr_enabled = I915_READ(INSTPM) & INSTPM_SELF_EN; else if (IS_PINEVIEW(dev)) sr_enabled = I915_READ(DSPFW3) & PINEVIEW_SELF_REFRESH_EN; + else if (IS_VALLEYVIEW(dev)) + sr_enabled = I915_READ(FW_BLC_SELF_VLV) & FW_CSPWRDWNEN; intel_runtime_pm_put(dev_priv); -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Disable all infoframes when turning off the HDMI port
On Mon, Jun 01, 2015 at 10:48:03PM +, Konduru, Chandra wrote:
>
>
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of
> > ville.syrj...@linux.intel.com
> > Sent: Tuesday, May 05, 2015 7:06 AM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH v2 6/9] drm/i915: Disable all infoframes when
> > turning off the HDMI port
> >
> > From: Ville Syrjälä
> >
> > Currently we just disable the GCP infoframe when turning off the port.
> > That means if the same transcoder is used on a DP port next, we might
> > end up pushing infoframes over DP, which isn't intended. Just disable
>
> Wonder how it is working. May be it is ok, or never hit using a previously
> used transcoder for HDMI port for DP.
>
> By the way, you mean end up pushing "other" infoframes over DP?
We don't send infoframes over DP at all currently. Or I should say we
never intended to send them. After this patch that should even be true.
Well, unless the BIOS already enables them and we just fire up a DP port
using the transcoder in question. So I suppose we should really have the
DP code clear the infoframe settings explicitly, or we should clear them
during the sanitize phase.
>
> > all the infoframes when turning off the port.
> >
> > Also protect against two ports stomping on each other on g4x due to
> > the single video DIP instance. Now only the first port to enable
> > gets to send infoframes.
>
> So is, 2nd port doesn't gets to send infoframes, the expected behavior
> when two ports trying with a single DIP?
I'm not sure what's the best behaviour here. Either we somehow pick one
of the ports to send infoframes (first come first serve in this patch),
or we could just disable infoframes entirely for cloned cases. But it's
probably a rare configuration anyway since HDMI cloning is only allowed
on g4x.
>
> Seems like a corner case to test thoroughly. Is this path exercised in your
> testing?
I tested it long ago. Although I must admit that the patch looked a bit
different back then.
>
> >
> > v2: Rebase
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/intel_hdmi.c | 85
> > ++-
> > 1 file changed, 40 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 766bdb1..03b4759 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -514,7 +514,13 @@ static void g4x_set_infoframes(struct drm_encoder
> > *encoder,
> > if (!enable) {
> > if (!(val & VIDEO_DIP_ENABLE))
> > return;
> > - val &= ~VIDEO_DIP_ENABLE;
> > + if (port != (val & VIDEO_DIP_PORT_MASK)) {
> > + DRM_DEBUG_KMS("video DIP still enabled on port
> > %c\n",
> > + (val & VIDEO_DIP_PORT_MASK) >> 29);
> > + return;
> > + }
> > + val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI |
> > +VIDEO_DIP_ENABLE_VENDOR |
> > VIDEO_DIP_ENABLE_SPD);
> > I915_WRITE(reg, val);
> > POSTING_READ(reg);
> > return;
> > @@ -522,16 +528,17 @@ static void g4x_set_infoframes(struct drm_encoder
> > *encoder,
> >
> > if (port != (val & VIDEO_DIP_PORT_MASK)) {
> > if (val & VIDEO_DIP_ENABLE) {
> > - val &= ~VIDEO_DIP_ENABLE;
> > - I915_WRITE(reg, val);
> > - POSTING_READ(reg);
> > + DRM_DEBUG_KMS("video DIP already enabled on port
> > %c\n",
> > + (val & VIDEO_DIP_PORT_MASK) >> 29);
> > + return;
> > }
> > val &= ~VIDEO_DIP_PORT_MASK;
> > val |= port;
> > }
> >
> > val |= VIDEO_DIP_ENABLE;
> > - val &= ~VIDEO_DIP_ENABLE_VENDOR;
> > + val &= ~(VIDEO_DIP_ENABLE_AVI |
> > +VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
> >
> > I915_WRITE(reg, val);
> > POSTING_READ(reg);
> > @@ -632,23 +639,6 @@ static bool intel_hdmi_set_gcp_infoframe(struct
> > drm_encoder *encoder)
> > return val != 0;
> > }
> >
> > -static void intel_disable_gcp_infoframe(struct intel_crtc *crtc)
> > -{
> > - struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
> > - u32 reg;
> > -
> > - if (HAS_DDI(dev_priv))
> > - reg = HSW_TVIDEO_DIP_CTL(crtc->config->cpu_transcoder);
> > - else if (IS_VALLEYVIEW(dev_priv))
> > - reg = VLV_TVIDEO_DIP_CTL(crtc->pipe);
> > - else if (HAS_PCH_SPLIT(dev_priv->dev))
> > - reg = TVIDEO_DIP_CTL(crtc->pipe);
> > - else
> > - return;
> > -
> > - I915_WRITE(reg, I915_READ(reg) & ~VIDEO_DIP_ENABLE_GCP);
> > -}
> > -
> > static void ibx_set_infoframes(struct drm_encoder *encoder,
> >bool enable,
> >struct
Re: [Intel-gfx] [PATCH 1/7] drm/i915: Initialize Color Manager
On 6/2/2015 1:22 AM, Kausal Malladi wrote:
From: Kausal Malladi
Color Manager is an extension in i915 driver to handle color correction
and enhancements across various Intel platforms.
This patch initializes color manager framework by :
1. Adding two new files, intel_color_manager(.c/.h)
2. Introducing new pointers in DRM mode_config structure to
carry CSC and Gamma color correction properties.
3. Creating these DRM properties in Color Manager initialization
sequence.
Signed-off-by: Shashank Sharma
Signed-off-by: Kausal Malladi
---
drivers/gpu/drm/i915/Makefile |3 ++
drivers/gpu/drm/i915/intel_color_manager.c | 49
drivers/gpu/drm/i915/intel_color_manager.h | 32 ++
drivers/gpu/drm/i915/intel_display.c |5 +++
include/drm/drm_crtc.h |4 +++
5 files changed, 93 insertions(+)
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b7ddf48..c62d048 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -89,6 +89,9 @@ i915-y += i915_vgpu.o
# legacy horrors
i915-y += i915_dma.o
+# Color Management
+i915-y += intel_color_manager.o
+
obj-$(CONFIG_DRM_I915) += i915.o
CFLAGS_i915_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
b/drivers/gpu/drm/i915/intel_color_manager.c
new file mode 100644
index 000..c83a212
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Shashank Sharma
+ * Kausal Malladi
+ */
+
+#include "intel_color_manager.h"
+
+int intel_color_manager_init(struct drm_device *dev)
+{
+ struct drm_mode_config *config = &dev->mode_config;
+
+ /* Create Gamma and CSC properties */
+ config->gamma_property = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "gamma_property", 0);
+ if (!config->gamma_property)
+ DRM_ERROR("Gamma property creation failed\n");
+
+ DRM_DEBUG_DRIVER("Created Gamma property\n");
+
+ config->csc_property = drm_property_create(dev,
+ DRM_MODE_PROP_BLOB, "csc_property", 0);
+ if (!config->csc_property)
+ DRM_ERROR("CSC property creation failed\n");
+
+ DRM_DEBUG_DRIVER("Created CSC property\n");
+ return 0;
+}
diff --git a/drivers/gpu/drm/i915/intel_color_manager.h
b/drivers/gpu/drm/i915/intel_color_manager.h
new file mode 100644
index 000..3cff09d
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_color_manager.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH TH
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix command parser to validate multiple register access with the same command.
Zhigang Gong writes:
> The patchset LGTM and works well with beignet. The 80%+ performance
> regression issue in darktable also has been fixed
> after this patchset applied and enable the atomic in L3 at beignet side. So,
>
> Reviewed-by: Zhigang Gong
>
> Thanks,
> Zhigang Gong.
>
Thanks!
>> -Original Message-
>> From: Francisco Jerez [mailto:curroje...@riseup.net]
>> Sent: Friday, May 29, 2015 9:44 PM
>> To: intel-gfx@lists.freedesktop.org
>> Cc: Ville Syrjälä; Zhigang Gong; Brad Volkin
>> Subject: [PATCH 1/3] drm/i915: Fix command parser to validate multiple
>> register access with the same command.
>>
>> Until now the software command checker assumed that commands could read
>> or write at most a single register per packet. This is not necessarily the
>> case,
>> MI_LOAD_REGISTER_IMM expects a variable-length list of offset/value pairs
>> and writes them in sequence. The previous code would only check whether
>> the first entry was valid, effectively allowing userspace to write
>> unrestricted
>> registers of the MMIO space by sending a multi-register write with a legal
>> first
>> register, with potential security implications on Gen6 and 7 hardware.
>>
>> Fix it by extending the drm_i915_cmd_descriptor table to represent
>> multi-register access and making validate_cmd() iterate for all register
>> offsets
>> present in the command packet.
>>
>> Signed-off-by: Francisco Jerez
>> ---
>> drivers/gpu/drm/i915/i915_cmd_parser.c | 74
>> --
>> drivers/gpu/drm/i915/i915_drv.h| 5 +++
>> 2 files changed, 48 insertions(+), 31 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
>> b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> index 61ae8ff..c4a5f73 100644
>> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
>> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
>> @@ -123,7 +123,7 @@ static const struct drm_i915_cmd_descriptor
>> common_cmds[] = {
>> CMD( MI_SEMAPHORE_MBOX,SMI, !F, 0xFF,
>> R ),
>> CMD( MI_STORE_DWORD_INDEX, SMI, !F, 0xFF,
>> R ),
>> CMD( MI_LOAD_REGISTER_IMM(1), SMI, !F, 0xFF,
>> W,
>> - .reg = { .offset = 1, .mask = 0x007C } ),
>> + .reg = { .offset = 1, .mask = 0x007C, .step = 2 }),
>> CMD( MI_STORE_REGISTER_MEM(1), SMI, !F, 0xFF,
>> W | B,
>>.reg = { .offset = 1, .mask = 0x007C },
>>.bits = {{
>> @@ -939,7 +939,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs
>> *ring)
>>
>> static bool check_cmd(const struct intel_engine_cs *ring,
>>const struct drm_i915_cmd_descriptor *desc,
>> - const u32 *cmd,
>> + const u32 *cmd, u32 length,
>>const bool is_master,
>>bool *oacontrol_set)
>> {
>> @@ -955,38 +955,49 @@ static bool check_cmd(const struct intel_engine_cs
>> *ring,
>> }
>>
>> if (desc->flags & CMD_DESC_REGISTER) {
>> -u32 reg_addr = cmd[desc->reg.offset] & desc->reg.mask;
>> -
>> /*
>> - * OACONTROL requires some special handling for writes. We
>> - * want to make sure that any batch which enables OA also
>> - * disables it before the end of the batch. The goal is to
>> - * prevent one process from snooping on the perf data from
>> - * another process. To do that, we need to check the value
>> - * that will be written to the register. Hence, limit
>> - * OACONTROL writes to only MI_LOAD_REGISTER_IMM
>> commands.
>> + * Get the distance between individual register offset
>> + * fields if the command can perform more than one
>> + * access at a time.
>> */
>> -if (reg_addr == OACONTROL) {
>> -if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
>> -DRM_DEBUG_DRIVER("CMD: Rejected LRM to
>> OACONTROL\n");
>> -return false;
>> +const u32 step = desc->reg.step ? desc->reg.step : length;
>> +u32 offset;
>> +
>> +for (offset = desc->reg.offset; offset < length;
>> + offset += step) {
>> +const u32 reg_addr = cmd[offset] & desc->reg.mask;
>> +
>> +/*
>> + * OACONTROL requires some special handling for
>> + * writes. We want to make sure that any batch which
>> + * enables OA also disables it before the end of the
>> + * batch. The goal is to prevent one process from
>> + * snooping on the perf data from another process. To do
>> + * that, we need to check the value that will be written
>> + * to the register. Hence, limit OACONTROL writes to
>> + * only MI_LOAD_REGISTER_IMM comman
Re: [Intel-gfx] [PATCH v5 0/8] All sort of cdclk stuff
On Tue, Jun 02, 2015 at 10:20:58AM +0300, Mika Kahola wrote: > This patch series rebases Ville's original cdclk patch series > excluding the ones that has already been reviewed. FYI, When a patch that has been reviewed is resent, we usually but the r-b tags tags along (yes, I know, confusing with what has been said before) -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 8/8] drm/i915: HSW cdclk support
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6518 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 303/303 303/303 SNB -1 315/315 314/315 IVB 343/343 343/343 BYT 287/287 287/287 BDW -1 321/321 320/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *SNB igt@pm_rpm@dpms-mode-unset-non-lpsp PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_uncore.c:#assert_device_not_suspended[i915]()@WARNING:.* at .* assert_device_not_suspended+0x *BDW igt@gem_flink_race@flink_name PASS(1) DMESG_WARN(1) (dmesg patch applied)WARNING:at_drivers/gpu/drm/i915/intel_display.c:#assert_plane[i915]()@WARNING:.* at .* assert_plane assertion_failure@assertion failure WARNING:at_drivers/gpu/drm/drm_irq.c:#drm_wait_one_vblank[drm]()@WARNING:.* at .* drm_wait_one_vblank+0x Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915: Fix DDC probe for passive adapters
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC protocol. The retry loop inside of
drm_do_probe_ddc_edid() would normally catch this case and try the
transaction again, resulting in success.
That, however, was thwarted by the fix for [1]:
commit 9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov
Date: Thu Jan 5 09:34:28 2012 -0200
drm: give up on edid retries when i2c bus is not responding
This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time
spent in waiting for unresponsive or disconnected devices. That was
possible because the underlying i2c bit banging algorithm had retries of
its own (which, of course, were part of the reason for the bug the
commit fixes).
Since its introduction in
commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
we've been flipping back and forth enabling the GMBUS transfers, but
we've settled since then. The GMBUS implementation does not do any
retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
the retry on -ENXIO.
Retry GMBUS once on -ENXIO on first message to mitigate the issues with
passive adapters.
This patch is based on the work, and commit message, by Todd Previte
.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
v2: Don't retry if using bit banging.
v3: Move retry within gmbux_xfer, retry only on first message.
v4: Initialize GMBUS0 on retry (Ville).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
Cc: Todd Previte
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 92072f56e418..5f2e88d39baf 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -486,7 +486,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct intel_gmbus,
adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
- int i, reg_offset;
+ int i = 0, try = 0, reg_offset;
int ret = 0;
intel_aux_display_runtime_get(dev_priv);
@@ -499,9 +499,10 @@ gmbus_xfer(struct i2c_adapter *adapter,
reg_offset = dev_priv->gpio_mmio_base;
+retry:
I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
- for (i = 0; i < num; i++) {
+ for (; i < num; i++) {
if (gmbus_is_index_read(msgs, i, num)) {
ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
i += 1; /* set i to the index of the read xfer */
@@ -576,6 +577,18 @@ clear_err:
adapter->name, msgs[i].addr,
(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
+ /*
+* Passive adapters sometimes NAK the first probe. Retry once on -ENXIO
+* for GMBUS transfers; the bit banging algorithm has retries
+* internally. See also the retry loop in drm_do_probe_ddc_edid, which
+* bails out on the first -ENXIO.
+*/
+ if (ret == -ENXIO && i == 0 && try++ == 0) {
+ DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
+ adapter->name);
+ goto retry;
+ }
+
goto out;
timeout:
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Fix DDC probe for passive adapters
On Tue, Jun 02, 2015 at 11:29:23AM +0300, Jani Nikula wrote:
> Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
> devices, as they do not have a sink device in them to respond to any AUX
> traffic. When probing these dongles over the DDC, sometimes they will
> NAK the first attempt even though the transaction is valid and they
> support the DDC protocol. The retry loop inside of
> drm_do_probe_ddc_edid() would normally catch this case and try the
> transaction again, resulting in success.
>
> That, however, was thwarted by the fix for [1]:
>
> commit 9292f37e1f5c79400254dca46f83313488093825
> Author: Eugeni Dodonov
> Date: Thu Jan 5 09:34:28 2012 -0200
>
> drm: give up on edid retries when i2c bus is not responding
>
> This added code to exit immediately if the return code from the
> i2c_transfer function was -ENXIO in order to reduce the amount of time
> spent in waiting for unresponsive or disconnected devices. That was
> possible because the underlying i2c bit banging algorithm had retries of
> its own (which, of course, were part of the reason for the bug the
> commit fixes).
>
> Since its introduction in
>
> commit f899fc64cda8569d0529452aafc0da31c042df2e
> Author: Chris Wilson
> Date: Tue Jul 20 15:44:45 2010 -0700
>
> drm/i915: use GMBUS to manage i2c links
>
> we've been flipping back and forth enabling the GMBUS transfers, but
> we've settled since then. The GMBUS implementation does not do any
> retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
> on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
> the retry on -ENXIO.
>
> Retry GMBUS once on -ENXIO on first message to mitigate the issues with
> passive adapters.
>
> This patch is based on the work, and commit message, by Todd Previte
> .
>
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
>
> v2: Don't retry if using bit banging.
>
> v3: Move retry within gmbux_xfer, retry only on first message.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
> Cc: Todd Previte
> Cc: sta...@vger.kernel.org
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index 92072f56e418..5519ad3a9574 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -486,7 +486,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
> struct intel_gmbus,
> adapter);
> struct drm_i915_private *dev_priv = bus->dev_priv;
> - int i, reg_offset;
> + int i, try = 0, reg_offset;
> int ret = 0;
>
> intel_aux_display_runtime_get(dev_priv);
> @@ -502,6 +502,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
> I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
>
> for (i = 0; i < num; i++) {
> +retry:
> if (gmbus_is_index_read(msgs, i, num)) {
> ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
> i += 1; /* set i to the index of the read xfer */
> @@ -576,6 +577,18 @@ clear_err:
>adapter->name, msgs[i].addr,
>(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
>
> + /*
> + * Passive adapters sometimes NAK the first probe. Retry once on -ENXIO
> + * for GMBUS transfers; the bit banging algorithm has retries
> + * internally. See also the retry loop in drm_do_probe_ddc_edid, which
> + * bails out on the first -ENXIO.
> + */
> + if (ret == -ENXIO && i == 0 && try++ == 0) {
> + DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
> + adapter->name);
> + goto retry;
> + }
> +
This would leave GMBUS0 set to 0 for the retry.
> goto out;
>
> timeout:
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/21] drm/i915/gtt: Introduce i915_page_dir_dma_addr
On 5/22/2015 6:05 PM, Mika Kuoppala wrote:
The legacy mode mm switch and the execlist context assignment
needs dma address for the page directories.
Introduce a function that encapsulates the scratch_pd dma
fallback if no pd is found.
Signed-off-by: Mika Kuoppala
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 6 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 8
drivers/gpu/drm/i915/intel_lrc.c| 4 +---
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4cf47f9..18989f7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -481,10 +481,8 @@ static int gen8_mm_switch(struct i915_hw_ppgtt *ppgtt,
int i, ret;
for (i = GEN8_LEGACY_PDPES - 1; i >= 0; i--) {
- struct i915_page_directory *pd = ppgtt->pdp.page_directory[i];
- dma_addr_t pd_daddr = pd ? pd->daddr : ppgtt->scratch_pd->daddr;
- /* The page directory might be NULL, but we need to clear out
-* whatever the previous context might have used. */
+ const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
+
ret = gen8_write_pdp(ring, i, pd_daddr);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index c343161..da67542 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -468,6 +468,14 @@ static inline size_t gen8_pte_count(uint64_t address,
uint64_t length)
return i915_pte_count(address, length, GEN8_PDE_SHIFT);
}
+static inline dma_addr_t
+i915_page_dir_dma_addr(const struct i915_hw_ppgtt *ppgtt, const unsigned n)
+{
+ return test_bit(n, ppgtt->pdp.used_pdpes) ?
+ ppgtt->pdp.page_directory[n]->daddr :
+ ppgtt->scratch_pd->daddr;
+}
+
int i915_gem_gtt_init(struct drm_device *dev);
void i915_gem_init_global_gtt(struct drm_device *dev);
void i915_global_gtt_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d793d4e..626949a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -184,9 +184,7 @@
#define CTX_GPGPU_CSR_BASE_ADDRESS 0x44
#define ASSIGN_CTX_PDP(ppgtt, reg_state, n) { \
- const u64 _addr = test_bit(n, ppgtt->pdp.used_pdpes) ? \
- ppgtt->pdp.page_directory[n]->daddr : \
- ppgtt->scratch_pd->daddr; \
+ const u64 _addr = i915_page_dir_dma_addr((ppgtt), (n)); \
reg_state[CTX_PDP ## n ## _UDW+1] = upper_32_bits(_addr); \
reg_state[CTX_PDP ## n ## _LDW+1] = lower_32_bits(_addr); \
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/21] drm/i915/gtt: Remove _single from page table allocator
On 5/22/2015 6:04 PM, Mika Kuoppala wrote: We are always allocating a single page. No need to be verbose so remove the suffix. Signed-off-by: Mika Kuoppala I saw another of your patches will take care of i915_dma_map_single/i915_dma_unmap_single... Reviewed-by: Michel Thierry ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/21] drm/i915/gtt: Remove _single from page table allocator
On pe, 2015-05-22 at 20:04 +0300, Mika Kuoppala wrote:
> We are always allocating a single page. No need to be verbose so
> remove the suffix.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index a608b1b..4cf47f9 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -369,7 +369,7 @@ static void gen8_initialize_pt(struct i915_address_space
> *vm,
> kunmap_atomic(pt_vaddr);
> }
>
> -static struct i915_page_table *alloc_pt_single(struct drm_device *dev)
> +static struct i915_page_table *alloc_pt(struct drm_device *dev)
> {
> struct i915_page_table *pt;
> const size_t count = INTEL_INFO(dev)->gen >= 8 ?
> @@ -417,7 +417,7 @@ static void unmap_and_free_pd(struct i915_page_directory
> *pd,
> }
> }
>
> -static struct i915_page_directory *alloc_pd_single(struct drm_device *dev)
> +static struct i915_page_directory *alloc_pd(struct drm_device *dev)
> {
> struct i915_page_directory *pd;
> int ret = -ENOMEM;
> @@ -702,7 +702,7 @@ static int gen8_ppgtt_alloc_pagetabs(struct i915_hw_ppgtt
> *ppgtt,
> continue;
> }
>
> - pt = alloc_pt_single(dev);
> + pt = alloc_pt(dev);
> if (IS_ERR(pt))
> goto unwind_out;
>
> @@ -760,7 +760,7 @@ static int gen8_ppgtt_alloc_page_directories(struct
> i915_hw_ppgtt *ppgtt,
> if (pd)
> continue;
>
> - pd = alloc_pd_single(dev);
> + pd = alloc_pd(dev);
> if (IS_ERR(pd))
> goto unwind_out;
>
> @@ -992,11 +992,11 @@ static int gen8_preallocate_top_level_pdps(struct
> i915_hw_ppgtt *ppgtt)
> */
> static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
> {
> - ppgtt->scratch_pt = alloc_pt_single(ppgtt->base.dev);
> + ppgtt->scratch_pt = alloc_pt(ppgtt->base.dev);
> if (IS_ERR(ppgtt->scratch_pt))
> return PTR_ERR(ppgtt->scratch_pt);
>
> - ppgtt->scratch_pd = alloc_pd_single(ppgtt->base.dev);
> + ppgtt->scratch_pd = alloc_pd(ppgtt->base.dev);
> if (IS_ERR(ppgtt->scratch_pd))
> return PTR_ERR(ppgtt->scratch_pd);
>
> @@ -1375,7 +1375,7 @@ static int gen6_alloc_va_range(struct
> i915_address_space *vm,
> /* We've already allocated a page table */
> WARN_ON(!bitmap_empty(pt->used_ptes, GEN6_PTES));
>
> - pt = alloc_pt_single(dev);
> + pt = alloc_pt(dev);
> if (IS_ERR(pt)) {
> ret = PTR_ERR(pt);
> goto unwind_out;
> @@ -1461,7 +1461,7 @@ static int gen6_ppgtt_allocate_page_directories(struct
> i915_hw_ppgtt *ppgtt)
>* size. We allocate at the top of the GTT to avoid fragmentation.
>*/
> BUG_ON(!drm_mm_initialized(&dev_priv->gtt.base.mm));
> - ppgtt->scratch_pt = alloc_pt_single(ppgtt->base.dev);
> + ppgtt->scratch_pt = alloc_pt(ppgtt->base.dev);
> if (IS_ERR(ppgtt->scratch_pt))
> return PTR_ERR(ppgtt->scratch_pt);
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/vlv: fix RC6 residency time calculation
On ma, 2015-06-01 at 12:01 -0700, Rodrigo Vivi wrote:
> On Mon, Jun 1, 2015 at 12:32 AM, Imre Deak wrote:
> > The divider value to convert from CZ clock rate to ms needs a +1
> > adjustment on VLV just like on CHV. This matches both the spec and
> > the accuracy test by pm_rc6_residency.
> >
> > v2:
> > - simplify logic checking for the CHV 320MHz special case (Rodrigo)
> >
> > Testcase: igt/pm_rc6_residency
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_sysfs.c | 22 +++---
> > 1 file changed, 7 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> > b/drivers/gpu/drm/i915/i915_sysfs.c
> > index 2476268..55bd04c 100644
> > --- a/drivers/gpu/drm/i915/i915_sysfs.c
> > +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> > @@ -64,24 +64,16 @@ static u32 calc_residency(struct drm_device *dev, const
> > u32 reg)
> > goto out;
> > }
> >
> > - units = 0;
> > - div = 100ULL;
> > -
> > - if (IS_CHERRYVIEW(dev)) {
> > + if (IS_CHERRYVIEW(dev) && czcount_30ns == 1) {
> > /* Special case for 320Mhz */
> > - if (czcount_30ns == 1) {
> > - div = 1000ULL;
> > - units = 3125ULL;
> > - } else {
> > - /* chv counts are one less */
> > - czcount_30ns += 1;
> > - }
> > + div = 1000ULL;
> > + units = 3125ULL;
> > + } else {
> > + czcount_30ns += 1;
> > + div = 100ULL;
> > + units = DIV_ROUND_UP_ULL(30ULL * bias,
> > czcount_30ns);
> Is (u64) cast unnecessary?
Yes. Here the only reason for it would be overflow, but that's not
possible.
> But reading like this now I wonder if we couldn't just pass
> czcount_30ns+1 instead of the increment...
> But if we don't need the cast let's please just ignore this bikeshed
> and let's move fwd! ;)
Yes, I think we could do more cleanup in this function as a follow-up.
For example we may still loose precision in the current way, would be
better to calculate the result directly from the reference clock rate
(CZ clock in case of VLV/CHV).
> More organized than I had suggested, thanks.
>
> Reviewed-by: Rodrigo Vivi
Thanks.
Forgot to add:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76877
> > }
> >
> > - if (units == 0)
> > - units = DIV_ROUND_UP_ULL(30ULL * bias,
> > -(u64)czcount_30ns);
> > -
> > if (I915_READ(VLV_COUNTER_CONTROL) & VLV_COUNT_RANGE_HIGH)
> > units <<= 8;
> >
> > --
> > 2.1.4
> >
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix command parser to validate multiple register access with the same command.
The patchset LGTM and works well with beignet. The 80%+ performance regression
issue in darktable also has been fixed
after this patchset applied and enable the atomic in L3 at beignet side. So,
Reviewed-by: Zhigang Gong
Thanks,
Zhigang Gong.
> -Original Message-
> From: Francisco Jerez [mailto:curroje...@riseup.net]
> Sent: Friday, May 29, 2015 9:44 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Ville Syrjälä; Zhigang Gong; Brad Volkin
> Subject: [PATCH 1/3] drm/i915: Fix command parser to validate multiple
> register access with the same command.
>
> Until now the software command checker assumed that commands could read
> or write at most a single register per packet. This is not necessarily the
> case,
> MI_LOAD_REGISTER_IMM expects a variable-length list of offset/value pairs
> and writes them in sequence. The previous code would only check whether
> the first entry was valid, effectively allowing userspace to write
> unrestricted
> registers of the MMIO space by sending a multi-register write with a legal
> first
> register, with potential security implications on Gen6 and 7 hardware.
>
> Fix it by extending the drm_i915_cmd_descriptor table to represent
> multi-register access and making validate_cmd() iterate for all register
> offsets
> present in the command packet.
>
> Signed-off-by: Francisco Jerez
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 74
> --
> drivers/gpu/drm/i915/i915_drv.h| 5 +++
> 2 files changed, 48 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser.c
> index 61ae8ff..c4a5f73 100644
> --- a/drivers/gpu/drm/i915/i915_cmd_parser.c
> +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
> @@ -123,7 +123,7 @@ static const struct drm_i915_cmd_descriptor
> common_cmds[] = {
> CMD( MI_SEMAPHORE_MBOX,SMI, !F, 0xFF,
> R ),
> CMD( MI_STORE_DWORD_INDEX, SMI, !F, 0xFF,
> R ),
> CMD( MI_LOAD_REGISTER_IMM(1), SMI, !F, 0xFF,
> W,
> - .reg = { .offset = 1, .mask = 0x007C } ),
> + .reg = { .offset = 1, .mask = 0x007C, .step = 2 }),
> CMD( MI_STORE_REGISTER_MEM(1), SMI, !F, 0xFF,
> W | B,
> .reg = { .offset = 1, .mask = 0x007C },
> .bits = {{
> @@ -939,7 +939,7 @@ bool i915_needs_cmd_parser(struct intel_engine_cs
> *ring)
>
> static bool check_cmd(const struct intel_engine_cs *ring,
> const struct drm_i915_cmd_descriptor *desc,
> - const u32 *cmd,
> + const u32 *cmd, u32 length,
> const bool is_master,
> bool *oacontrol_set)
> {
> @@ -955,38 +955,49 @@ static bool check_cmd(const struct intel_engine_cs
> *ring,
> }
>
> if (desc->flags & CMD_DESC_REGISTER) {
> - u32 reg_addr = cmd[desc->reg.offset] & desc->reg.mask;
> -
> /*
> - * OACONTROL requires some special handling for writes. We
> - * want to make sure that any batch which enables OA also
> - * disables it before the end of the batch. The goal is to
> - * prevent one process from snooping on the perf data from
> - * another process. To do that, we need to check the value
> - * that will be written to the register. Hence, limit
> - * OACONTROL writes to only MI_LOAD_REGISTER_IMM
> commands.
> + * Get the distance between individual register offset
> + * fields if the command can perform more than one
> + * access at a time.
>*/
> - if (reg_addr == OACONTROL) {
> - if (desc->cmd.value == MI_LOAD_REGISTER_MEM) {
> - DRM_DEBUG_DRIVER("CMD: Rejected LRM to
> OACONTROL\n");
> - return false;
> + const u32 step = desc->reg.step ? desc->reg.step : length;
> + u32 offset;
> +
> + for (offset = desc->reg.offset; offset < length;
> + offset += step) {
> + const u32 reg_addr = cmd[offset] & desc->reg.mask;
> +
> + /*
> + * OACONTROL requires some special handling for
> + * writes. We want to make sure that any batch which
> + * enables OA also disables it before the end of the
> + * batch. The goal is to prevent one process from
> + * snooping on the perf data from another process. To do
> + * that, we need to check the value that will be written
> + * to the register. Hence, limit OACONTROL writes to
> + * only MI_LOAD_REGISTER_IMM commands.
> + */
> + if (reg_addr == OACONTROL) {
> +
Re: [Intel-gfx] [PATCH 00/24] Convert to atomic, part 3.
Op 01-06-15 om 15:27 schreef Maarten Lankhorst: > This patch series requires the following prerequisites: > "[PATCH v4 00/27] Convert to atomic, part 2" > "[PATCH] drm/atomic: Clear crtc_state->active in > drm_atomic_helper_set_config." > > Now that suspend/restore is atomic it's time to clean up some > remaining issues. First I clean up the suspend code some more now > that it's atomic. > > After that I try to make a better separation between checking and > modeset. This meant that intel_modeset_pipe_config should no longer > touch mode_changed, because it will only be called when a modeset > will already happen to prevent excessive rechecking. > > I also clean up the scaler stuff slightly, and add a hack to allow > switching a plane to/from hq mode without requiring it to be part > of the state. This allows calling intel_atomic_update_scalers from > the crtc_check function, although I guess in theory there wouldn't > be much harm adding a plane. This part's open for debate, if people > prefer a different approach I'd be fine with it. :-) > > After those changes drm_atomic_commit and intel_set_mode become very > similar, but it's still too early to use intel_set_mode as a > replacement. > > First planes have to be converted to atomic, which is done by > splitting out the updates of intel_crtc->atomic to a helper. > Most of the changes to intel_crtc->atomic will not be done during a > modeset, because all state will be updated regardless. > > After this is split out converting planes to atomic in intel_set_mode > is simply a matter of updating intel_crtc->atomic during modeset and > calling the helpers we split out. > > Maarten Lankhorst (24): > drm/i915: Always reset in intel_crtc_restore_mode > drm/i915: Use crtc state in intel_modeset_pipe_config > drm/i915: clean up intel_sanitize_crtc > drm/i915: Update power domains only on affected crtc's. > drm/i915: add fastboot checks for has_audio and has_infoframe > drm/i915: Clean up intel_atomic_setup_scalers slightly. > drm/i915: Add a simple atomic crtc check function. > drm/i915: Do not add planes from intel_atomic_setup_scalers. > drm/i915: Assign a new pll from the crtc check function. > drm/i915: Do not run most checks when there's no modeset. > drm/i915: Split skl_update_scaler. > drm/i915: Split plane updates of crtc->atomic into a helper. > drm/i915: move detaching scalers to begin_crtc_commit > drm/i915: Move crtc commit updates to separate functions. Note to reviewers: after I looked at how to clear cursor/sprites on initial modeset work I had to reorder some patches. Can I get this series only reviewed for up to "[PATCH 14/24] drm/i915: Move crtc commit updates to separate functions." ? Although I wouldn't mind a cursory glance at the other patches, see if the approach looks sane. :-) ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Fix DDC probe for passive adapters
Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC protocol. The retry loop inside of
drm_do_probe_ddc_edid() would normally catch this case and try the
transaction again, resulting in success.
That, however, was thwarted by the fix for [1]:
commit 9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov
Date: Thu Jan 5 09:34:28 2012 -0200
drm: give up on edid retries when i2c bus is not responding
This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time
spent in waiting for unresponsive or disconnected devices. That was
possible because the underlying i2c bit banging algorithm had retries of
its own (which, of course, were part of the reason for the bug the
commit fixes).
Since its introduction in
commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson
Date: Tue Jul 20 15:44:45 2010 -0700
drm/i915: use GMBUS to manage i2c links
we've been flipping back and forth enabling the GMBUS transfers, but
we've settled since then. The GMBUS implementation does not do any
retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
the retry on -ENXIO.
Retry GMBUS once on -ENXIO on first message to mitigate the issues with
passive adapters.
This patch is based on the work, and commit message, by Todd Previte
.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
v2: Don't retry if using bit banging.
v3: Move retry within gmbux_xfer, retry only on first message.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
Cc: Todd Previte
Cc: sta...@vger.kernel.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_i2c.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 92072f56e418..5519ad3a9574 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -486,7 +486,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct intel_gmbus,
adapter);
struct drm_i915_private *dev_priv = bus->dev_priv;
- int i, reg_offset;
+ int i, try = 0, reg_offset;
int ret = 0;
intel_aux_display_runtime_get(dev_priv);
@@ -502,6 +502,7 @@ gmbus_xfer(struct i2c_adapter *adapter,
I915_WRITE(GMBUS0 + reg_offset, bus->reg0);
for (i = 0; i < num; i++) {
+retry:
if (gmbus_is_index_read(msgs, i, num)) {
ret = gmbus_xfer_index_read(dev_priv, &msgs[i]);
i += 1; /* set i to the index of the read xfer */
@@ -576,6 +577,18 @@ clear_err:
adapter->name, msgs[i].addr,
(msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
+ /*
+* Passive adapters sometimes NAK the first probe. Retry once on -ENXIO
+* for GMBUS transfers; the bit banging algorithm has retries
+* internally. See also the retry loop in drm_do_probe_ddc_edid, which
+* bails out on the first -ENXIO.
+*/
+ if (ret == -ENXIO && i == 0 && try++ == 0) {
+ DRM_DEBUG_KMS("GMBUS [%s] NAK on first message, retry\n",
+ adapter->name);
+ goto retry;
+ }
+
goto out;
timeout:
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: changed the filename of csr firmware
On 27.05.2015 14:34, Daniel Vetter wrote: > On Tue, May 26, 2015 at 05:21:56PM -0700, Rodrigo Vivi wrote: >> On Thu, May 21, 2015 at 5:04 AM, Animesh Manna >> wrote: >>> Naming convention of csr firmware will be - >>> _dmc__.bin >>> >>> Accordingly updated the same in code. >>> >>> Signed-off-by: Animesh Manna >>> --- >>> drivers/gpu/drm/i915/intel_csr.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/i915/intel_csr.c >>> b/drivers/gpu/drm/i915/intel_csr.c >>> index fec2bc5..9bd05bf 100644 >>> --- a/drivers/gpu/drm/i915/intel_csr.c >>> +++ b/drivers/gpu/drm/i915/intel_csr.c >>> @@ -34,7 +34,7 @@ >>> * low-power state and comes back to normal. >>> */ >>> >>> -#define I915_CSR_SKL "i915/skl_dmc_ver4.bin" >>> +#define I915_CSR_SKL "i915/skl_dmc_1_4.bin" >> >> I believe in this case the install instructions should point to copy >> instead of linking it, but not hardcode the release version. >> >> So shouldn't it be i915/skl_dmc_ver1.bin then? >> >> or i915/skl_dmc_ver1_4.bin in worst case... > > While at it, can we perhaps _not_ hardcode the minor revision? Hardcoding > the minor revision torpedoes the entire concept of even having a minor > revision. If the firmware team can't do proper abi versioning, then imo we > should just put one number for each and keep it at that. > -Daniel Can we please settle on something? I'd rather have the csr fw in linux-firmware quite soon, so that the driver wouldn't give an ugly assert when csr doesn't work. -- t ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/21] drm/i915/gtt: Don't leak scratch page on mapping error
On pe, 2015-05-22 at 20:04 +0300, Mika Kuoppala wrote:
> Free the scratch page if dma mapping fails.
>
> Signed-off-by: Mika Kuoppala
Reviewed-by: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index c61de4a..a608b1b 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2191,8 +2191,10 @@ static int setup_scratch_page(struct drm_device *dev)
> #ifdef CONFIG_INTEL_IOMMU
> dma_addr = pci_map_page(dev->pdev, page, 0, PAGE_SIZE,
> PCI_DMA_BIDIRECTIONAL);
> - if (pci_dma_mapping_error(dev->pdev, dma_addr))
> + if (pci_dma_mapping_error(dev->pdev, dma_addr)) {
> + __free_page(page);
> return -EINVAL;
> + }
> #else
> dma_addr = page_to_phys(page);
> #endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't check modeset state in the hw state force restore path
On Tue, 2015-06-02 at 09:27 +0200, Maarten Lankhorst wrote: > Op 02-06-15 om 09:12 schreef Jani Nikula: > > On Mon, 01 Jun 2015, Ander Conselvan de Oliveira > > wrote: > >> Since the force restore logic will restore the CRTCs state one at a > >> time, it is possible that the state will be inconsistent until the whole > >> operation finishes. A call to intel_modeset_check_state() is done once > >> it's over, so don't check the state multiple times in between. This > >> regression was introduced in: > >> > >> commit 7f27126ea3db6ade886f18fd39caf0ff0cd1d37f > >> Author: Jesse Barnes > >> Date: Wed Nov 5 14:26:06 2014 -0800 > >> > >> drm/i915: factor out compute_config from __intel_set_mode v3 > >> > >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431 > >> Cc: Jesse Barnes > >> Signed-off-by: Ander Conselvan de Oliveira > >> > >> --- > >> > >> Hi, > >> > >> This patch applies on top of nightly, but it is only relevant without > >> Maarten's "drm/i915: Convert to atomic, part 2" series, because of the > >> changes to the hw state read out and force restore logic. > >> > >> The regression exists since 3.19. > > Sooo, I think this should be applied to fixes, with cc: stable v3.19+, > > and IIUC Maarten's series makes this obsolete in dinq? > > > > Now we just need review... Maarten? > > > > BR, > > Jani. > Reviewed-by: Maarten Lankhorst > > Looks good to me, but it will conflict with my own patch series. :( I think it's fine to skip this for dinq, since we move to a single modeset in the force restore path with your patch series. I just got confused with what branch to base this on. Thanks for reviewing. Ander ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't check modeset state in the hw state force restore path
Op 02-06-15 om 09:12 schreef Jani Nikula: > On Mon, 01 Jun 2015, Ander Conselvan de Oliveira > wrote: >> Since the force restore logic will restore the CRTCs state one at a >> time, it is possible that the state will be inconsistent until the whole >> operation finishes. A call to intel_modeset_check_state() is done once >> it's over, so don't check the state multiple times in between. This >> regression was introduced in: >> >> commit 7f27126ea3db6ade886f18fd39caf0ff0cd1d37f >> Author: Jesse Barnes >> Date: Wed Nov 5 14:26:06 2014 -0800 >> >> drm/i915: factor out compute_config from __intel_set_mode v3 >> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431 >> Cc: Jesse Barnes >> Signed-off-by: Ander Conselvan de Oliveira >> >> --- >> >> Hi, >> >> This patch applies on top of nightly, but it is only relevant without >> Maarten's "drm/i915: Convert to atomic, part 2" series, because of the >> changes to the hw state read out and force restore logic. >> >> The regression exists since 3.19. > Sooo, I think this should be applied to fixes, with cc: stable v3.19+, > and IIUC Maarten's series makes this obsolete in dinq? > > Now we just need review... Maarten? > > BR, > Jani. Reviewed-by: Maarten Lankhorst Looks good to me, but it will conflict with my own patch series. :( ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/8] All sort of cdclk stuff
This patch series rebases Ville's original cdclk patch series excluding the ones that has already been reviewed. http://lists.freedesktop.org/archives/intel-gfx/2014-November/055633.html The patches are rebased to the latest drm-intel-nightly. The major change to the original series is the patch order change for Broadwell and Haswell. Now, the Broadwell CD clock patch can be applied before Haswell CD clock patch. This way, if decided, the CD clock change for Haswell can be discarded without affecting the Broadwell patch. Ville Syrjälä (8): drm/i915: Cache current cdclk frequency in dev_priv drm/i915: Use cached cdclk value drm/i915: Unify ilk and hsw .get_aux_clock_divider drm/i915: Store max cdclk value in dev_priv drm/i915: Don't enable IPS when pixel rate exceeds 95% drm/i915: Add IS_BDW_ULX drm/i915: BDW clock change support drm/i915: HSW cdclk support drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_display.c | 408 +-- drivers/gpu/drm/i915/intel_dp.c | 24 +-- drivers/gpu/drm/i915/intel_drv.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 19 +- 6 files changed, 415 insertions(+), 47 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 7/8] drm/i915: BDW clock change support
From: Ville Syrjälä
Add support for changing cdclk frequency during runtime on BDW. The
procedure is quite a bit different on BDW from the one on HSW, so
add a separate function for it.
Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
so take that into account when computing the max pixel rate.
v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
Signed-off-by: Ville Syrjälä
v4: Rebased to the latest
v5: Rebased to the latest
v6: Patch order shuffle so that Broadwell CD clock change is
applied before the patch for Haswell CD clock change
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 216 +--
2 files changed, 208 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7213224..0f72c0e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6705,6 +6705,7 @@ enum skl_disp_power_wells {
#define GEN6_PCODE_READ_RC6VIDS 0x5
#define GEN6_ENCODE_RC6_VID(mv)(((mv) - 245) / 5)
#define GEN6_DECODE_RC6_VID(vids) (((vids) * 5) + 245)
+#define BDW_PCODE_DISPLAY_FREQ_CHANGE_REQ0x18
#define GEN9_PCODE_READ_MEM_LATENCY 0x6
#define GEN9_MEM_LATENCY_LEVEL_MASK0xFF
#define GEN9_MEM_LATENCY_LEVEL_1_5_SHIFT 8
@@ -7170,6 +7171,7 @@ enum skl_disp_power_wells {
#define LCPLL_CLK_FREQ_337_5_BDW (2<<26)
#define LCPLL_CLK_FREQ_675_BDW(3<<26)
#define LCPLL_CD_CLOCK_DISABLE(1<<25)
+#define LCPLL_ROOT_CD_CLOCK_DISABLE (1<<24)
#define LCPLL_CD2X_CLOCK_DISABLE (1<<23)
#define LCPLL_POWER_DOWN_ALLOW(1<<22)
#define LCPLL_CD_SOURCE_FCLK (1<<21)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 961535e..3f50bb1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5751,7 +5751,22 @@ static void intel_update_max_cdclk(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- if (IS_VALLEYVIEW(dev)) {
+ if (IS_BROADWELL(dev)) {
+ /*
+* FIXME with extra cooling we can allow
+* 540 MHz for ULX and 675 Mhz for ULT.
+* How can we know if extra cooling is
+* available? PCI ID, VTB, something else?
+*/
+ if (I915_READ(FUSE_STRAP) & HSW_CDCLK_LIMIT)
+ dev_priv->max_cdclk_freq = 45;
+ else if (IS_BDW_ULX(dev))
+ dev_priv->max_cdclk_freq = 45;
+ else if (IS_BDW_ULT(dev))
+ dev_priv->max_cdclk_freq = 54;
+ else
+ dev_priv->max_cdclk_freq = 675000;
+ } else if (IS_VALLEYVIEW(dev)) {
dev_priv->max_cdclk_freq = 40;
} else {
/* otherwise assume cdclk is fixed */
@@ -6623,13 +6638,11 @@ static bool pipe_config_supports_ips(struct
drm_i915_private *dev_priv,
return true;
/*
-* FIXME if we compare against max we should then
-* increase the cdclk frequency when the current
-* value is too low. The other option is to compare
-* against the cdclk frequency we're going have post
-* modeset (ie. one we computed using other constraints).
-* Need to measure whether using a lower cdclk w/o IPS
-* is better or worse than a higher cdclk w/ IPS.
+* We compare against max which means we must take
+* the increased cdclk requirement into account when
+* calculating the new cdclk.
+*
+* Should measure whether using a lower cdclk w/o IPS
*/
return ilk_pipe_pixel_rate(pipe_config) <=
dev_priv->max_cdclk_freq * 95 / 100;
@@ -9610,6 +9623,182 @@ static void broxton_modeset_global_resources(struct
drm_atomic_state *old_state)
broxton_set_cdclk(dev, req_cdclk);
}
+/* compute the max rate for new configuration */
+static int ilk_max_pixel_rate(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv->dev;
+ struct intel_crtc *intel_crtc;
+ struct drm_crtc *crtc;
+ int max_pixel_rate = 0;
+ int pixel_rate;
+
+ for_each_crtc(dev, crtc) {
+ if (!crtc->state->enable)
+ continue;
+
+ intel_crtc = to_intel_crtc(crtc);
+ pixel_rate = ilk_pipe_pixel_rate(intel_crtc->config);
+
+ /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
+ if (IS_BROADWELL(dev) && intel_crtc->config->ips_enabled)
+ pixel_rate = DIV_ROUND_UP(p
[Intel-gfx] [PATCH v5 3/8] drm/i915: Unify ilk and hsw .get_aux_clock_divider
From: Ville Syrjälä
ilk_get_aux_clock_divider() is now a subset of
hsw_get_aux_clock_divider() so unify them.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 23 +++
1 file changed, 3 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9a6517d..959f115 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -704,23 +704,6 @@ static uint32_t ilk_get_aux_clock_divider(struct intel_dp
*intel_dp, int index)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- if (index)
- return 0;
-
- if (intel_dig_port->port == PORT_A) {
- return DIV_ROUND_UP(dev_priv->cdclk_freq, 2000);
-
- } else {
- return DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
- }
-}
-
-static uint32_t hsw_get_aux_clock_divider(struct intel_dp *intel_dp, int index)
-{
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct drm_device *dev = intel_dig_port->base.base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
-
if (intel_dig_port->port == PORT_A) {
if (index)
return 0;
@@ -733,7 +716,9 @@ static uint32_t hsw_get_aux_clock_divider(struct intel_dp
*intel_dp, int index)
default: return 0;
}
} else {
- return index ? 0 : DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
+ if (index)
+ return 0;
+ return DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
}
}
@@ -5746,8 +5731,6 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp->get_aux_clock_divider = skl_get_aux_clock_divider;
else if (IS_VALLEYVIEW(dev))
intel_dp->get_aux_clock_divider = vlv_get_aux_clock_divider;
- else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- intel_dp->get_aux_clock_divider = hsw_get_aux_clock_divider;
else if (HAS_PCH_SPLIT(dev))
intel_dp->get_aux_clock_divider = ilk_get_aux_clock_divider;
else
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/8] drm/i915: Cache current cdclk frequency in dev_priv
From: Ville Syrjälä
Rather that extracting the current cdclk freuqncy every time someone
wants to know it, cache the current value and use that. VLV/CHV already
stored a cached value there so just expand that to cover all platforms.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
v4: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 16e159d..4dd00a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5747,7 +5747,7 @@ static int valleyview_get_vco(struct drm_i915_private
*dev_priv)
return vco_freq[hpll_freq] * 1000;
}
-static void vlv_update_cdclk(struct drm_device *dev)
+static void intel_update_cdclk(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -5760,7 +5760,14 @@ static void vlv_update_cdclk(struct drm_device *dev)
* BSpec erroneously claims we should aim for 4MHz, but
* in fact 1MHz is the correct frequency.
*/
- I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq, 1000));
+ if (IS_VALLEYVIEW(dev)) {
+ /*
+* Program the gmbus_freq based on the cdclk frequency.
+* BSpec erroneously claims we should aim for 4MHz, but
+* in fact 1MHz is the correct frequency.
+*/
+ I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq,
1000));
+ }
}
/* Adjust CDclk dividers to allow high res or save power if possible */
@@ -5826,7 +5833,7 @@ static void valleyview_set_cdclk(struct drm_device *dev,
int cdclk)
mutex_unlock(&dev_priv->sb_lock);
- vlv_update_cdclk(dev);
+ intel_update_cdclk(dev);
}
static void cherryview_set_cdclk(struct drm_device *dev, int cdclk)
@@ -5867,7 +5874,7 @@ static void cherryview_set_cdclk(struct drm_device *dev,
int cdclk)
}
mutex_unlock(&dev_priv->rps.hw_lock);
- vlv_update_cdclk(dev);
+ intel_update_cdclk(dev);
}
static int valleyview_calc_cdclk(struct drm_i915_private *dev_priv,
@@ -6056,6 +6063,8 @@ static void valleyview_modeset_global_resources(struct
drm_atomic_state *old_sta
intel_display_power_put(dev_priv, POWER_DOMAIN_PIPE_A);
}
+
+ intel_update_cdclk(dev);
}
static void valleyview_crtc_enable(struct drm_crtc *crtc)
@@ -9479,6 +9488,7 @@ static void hsw_restore_lcpll(struct drm_i915_private
*dev_priv)
}
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ intel_update_cdclk(dev_priv->dev);
}
/*
@@ -13273,6 +13283,8 @@ static void intel_shared_dpll_init(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ intel_update_cdclk(dev);
+
if (HAS_DDI(dev))
intel_ddi_pll_init(dev);
else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev))
@@ -14848,13 +14860,9 @@ static void i915_disable_vga(struct drm_device *dev)
void intel_modeset_init_hw(struct drm_device *dev)
{
+ intel_update_cdclk(dev);
intel_prepare_ddi(dev);
-
- if (IS_VALLEYVIEW(dev))
- vlv_update_cdclk(dev);
-
intel_init_clock_gating(dev);
-
intel_enable_gt_powersave(dev);
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 8/8] drm/i915: HSW cdclk support
From: Ville Syrjälä
Implement support for changing the cdclk frequency during runtime on
HSW. VLV/CHV already have support for this, so we can follow their
example for the most part. Only the actual hardware programming differs,
the rest is pretty much the same.
The pipe pixel rate stuff is handled a bit differently for now due to
the difference in pch vs. gmch pfit handling. Eventually we should unify
that part to eliminate what is essentially duplicated code.
v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
Signed-off-by: Ville Syrjälä
v3: Rebased to the latest
v4: Reformatting 'haswell_modeset_global_pipes' function to
support atomic state
v5: Shuffling the patch order so the Broadwell CD clock patch
can be applied before this Haswell CD clock patch
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 137 ++-
2 files changed, 136 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0f72c0e..418d149 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6705,6 +6705,7 @@ enum skl_disp_power_wells {
#define GEN6_PCODE_READ_RC6VIDS 0x5
#define GEN6_ENCODE_RC6_VID(mv)(((mv) - 245) / 5)
#define GEN6_DECODE_RC6_VID(vids) (((vids) * 5) + 245)
+#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
#define BDW_PCODE_DISPLAY_FREQ_CHANGE_REQ0x18
#define GEN9_PCODE_READ_MEM_LATENCY 0x6
#define GEN9_MEM_LATENCY_LEVEL_MASK0xFF
@@ -7167,6 +7168,7 @@ enum skl_disp_power_wells {
#define LCPLL_PLL_LOCK(1<<30)
#define LCPLL_CLK_FREQ_MASK (3<<26)
#define LCPLL_CLK_FREQ_450(0<<26)
+#define LCPLL_CLK_FREQ_ALT_HSW(1<<26) /* 337.5 (ULX) or 540 */
#define LCPLL_CLK_FREQ_54O_BDW(1<<26)
#define LCPLL_CLK_FREQ_337_5_BDW (2<<26)
#define LCPLL_CLK_FREQ_675_BDW(3<<26)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3f50bb1..28c083e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5751,7 +5751,16 @@ static void intel_update_max_cdclk(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- if (IS_BROADWELL(dev)) {
+ if (IS_HASWELL(dev)) {
+ if (I915_READ(FUSE_STRAP) & HSW_CDCLK_LIMIT)
+ dev_priv->max_cdclk_freq = 45;
+ else if (IS_HSW_ULX(dev))
+ dev_priv->max_cdclk_freq = 337500;
+ else if (IS_HSW_ULT(dev))
+ dev_priv->max_cdclk_freq = 45;
+ else
+ dev_priv->max_cdclk_freq = 54;
+ } else if (IS_BROADWELL(dev)) {
/*
* FIXME with extra cooling we can allow
* 540 MHz for ULX and 675 Mhz for ULT.
@@ -9757,6 +9766,80 @@ static int broadwell_calc_cdclk(struct drm_i915_private
*dev_priv,
return cdclk;
}
+static void haswell_set_cdclk(struct drm_device *dev, int cdclk)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ uint32_t val;
+
+ if (WARN((I915_READ(LCPLL_CTL) &
+ (LCPLL_PLL_DISABLE | LCPLL_PLL_LOCK |
+ LCPLL_CD_CLOCK_DISABLE | LCPLL_ROOT_CD_CLOCK_DISABLE |
+ LCPLL_CD2X_CLOCK_DISABLE | LCPLL_POWER_DOWN_ALLOW |
+ LCPLL_CD_SOURCE_FCLK)) != LCPLL_PLL_LOCK,
+"trying to change cdclk frequency with cdclk not enabled\n"))
+ return;
+
+ val = I915_READ(LCPLL_CTL);
+ val &= ~LCPLL_CLK_FREQ_MASK;
+
+ switch (cdclk) {
+ case 45:
+ val |= LCPLL_CLK_FREQ_450;
+ break;
+ case 337500:
+ case 54:
+ val |= LCPLL_CLK_FREQ_ALT_HSW;
+ break;
+ default:
+ WARN(1, "invalid cdclk frequency\n");
+ return;
+ }
+
+ I915_WRITE(LCPLL_CTL, val);
+
+ if (IS_HSW_ULX(dev)) {
+ mutex_lock(&dev_priv->rps.hw_lock);
+ sandybridge_pcode_write(dev_priv, HSW_PCODE_DE_WRITE_FREQ_REQ,
+ cdclk == 337500);
+ mutex_unlock(&dev_priv->rps.hw_lock);
+ }
+
+ intel_update_cdclk(dev);
+
+ WARN(cdclk != dev_priv->cdclk_freq,
+"cdclk requested %d kHz but got %d kHz\n",
+cdclk, dev_priv->cdclk_freq);
+}
+
+static int haswell_calc_cdclk(struct drm_i915_private *dev_priv,
+ int max_pixel_rate)
+{
+ int cdclk;
+
+ /*
+* FIXME should also account for plane ratio
+* once 64bpp pixe
[Intel-gfx] [PATCH v5 2/8] drm/i915: Use cached cdclk value
From: Ville Syrjälä
Rather than reading out the current cdclk value use the cached value we
have tucked away in dev_priv.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
drivers/gpu/drm/i915/intel_dp.c | 5 +++--
drivers/gpu/drm/i915/intel_pm.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4dd00a5..3e29d8c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6612,8 +6612,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
/* FIXME should check pixel clock limits on all platforms */
if (INTEL_INFO(dev)->gen < 4) {
- int clock_limit =
- dev_priv->display.get_display_clock_speed(dev);
+ int clock_limit = dev_priv->cdclk_freq;
/*
* Enable pixel doubling when the dot clock
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6f525093..9a6517d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -708,7 +708,8 @@ static uint32_t ilk_get_aux_clock_divider(struct intel_dp
*intel_dp, int index)
return 0;
if (intel_dig_port->port == PORT_A) {
- return
DIV_ROUND_UP(dev_priv->display.get_display_clock_speed(dev), 2000);
+ return DIV_ROUND_UP(dev_priv->cdclk_freq, 2000);
+
} else {
return DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
}
@@ -723,7 +724,7 @@ static uint32_t hsw_get_aux_clock_divider(struct intel_dp
*intel_dp, int index)
if (intel_dig_port->port == PORT_A) {
if (index)
return 0;
- return
DIV_ROUND_CLOSEST(dev_priv->display.get_display_clock_speed(dev), 2000);
+ return DIV_ROUND_CLOSEST(dev_priv->cdclk_freq, 2000);
} else if (dev_priv->pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
/* Workaround for non-ULT HSW */
switch (index) {
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index eadc15c..5db429e 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1815,7 +1815,7 @@ hsw_compute_linetime_wm(struct drm_device *dev, struct
drm_crtc *crtc)
linetime = DIV_ROUND_CLOSEST(mode->crtc_htotal * 1000 * 8,
mode->crtc_clock);
ips_linetime = DIV_ROUND_CLOSEST(mode->crtc_htotal * 1000 * 8,
-
dev_priv->display.get_display_clock_speed(dev_priv->dev));
+dev_priv->cdclk_freq);
return PIPE_WM_LINETIME_IPS_LINETIME(ips_linetime) |
PIPE_WM_LINETIME_TIME(linetime);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 4/8] drm/i915: Store max cdclk value in dev_priv
From: Ville Syrjälä
Keep the cdclk maximum supported frequency around in dev_priv so that we
can verify certain things against it before actually changing the cdclk
frequency.
For now only VLV/CHV have support changing cdclk frequency, so other
plarforms get to assume cdclk is fixed.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 20 +++-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 60aa962..db9e268 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1743,7 +1743,7 @@ struct drm_i915_private {
unsigned int fsb_freq, mem_freq, is_ddr3;
unsigned int skl_boot_cdclk;
- unsigned int cdclk_freq;
+ unsigned int cdclk_freq, max_cdclk_freq;
unsigned int hpll_freq;
/**
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3e29d8c..dc4ea78 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5747,6 +5747,21 @@ static int valleyview_get_vco(struct drm_i915_private
*dev_priv)
return vco_freq[hpll_freq] * 1000;
}
+static void intel_update_max_cdclk(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ if (IS_VALLEYVIEW(dev)) {
+ dev_priv->max_cdclk_freq = 40;
+ } else {
+ /* otherwise assume cdclk is fixed */
+ dev_priv->max_cdclk_freq = dev_priv->cdclk_freq;
+ }
+
+ DRM_DEBUG_DRIVER("Max CD clock rate: %d kHz\n",
+dev_priv->max_cdclk_freq);
+}
+
static void intel_update_cdclk(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -5768,6 +5783,9 @@ static void intel_update_cdclk(struct drm_device *dev)
*/
I915_WRITE(GMBUSFREQ_VLV, DIV_ROUND_UP(dev_priv->cdclk_freq,
1000));
}
+
+ if (dev_priv->max_cdclk_freq == 0)
+ intel_update_max_cdclk(dev);
}
/* Adjust CDclk dividers to allow high res or save power if possible */
@@ -6612,7 +6630,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
/* FIXME should check pixel clock limits on all platforms */
if (INTEL_INFO(dev)->gen < 4) {
- int clock_limit = dev_priv->cdclk_freq;
+ int clock_limit = dev_priv->max_cdclk_freq;
/*
* Enable pixel doubling when the dot clock
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 6/8] drm/i915: Add IS_BDW_ULX
From: Ville Syrjälä
We need to tell BDW ULT and ULX apart.
Signed-off-by: Ville Syrjälä
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index db9e268..46722f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2399,6 +2399,9 @@ struct drm_i915_cmd_table {
((INTEL_DEVID(dev) & 0xf) == 0x6 ||\
(INTEL_DEVID(dev) & 0xf) == 0xb || \
(INTEL_DEVID(dev) & 0xf) == 0xe))
+/* ULX machines are also considered ULT. */
+#define IS_BDW_ULX(dev)(IS_BROADWELL(dev) && \
+(INTEL_DEVID(dev) & 0xf) == 0xe)
#define IS_BDW_GT3(dev)(IS_BROADWELL(dev) && \
(INTEL_DEVID(dev) & 0x00F0) == 0x0020)
#define IS_HSW_ULT(dev)(IS_HASWELL(dev) && \
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 5/8] drm/i915: Don't enable IPS when pixel rate exceeds 95%
From: Ville Syrjälä
Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
exceeds 95% of the core display clock. Apparently this can cause
underruns.
There's no similar restriction listed for HSW, so leave that one alone
for now.
v2: Add pipe_config_supports_ips() (Chris)
v3: Compare against the max cdclk insted of the current cdclk
Tested-by: Timo Aaltonen
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83497
Signed-off-by: Ville Syrjälä
v4: Rebased to the latest
v5: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 30 --
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 17 -
3 files changed, 37 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dc4ea78..961535e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6612,12 +6612,38 @@ retry:
return ret;
}
+static bool pipe_config_supports_ips(struct drm_i915_private *dev_priv,
+struct intel_crtc_state *pipe_config)
+{
+ if (pipe_config->pipe_bpp > 24)
+ return false;
+
+ /* HSW can handle pixel rate up to cdclk? */
+ if (IS_HASWELL(dev_priv->dev))
+ return true;
+
+ /*
+* FIXME if we compare against max we should then
+* increase the cdclk frequency when the current
+* value is too low. The other option is to compare
+* against the cdclk frequency we're going have post
+* modeset (ie. one we computed using other constraints).
+* Need to measure whether using a lower cdclk w/o IPS
+* is better or worse than a higher cdclk w/ IPS.
+*/
+ return ilk_pipe_pixel_rate(pipe_config) <=
+ dev_priv->max_cdclk_freq * 95 / 100;
+}
+
static void hsw_compute_ips_config(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config)
{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
pipe_config->ips_enabled = i915.enable_ips &&
- hsw_crtc_supports_ips(crtc) &&
- pipe_config->pipe_bpp <= 24;
+ hsw_crtc_supports_ips(crtc) &&
+ pipe_config_supports_ips(dev_priv, pipe_config);
}
static int intel_crtc_compute_config(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 2afb31a..5cb3004 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1375,7 +1375,7 @@ void ilk_wm_get_hw_state(struct drm_device *dev);
void skl_wm_get_hw_state(struct drm_device *dev);
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
struct skl_ddb_allocation *ddb /* out */);
-
+uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
/* intel_sdvo.c */
bool intel_sdvo_init(struct drm_device *dev, uint32_t sdvo_reg, bool is_sdvob);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 5db429e..d091fec 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1434,23 +1434,22 @@ static void i845_update_wm(struct drm_crtc *unused_crtc)
I915_WRITE(FW_BLC, fwater_lo);
}
-static uint32_t ilk_pipe_pixel_rate(struct drm_device *dev,
- struct drm_crtc *crtc)
+uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
uint32_t pixel_rate;
- pixel_rate = intel_crtc->config->base.adjusted_mode.crtc_clock;
+ pixel_rate = pipe_config->base.adjusted_mode.crtc_clock;
/* We only use IF-ID interlacing. If we ever use PF-ID we'll need to
* adjust the pixel_rate here. */
- if (intel_crtc->config->pch_pfit.enabled) {
+ if (pipe_config->pch_pfit.enabled) {
uint64_t pipe_w, pipe_h, pfit_w, pfit_h;
- uint32_t pfit_size = intel_crtc->config->pch_pfit.size;
+ uint32_t pfit_size = pipe_config->pch_pfit.size;
+
+ pipe_w = pipe_config->pipe_src_w;
+ pipe_h = pipe_config->pipe_src_h;
- pipe_w = intel_crtc->config->pipe_src_w;
- pipe_h = intel_crtc->config->pipe_src_h;
pfit_w = (pfit_size >> 16) & 0x;
pfit_h = pfit_size & 0x;
if (pipe_w < pfit_w)
@@ -2066,7 +2065,7 @@ static void ilk_compute_wm_parameters(struct drm_crtc
*crtc,
p->active = true;
p->pipe_htotal = intel_crtc->config->base.adjusted_mode.crtc_htotal;
- p->pixel_rate = ilk_pipe_pixel_rate(dev, crtc);
+ p->pixel_rate = ilk_pipe_p
Re: [Intel-gfx] [PATCH] drm/i915: Don't check modeset state in the hw state force restore path
On Mon, 01 Jun 2015, Ander Conselvan de Oliveira
wrote:
> Since the force restore logic will restore the CRTCs state one at a
> time, it is possible that the state will be inconsistent until the whole
> operation finishes. A call to intel_modeset_check_state() is done once
> it's over, so don't check the state multiple times in between. This
> regression was introduced in:
>
> commit 7f27126ea3db6ade886f18fd39caf0ff0cd1d37f
> Author: Jesse Barnes
> Date: Wed Nov 5 14:26:06 2014 -0800
>
> drm/i915: factor out compute_config from __intel_set_mode v3
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431
> Cc: Jesse Barnes
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
>
> Hi,
>
> This patch applies on top of nightly, but it is only relevant without
> Maarten's "drm/i915: Convert to atomic, part 2" series, because of the
> changes to the hw state read out and force restore logic.
>
> The regression exists since 3.19.
Sooo, I think this should be applied to fixes, with cc: stable v3.19+,
and IIUC Maarten's series makes this obsolete in dinq?
Now we just need review... Maarten?
BR,
Jani.
>
> ---
> drivers/gpu/drm/i915/intel_display.c | 21 -
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 16e159d..24fb7ce 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -87,7 +87,8 @@ static void ironlake_pch_clock_get(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config);
>
> static int intel_set_mode(struct drm_crtc *crtc,
> - struct drm_atomic_state *state);
> + struct drm_atomic_state *state,
> + bool check);
> static int intel_framebuffer_init(struct drm_device *dev,
> struct intel_framebuffer *ifb,
> struct drm_mode_fb_cmd2 *mode_cmd,
> @@ -10282,7 +10283,7 @@ retry:
>
> drm_mode_copy(&crtc_state->base.mode, mode);
>
> - if (intel_set_mode(crtc, state)) {
> + if (intel_set_mode(crtc, state, true)) {
> DRM_DEBUG_KMS("failed to set mode on load-detect pipe\n");
> if (old->release_fb)
> old->release_fb->funcs->destroy(old->release_fb);
> @@ -10356,7 +10357,7 @@ void intel_release_load_detect_pipe(struct
> drm_connector *connector,
> if (ret)
> goto fail;
>
> - ret = intel_set_mode(crtc, state);
> + ret = intel_set_mode(crtc, state, true);
> if (ret)
> goto fail;
>
> @@ -12832,20 +12833,22 @@ static int __intel_set_mode(struct drm_crtc
> *modeset_crtc,
> }
>
> static int intel_set_mode_with_config(struct drm_crtc *crtc,
> - struct intel_crtc_state *pipe_config)
> + struct intel_crtc_state *pipe_config,
> + bool check)
> {
> int ret;
>
> ret = __intel_set_mode(crtc, pipe_config);
>
> - if (ret == 0)
> + if (ret == 0 && check)
> intel_modeset_check_state(crtc->dev);
>
> return ret;
> }
>
> static int intel_set_mode(struct drm_crtc *crtc,
> - struct drm_atomic_state *state)
> + struct drm_atomic_state *state,
> + bool check)
> {
> struct intel_crtc_state *pipe_config;
> int ret = 0;
> @@ -12856,7 +12859,7 @@ static int intel_set_mode(struct drm_crtc *crtc,
> goto out;
> }
>
> - ret = intel_set_mode_with_config(crtc, pipe_config);
> + ret = intel_set_mode_with_config(crtc, pipe_config, check);
> if (ret)
> goto out;
>
> @@ -12933,7 +12936,7 @@ void intel_crtc_restore_mode(struct drm_crtc *crtc)
> intel_modeset_setup_plane_state(state, crtc, &crtc->mode,
> crtc->primary->fb, crtc->x, crtc->y);
>
> - ret = intel_set_mode(crtc, state);
> + ret = intel_set_mode(crtc, state, false);
> if (ret)
> drm_atomic_state_free(state);
> }
> @@ -13133,7 +13136,7 @@ static int intel_crtc_set_config(struct drm_mode_set
> *set)
>
> primary_plane_was_visible = primary_plane_visible(set->crtc);
>
> - ret = intel_set_mode_with_config(set->crtc, pipe_config);
> + ret = intel_set_mode_with_config(set->crtc, pipe_config, true);
>
> if (ret == 0 &&
> pipe_config->base.enable &&
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH v2] drm/atomic: Handle vblank events in atomic ioctl correctly.
All users of async updates seem to clear clear crtc_state->event
correctly, so move destroying vblank event to crtc_destroy_state.
This is better than manually free'ing it in the atomic ioctl, since
this code seems to do it wrong.
While we're at it handle -EDEADLK from atomic_commit correctly,
because the check might fail otherwise if it takes additional state.
Changes since v1:
- Fix freeing a NULL framebuffer, thanks for catching Daniel Stone.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Stone
---
drivers/gpu/drm/drm_atomic.c| 45 +
drivers/gpu/drm/drm_atomic_helper.c | 15 +
2 files changed, 26 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c7e59b074e62..8add0dd8dc5d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1328,17 +1328,6 @@ out:
return e;
}
-static void destroy_vblank_event(struct drm_device *dev,
- struct drm_file *file_priv, struct drm_pending_vblank_event *e)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&dev->event_lock, flags);
- file_priv->event_space += sizeof e->event;
- spin_unlock_irqrestore(&dev->event_lock, flags);
- kfree(e);
-}
-
static int atomic_set_prop(struct drm_atomic_state *state,
struct drm_mode_object *obj, struct drm_property *prop,
uint64_t prop_value)
@@ -1534,13 +1523,18 @@ retry:
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
ret = drm_atomic_check_only(state);
/* _check_only() does not free state, unlike _commit() */
- drm_atomic_state_free(state);
+ if (!ret)
+ drm_atomic_state_free(state);
} else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
ret = drm_atomic_async_commit(state);
} else {
ret = drm_atomic_commit(state);
}
+fail:
+ if (ret == -EDEADLK)
+ goto backoff;
+
/* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
* locks (ie. while it is still safe to deref plane->state). We
* need to do this here because the driver entry points cannot
@@ -1553,32 +1547,15 @@ retry:
drm_framebuffer_reference(new_fb);
plane->fb = new_fb;
plane->crtc = plane->state->crtc;
- } else {
- plane->old_fb = NULL;
- }
- if (plane->old_fb) {
- drm_framebuffer_unreference(plane->old_fb);
- plane->old_fb = NULL;
- }
- }
-
- drm_modeset_drop_locks(&ctx);
- drm_modeset_acquire_fini(&ctx);
-
- return ret;
-
-fail:
- if (ret == -EDEADLK)
- goto backoff;
- if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
- for_each_crtc_in_state(state, crtc, crtc_state, i) {
- destroy_vblank_event(dev, file_priv, crtc_state->event);
- crtc_state->event = NULL;
+ if (plane->old_fb)
+ drm_framebuffer_unreference(plane->old_fb);
}
+ plane->old_fb = NULL;
}
- drm_atomic_state_free(state);
+ if (ret)
+ drm_atomic_state_free(state);
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 536ae4da4665..0bb70c4da77a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2101,6 +2101,18 @@ drm_atomic_helper_crtc_duplicate_state(struct drm_crtc
*crtc)
}
EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
+static void destroy_vblank_event(struct drm_device *dev,
+ struct drm_pending_vblank_event *e)
+{
+ struct drm_file *file_priv = e->base.file_priv;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->event_lock, flags);
+ file_priv->event_space += sizeof e->event;
+ spin_unlock_irqrestore(&dev->event_lock, flags);
+ kfree(e);
+}
+
/**
* __drm_atomic_helper_crtc_destroy_state - release CRTC state
* @crtc: CRTC object
@@ -2115,6 +2127,9 @@ void __drm_atomic_helper_crtc_destroy_state(struct
drm_crtc *crtc,
{
if (state->mode_blob)
drm_property_unreference_blob(state->mode_blob);
+
+ if (state->event)
+ destroy_vblank_event(crtc->dev, state->event);
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
