ild out fbdev structs
v2: use BIOS connector config unconditionally if possible (Daniel)
check for crtc cloning and reject (Daniel)
fix up comments (Daniel)
v3: use command line args and preferred modes first (Ville)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |
This allows drivers to use them in custom initial_config functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c |6 --
include/drm/drm_fb_helper.h |6 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b
It can be corrected later and may be what was actually desired, but
generally isn't, so if we find nothing is enabled, let the core DRM fb
helper figure something out.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 24 ++--
1 file change
It can be corrected later and may be what was actually desired, but
generally isn't, so if we find nothing is enabled, let the core DRM fb
helper figure something out.
v2: free the array too (Jesse)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c |
On Wed, 12 Feb 2014 23:07:15 +
Chris Wilson wrote:
> On Wed, Feb 12, 2014 at 12:26:29PM -0800, Jesse Barnes wrote:
> > + /* Find the largest fb */
> > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> > + int
ddf68ab71aeed709dacd9cf65dc0f75
> Author: Jesse Barnes
> Date: Fri Feb 7 12:10:38 2014 -0800
>
> drm/i915: alloc intel_fb in the intel_fbdev struct
>
> Cc: Jesse Barnes
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 8 +---
> 1 fi
blt_control_type_bits;
> } __packed;
>
> /* LFP pointer table contains entries to the struct below */
> @@ -478,6 +493,20 @@ struct bdb_driver_features {
>
> u8 hdmi_termination;
> u8 custom_vbt_version;
> + /* Driver features data block */
> + u16 rm
"[0x%08x - 0x%08x]\n",
> > + base, base +
> > (uint32_t)dev_priv->gtt.stolen_size);
> > + base = 0;
> > + }
> > }
> >
> > return base;
It doesn't look like this was actually merged, and it belongs in -fixes
with a cc: stable since it affects existing machines with these BIOS
issues.
Cc'ing Jani so he can pick it up when he returns.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off. Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config.
Reported-by: Ville Syrjälä
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm
-
> /* WaForceL3Serialization:vlv */
> I915_WRITE(GEN7_L3SQCREG4, I915_READ(GEN7_L3SQCREG4) &
> ~L3SQ_URB_READ_CAM_MATCH_DISABLE);
I don't think we have good docs on this, but since it works empirically:
Acked-by: Jesse Barnes
--
Jesse Barnes, Intel Open
dev_priv, power_well);
> + for_each_power_well_rev(i, power_well, BIT(domain), power_domains) {
> + WARN_ON(!power_well->count);
> +
> + if (!--power_well->count && power_well->set &&
> + i915.disab
- intel_display_power_get(dev_priv, domain);
> - }
> -
> - list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head) {
> - enum intel_display_power_domain domain;
> -
> - for_each_power_domain(domain, crtc->enabled_power_domains)
> - intel_display_power_put(dev_priv, domain);
> -
> - crtc->enabled_power_domains = pipe_domains[crtc->pipe];
> - }
> -
> - intel_display_set_init_power(dev_priv, false);
> -}
> -
> static void haswell_modeset_global_resources(struct drm_device *dev)
> {
> modeset_update_power_wells(dev);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_domains_resume(struct drm_i915_private *dev_priv)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> struct i915_power_domains *power_domains = &dev_priv->power_domains;
> struct i915_power_well *power_well;
> int i;
> @@ -5486,7 +5473,7 @@ static void intel_power_domains_resume(struct
> drm_device *dev)
> mutex_lock(&power_domains->lock);
> for_each_power_well(i, power_well, POWER_DOMAIN_MASK, power_domains) {
> if (power_well->set)
> - power_well->set(dev, power_well, power_well->count > 0);
> + power_well->set(dev_priv, power_well, power_well->count
> > 0);
> }
> mutex_unlock(&power_domains->lock);
> }
> @@ -5497,15 +5484,13 @@ static void intel_power_domains_resume(struct
> drm_device *dev)
> * to be enabled, and it will only be disabled if none of the registers is
> * requesting it to be enabled.
> */
> -void intel_power_domains_init_hw(struct drm_device *dev)
> +void intel_power_domains_init_hw(struct drm_i915_private *dev_priv)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> /* For now, we need the power well to be always enabled. */
> - intel_display_set_init_power(dev, true);
> - intel_power_domains_resume(dev);
> + intel_display_set_init_power(dev_priv, true);
> + intel_power_domains_resume(dev_priv);
>
> - if (!(IS_HASWELL(dev) || IS_BROADWELL(dev)))
> + if (!(IS_HASWELL(dev_priv->dev) || IS_BROADWELL(dev_priv->dev)))
> return;
>
> /* We're taking over the BIOS, so clear any requests made by it since
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
31,7 @@ static struct i915_power_well bdw_power_wells[] = {
> },
> {
> .name = "display",
> - .domains = POWER_DOMAIN_MASK & ~BDW_ALWAYS_ON_POWER_DOMAINS,
> + .domains = BDW_DISPLAY_POWER_DOMAINS,
> .is_enabled = hsw_power_well_enabled,
> .set = hsw_set_power_well,
> },
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
rivers/gpu/drm/i915/intel_pm.c
> @@ -5412,6 +5412,15 @@ EXPORT_SYMBOL_GPL(i915_release_power_well);
> #define HSW_ALWAYS_ON_POWER_DOMAINS (\
> BIT(POWER_DOMAIN_PIPE_A) | \
> BIT(POWER_DOMAIN_TRANSCODER_EDP) | \
> + BIT(PO
14 +5528,6 @@ void intel_power_domains_init_hw(struct
> drm_i915_private *dev_priv)
> /* For now, we need the power well to be always enabled. */
> intel_display_set_init_power(dev_priv, true);
> intel_power_domains_resume(dev_priv);
> -
> - if (!(IS_HASWELL
@ static struct i915_power_well hsw_power_wells[] = {
> static struct i915_power_well bdw_power_wells[] = {
> {
> .name = "always-on",
> - .always_on = 1,
> .domains = BDW_ALWAYS_ON_POWER_DOMAINS,
>
isplay_port_power_domain(struct intel_encoder
> *intel_encoder);
> int valleyview_get_vco(struct drm_i915_private *dev_priv);
> void intel_mode_from_pipe_config(struct drm_display_mode *mode,
>struct intel_crtc_config *pipe_config);
> +bool intel_enco
crtc->active = intel_display_get_pipe_config(crtc,
> + &crtc->config);
>
> crtc->base.enabled = crtc->active;
> crtc->primary_enabled = crtc->active;
Same comment
form specific power check for each block to
do some basic sanity checking on whether the appropriate well was
enabled and squak if not.
I just know we'll miss this more than once, and I'm not sure if the
unclaimed reg stuff will save us on all platforms.
--
Jesse Barnes, Intel Open Sourc
vlv_punit_write(dev_priv, PUNIT_REG_PWRGT_CTRL, 0x0);
>
> mutex_unlock(&dev_priv->rps.hw_lock);
I'd like to see a doc reference here, as I never remember which one has
these bits... Also, are you sure about the RX bits? The
PUNIT_HAS_0.8 doc says only subsystems 10-11 cover RX, maybe in a ganged
config?
Otherwise:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
return;
>
> - if (!(I915_READ(vga_reg) & VGA_DISP_DISABLE)) {
> - DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n");
> - i915_disable_vga(dev);
> - }
> + i915_redisable_vga_power_on(dev);
> }
>
> static void intel_
ng it to be enabled.
> - */
> void intel_power_domains_init_hw(struct drm_i915_private *dev_priv)
> {
> /* For now, we need the power well to be always enabled. */
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
cleanup_gem_stolen;
>
> - intel_power_domains_init_hw(dev_priv);
> -
> /* Important: The output setup functions called by modeset_init need
>* working irqs for e.g. gmbus and dp aux transfers. */
> intel_modeset_init(dev);
Reviewed-by: Jesse Barne
drm_device
> *dev)
> I915_WRITE(HWSTAM, 0x);
> I915_WRITE(PORT_HOTPLUG_EN, 0);
> I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
> - for_each_pipe(pipe)
> - I915_WRITE(PIPESTAT(pipe), 0x);
> +
> + if (dev_priv-&
gt; + if (wait_for(COND, 100))
> > + DRM_ERROR("timout setting power well state %08x (%08x)\n",
> > + state,
> > + vlv_punit_read(dev_priv, PUNIT_REG_PWRGT_CTRL));
>
> #undef COND somewhere to avoid suprises further down in the code?
>
> > +
> > +out:
> > + mutex_unlock(&dev_priv->rps.hw_lock);
> > +}
> > +
>
>
I'd like to see the code for re-enabling the display state land
eventually too, so we can get savings when userspace uses DPMS instead
of NULL mode sets for things. But to do that nicely requires some more
work in the mode set code to pull out more PLL bits (also needed for
atomic mode setting).
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ed-by: Ville Syrjälä
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 7693728..5935544 100644
--- a/drivers/gpu/drm/i915/intel_fb
Useful for bug reports.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b737583..1cb56f7 100644
--- a/drivers/gpu/drm/i915
ly cool registers */
Do we need this for the VLV path too?
It's a little confusing that we do this delayed thing, incrementing the
count and then decrementing again in the work queue, but what you have
looks correct for both cases.
So with the VLV thing addressed:
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
rtc_list, head) {
> if (!crtc->fb)
> @@ -8224,6 +8222,9 @@ void intel_mark_idle(struct drm_device *dev)
>
> if (INTEL_INFO(dev)->gen >= 6)
> gen6_rps_idle(dev->dev_private);
> +
> +out:
> + hsw_package_c8_gpu_idle(dev_priv);
, x, y, fb);
>
> if (ret == 0)
> intel_modeset_check_state(crtc->dev);
>
> + intel_runtime_pm_put(dev_priv);
> return ret;
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
atus;
> + if (!force) {
> + status = connector->status;
> + goto out;
> + }
>
> /* for pre-945g platforms use load detect */
> if (intel_get_load_detect_pipe(connector, NULL, &tmp)) {
> @@ -673,6 +683,8 @@ intel_crt_detect(s
_pm_get(dev_priv);
> +
> rdmsrl(MSR_RAPL_POWER_UNIT, power);
> power = (power & 0x1f00) >> 8;
> units = 100 / (1 << power); /* convert to uJ */
> power = I915_READ(MCH_SECP_NRG_STTS);
> power *= units;
>
> + intel_runtim
display
> > power gating is
> > enabled. I will try to include a test to cover this test
>
> Hm, which exact interrupt routing are you referring to? At least on my
> BYT I manage to power off only the display power well and keep the
> render well on, while still being ab
On Fri, 21 Feb 2014 17:08:50 -0300
Paulo Zanoni wrote:
> 2014-02-21 14:34 GMT-03:00 Jesse Barnes :
> > On Fri, 21 Feb 2014 13:52:20 -0300
> > Paulo Zanoni wrote:
> >
> >> From: Paulo Zanoni
> >>
> >> When we call gen6_gt_force_wake_put we don&
To silence locking complaints. This was a rebase failure on my part in
commit fa9fa083d0606cb323f6105c17702460ea0a6780
Author: Jesse Barnes
Date: Tue Feb 11 15:28:56 2014 -0800
drm/i915: read out hw state earlier v2
Reported-by: Ville Syrjälä
Signed-off-by: Jesse Barnes
---
drivers
.13 and 3.14-rc1 didn't prove fruitful,
> >either because I messed it up or there's a combination of things that
> >fix the issue. So instead I did a regular git bisect between 3.12 and
> >3.13 to see which commit _broke_ things and caused the above behavior.
> >
len Memory");
> + if (r == NULL) {
> + DRM_ERROR("conflict detected with stolen region:"\
> + "[0x%08x - 0x%08x]\n",
> + base, base +
> (uint32_t)dev_priv->gtt.stolen
906,7 +906,7 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
> drm_update_vblank_count(dev, crtc);
> }
> }
> - spin_unlock_irqrestore(&dev->vblank_time_lock, irqflags2);
> + spin_unlock(&dev->vblank_time_lock);
> } e
/* for wraparound handling */
> u32 last_wait; /* Last vblank seqno waited per CRTC */
> unsigned int inmodeset; /* Display driver is setting mode */
> + int crtc; /* crtc index */
> bool enabled;
bool vblank_always_enable_on_get;
> +
> /* array of size num_crtcs */
> struct drm_vblank_crtc *vblank;
>
This seems like the sort of thing it would be good to have a test
for... I'm surprised we haven't hit it yet. But in l
c'ing Mario for another opinion too. This makes me nervous but it
seems ok.
I think you should update the docbook (with examples) as well so other
driver writers will know how to use this stuff.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
/* crtc index */
> bool enabled; /* so we don't call enable more than
> once per disable */
> + bool reject;/* reject drm_vblank_get()? */
> };
>
> /**
> @@ -1400,7 +1401,8 @@
On Wed, 26 Feb 2014 20:02:19 +0200
Imre Deak wrote:
> On Thu, 2014-02-20 at 11:58 -0800, Jesse Barnes wrote:
> > On Wed, 19 Feb 2014 14:29:44 +0200
> > Ville Syrjälä wrote:
> >
> > > On Tue, Feb 18, 2014 at 12:02:20AM +0200, Imre Deak wrote:
> > &g
;
> dev_priv->mm.busy = true;
> }
> @@ -8131,7 +8131,7 @@ void intel_mark_idle(struct drm_device *dev)
> gen6_rps_idle(dev->dev_private);
>
> out:
> - hsw_enable_package_c8(dev_priv);
> + intel_runtime_pm_put(dev_priv);
> }
>
> void i
,7 +6716,7 @@ void hsw_disable_package_c8(struct drm_i915_private
> *dev_priv)
> return;
>
> mutex_lock(&dev_priv->pc8.lock);
> - __hsw_disable_package_c8(dev_priv);
> + intel_runtime_pm_get(dev_priv);
> mutex_unlock(&dev_priv->pc8
/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5793,7 +5793,6 @@ void intel_pm_setup(struct drm_device *dev)
> mutex_init(&dev_priv->pc8.lock);
> dev_priv->pc8.irqs_disabled = false;
> dev_priv->pc8.enabled = false;
> - dev_priv->pc8.
aux_display_runtime_get(struct drm_i915_private *dev_priv)
> -{
> - hsw_disable_package_c8(dev_priv);
> -}
> -
> -void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv)
> -{
> - hsw_enable_package_c8(dev_priv);
> -}
> -
> void intel_runtime_pm_get
R_WELL_DRIVER);
> is_enabled = tmp & HSW_PWR_WELL_STATE_ENABLED;
> enable_requested = tmp & HSW_PWR_WELL_ENABLE_REQUEST;
> @@ -5773,7 +5771,6 @@ void intel_pm_setup(struct drm_device *dev)
>
> mutex_init(&dev_priv->pc8.lock);
>
index 5ff4b59..3bd6e8f 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5769,7 +5769,6 @@ void intel_pm_setup(struct drm_device *dev)
>
> mutex_init(&dev_priv->rps.hw_lock);
>
> - mutex_init(&dev_priv->
_gt_irq(struct drm_i915_private *dev_priv, uint32_t mask);
> void snb_enable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask);
> void snb_disable_pm_irq(struct drm_i915_private *dev_priv, uint32_t mask);
> -void hsw_pc8_disable_interrupts(struct drm_device *dev);
> -void hsw_pc8_restore_interrupts(struct drm_device *dev);
> +void hsw_runtime_pm_disable_interrupts(struct drm_device *dev);
> +void hsw_runtime_pm_restore_interrupts(struct drm_device *dev);
>
>
> /* intel_crt.c */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index c85507a..5ff4b59 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5770,7 +5770,8 @@ void intel_pm_setup(struct drm_device *dev)
> mutex_init(&dev_priv->rps.hw_lock);
>
> mutex_init(&dev_priv->pc8.lock);
> - dev_priv->pc8.irqs_disabled = false;
> INIT_DELAYED_WORK(&dev_priv->rps.delayed_resume_work,
> intel_gen6_powersave_work);
> +
> + dev_priv->pm.irqs_disabled = false;
> }
I wonder if we should eventually not bother with saving/restoring the
interrupt state and do a full re-init like we'll have to in the display
power well case. But that's a separate issue really...
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
iv);
> +void hsw_enable_pc8(struct drm_i915_private *dev_priv);
> +void hsw_disable_pc8(struct drm_i915_private *dev_priv);
> void intel_dp_get_m_n(struct intel_crtc *crtc,
> struct intel_crtc_config *pipe_config);
> int intel_dotclock_calculate(int link_freq, con
gt; - hsw_enable_package_c8(dev_priv);
> -
> mutex_lock(&dev_priv->modeset_restore_lock);
> dev_priv->modeset_restore = MODESET_DONE;
> mutex_unlock(&dev_priv->modeset_restore_lock);
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source
l_init_runtime_pm),
> but
> + * it can be changed with the standard runtime PM files frmo sysfs.
typo "from"
Otherwise, Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
ut(struct drm_device *dev,
> struct i915_power_well *power_well)
> {
> - struct drm_i915_private *dev_priv = dev->dev_private;
> -
> WARN_ON(!power_well->count);
>
> if (!--power_well->count && power_well->set &&
> -
K(&dev_priv->rps.delayed_resume_work,
> intel_gen6_powersave_work);
>
> + dev_priv->pm.suspended = false;
> dev_priv->pm.irqs_disabled = false;
> }
Reviewed-by: Jesse Barnes
Though my earlier comments about getting rid of the init special case
sti
On Fri, 28 Feb 2014 19:38:17 +0200
Imre Deak wrote:
> On Fri, 2014-02-28 at 09:13 -0800, Jesse Barnes wrote:
> > On Thu, 27 Feb 2014 19:26:43 -0300
> > Paulo Zanoni wrote:
> >
> > > From: Paulo Zanoni
> > >
> > > We had these intel_aux_display
This reverts
>
> commit 2514bc510d0c3aadcc5204056bb440fa36845147
> Author: Jesse Barnes
> Date: Thu Jun 21 15:13:50 2012 -0700
>
> drm/i915: prefer wide & slow to fast & narrow in DP configs
>
> I'm pretty sure I'll regret this patch, but otoh I expect
On Thu, 27 Feb 2014 11:01:08 +0200
Jani Nikula wrote:
> On Thu, 27 Feb 2014, Jani Nikula wrote:
> > On Wed, 26 Feb 2014, Jesse Barnes wrote:
> >> On Mon, 13 Jan 2014 16:25:21 +0530
> >> akash.g...@intel.com wrote:
> >>
> >>> From: Akash
So don't try to allocate and program it, we're only fooling ourselves.
Reported-by: "Chang, Junxiao"
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i
On Mon, 3 Mar 2014 11:14:09 -0800
Jesse Barnes wrote:
> On Thu, 27 Feb 2014 11:01:08 +0200
> Jani Nikula wrote:
>
> > On Thu, 27 Feb 2014, Jani Nikula wrote:
> > > On Wed, 26 Feb 2014, Jesse Barnes wrote:
> > >> On Mon, 13 Jan 2014 16:25:21 +05
On Fri, 7 Feb 2014 18:37:01 -0200
Rodrigo Vivi wrote:
> From: Jesse Barnes
>
> The intent is to get back to userspace as quickly as possible so it can
> start doing drawing or whatever. It should also allow our
> suspend/resume/init time to improve a lot.
>
> Signed
tel_crtc(crtc)->unpin_work != NULL;
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> -
> - return pending;
> -}
> -
> bool intel_has_pending_fb_unpin(struct drm_device *dev)
> {
> struct intel_crtc *crtc;
Looks fine, my only comment is do we
On Tue, 4 Mar 2014 21:08:41 +0100
Daniel Vetter wrote:
> It started as a simple check whether anything is lit up, but now is't
> used to driver the general fallback logic to the default output
> configuration selector in the helper library. So rename it for more
> clarity.
>
(it even has hotplug handling and all that) fall back if more
> outputs could have been enabled.
>
> v2: Fix up my confusion about what enabled means - it's passed from
> the fbdev helper, we need to check for a non-zero connector->encoder
> link. Spotted by Ville.
>
&
On Wed, 5 Mar 2014 13:55:00 +0100
Daniel Vetter wrote:
> On Thu, Feb 20, 2014 at 08:50:59PM +, Chris Wilson wrote:
> > On Thu, Feb 20, 2014 at 12:39:57PM -0800, Jesse Barnes wrote:
> > > Useful for bug reports.
> >
> > Hey, this would be useful for error state
On Tue, 4 Mar 2014 22:08:12 +0100
Daniel Vetter wrote:
> On Tue, Mar 04, 2014 at 12:33:01PM -0800, Jesse Barnes wrote:
> > On Tue, 4 Mar 2014 21:08:42 +0100
> > Daniel Vetter wrote:
> >
> > > Both Ville and QA rather immediately complained that with the new
&
On Wed, 5 Mar 2014 19:34:45 +0100
Daniel Vetter wrote:
> On Wed, Mar 05, 2014 at 08:27:08AM -0800, Jesse Barnes wrote:
> > On Tue, 4 Mar 2014 22:08:12 +0100
> > Daniel Vetter wrote:
> >
> > > On Tue, Mar 04, 2014 at 12:33:01PM -0800, Jesse Barnes wrote:
> &
Drivers ought to complain otherwise.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_fb_helper.c | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 4
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm
It takes awhile to fetch the DPCD and EDID for caching, so take it out
of the critical path to improve init time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 113 +---
1 file changed, 82 insertions(+), 31 deletions(-)
diff --git a
This lets us return to userspace more quickly and should improve init
and suspend/resume times as well, allowing us to return to userspace
sooner.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915
In the hotplug case, nothing was grabbing VDD, leading to some warnings.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 763f235..78c883e 100644
--- a
I'm worried about the locking in this... I've also commented out the
state checker, but that can be re-added as a check after any queued CRTC
changes as another queued item, so should be easy to fix.
This set drastically improves the init time of the i915 module (based on
initcall_debug timing),
This gets us out of our init code and out to userspace quite a bit
faster, but does open us up to some bugs given the state of our init
time locking.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_dma.c| 3 ++-
drivers/gpu/drm/i915/i915_drv.h| 1 +
drivers/gpu/drm/i915
Reduces params in a few places and makes workqueueing the eDP caching work
easier.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c | 23 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu
On Thu, 06 Mar 2014 01:29:14 +0200
Imre Deak wrote:
> On Wed, 2014-03-05 at 14:48 -0800, Jesse Barnes wrote:
> > This lets us return to userspace more quickly and should improve init
> > and suspend/resume times as well, allowing us to return to userspace
> > sooner.
>
On Thu, 6 Mar 2014 09:35:23 +
Chris Wilson wrote:
> On Wed, Mar 05, 2014 at 02:48:26PM -0800, Jesse Barnes wrote:
> > @@ -7554,6 +7610,8 @@ static int intel_crtc_cursor_set(struct drm_crtc
> > *crtc,
> > goto fail;
> > }
> &g
On Thu, 6 Mar 2014 09:12:40 +
Chris Wilson wrote:
> On Wed, Mar 05, 2014 at 02:48:27PM -0800, Jesse Barnes wrote:
> > This gets us out of our init code and out to userspace quite a bit
> > faster, but does open us up to some bugs given the state of our init
> > time loc
On Thu, 6 Mar 2014 11:28:13 +0200
Ville Syrjälä wrote:
> On Wed, Mar 05, 2014 at 02:48:30PM -0800, Jesse Barnes wrote:
> > It takes awhile to fetch the DPCD and EDID for caching, so take it out
> > of the critical path to improve init time.
> >
> >
No special reason. It shouldn't matter on BYT either, really, since
pipe A doesn't have special characteristics like it does on HSW.
Jesse
On Thu, 6 Mar 2014 17:19:22 +0800
"Lin, Mengdong" wrote:
> Hi Jesse,
>
>
>
> Could you tell us why Baytrail Gfx driver does not always use pipe A when
gs and/or tasks filed for all these, or just the one? We
need to make sure people are signed up to fix/review them, or it'll end
up staying disabled forever, and then we'll be stuck without a command
checker and some advanced features coming up...
--
Jesse Barnes, Intel Open Source Techn
> Signed-off-by: Imre Deak
> Reviewed-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/i915_dma.c | 14
> drivers/gpu/drm/i915/i915_drv.c | 4 +--
> drivers/gpu/drm/i915/i915_drv.h | 4 +--
> drivers/gpu/drm/i915/intel_display.c | 27 +++
&g
.is_enabled = hsw_power_well_enabled,
> .set = hsw_set_power_well,
> },
> @@ -5414,7 +5430,7 @@ static struct i915_power_well bdw_power_wells[] = {
> },
> {
> .name = "display",
> - .domains = POW
BIT(POWER_DOMAIN_PIPE_A) | \
> - BIT(POWER_DOMAIN_TRANSCODER_EDP))
> + BIT(POWER_DOMAIN_TRANSCODER_EDP) | \
> + BIT(POWER_DOMAIN_INIT))
> #define HSW_DISPLAY_POWER_DOMAINS ( \
> (POWER_DOMAIN_MASK & ~HSW_ALWAYS_ON_POWER_D
> - if (power_well->ops->sync_hw)
> - power_well->ops->sync_hw(dev_priv, power_well);
> - }
> + for_each_power_well(i, power_well, POWER_DOMAIN_MASK, power_domains)
> + power_well->ops->sync_hw(dev_priv, power_well);
> mutex_unlock(&power_domains->lock);
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
gt;pipe)))
> + return false;
> +
> pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> pipe_config->shared_dpll = DPLL_ID_PRIVATE;
>
Same goes here, though I suppose there's more room for additional,
specific domains down at this l
e.
> - */
> - dev_priv->irq_mask = (~enable_mask) |
> - I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT |
> - I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT;
> + dev_priv->irq_mask = ~enable_mask;
>
> I915_WRITE(PORT_HOTPLUG_EN, 0);
> POSTING_READ(PORT_HOTPLUG_EN);
Reviewed-by: Jesse
each_pipe(pipe)
> + if (pipe != PIPE_A)
> + reset_vblank_counter(dev, pipe);
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
->count);
>
> - if (!--power_well->count && i915.disable_power_well)
> + if (!--power_well->count && i915.disable_power_well) {
> + DRM_DEBUG_KMS("disabling %s\n", power_well->name);
> po
ret;
> }
>
> static bool
> intel_hdmi_detect_audio(struct drm_connector *connector)
> {
> - struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> + struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&intel_encoder->base);
> struct drm_i915_private *dev_priv = connector->dev->dev_private;
> + enum intel_display_power_domain power_domain;
> struct edid *edid;
> bool has_audio = false;
>
> + power_domain = intel_display_port_power_domain(intel_encoder);
> + intel_display_power_get(dev_priv, power_domain);
> +
> edid = drm_get_edid(connector,
> intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus));
> @@ -975,6 +996,8 @@ intel_hdmi_detect_audio(struct drm_connector *connector)
> kfree(edid);
> }
>
> + intel_display_power_put(dev_priv, power_domain);
> +
> return has_audio;
> }
>
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
enc_to_intel_hdmi(&encoder->base);
> + enum intel_display_power_domain power_domain;
> u32 tmp;
>
> + power_domain = intel_display_port_power_domain(encoder);
> + if (!intel_display_power_enabled(dev_priv, power_domain))
> + return false;
&g
dev_priv->display_irqs_enabled = true;
> +
> + if (dev_priv->dev->irq_enabled)
> + valleyview_display_irqs_install(dev_priv);
> +}
This made me do a double take, then I saw you were checking the actual
drm_device irq enabled state rather than checking the new
ng it to be enabled.
> - */
> void intel_power_domains_init_hw(struct drm_i915_private *dev_priv)
> {
> /* For now, we need the power well to be always enabled. */
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
= intel_set_cpu_fifo_underrun_reporting_nolock(dev, pipe, enable);
> spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
> +
> return ret;
> }
>
Funky how diff left the spin_unlock line alone. :)
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
VLV_DPIO_TX_C_LANES_01_POWER_DOMAINS |
> +VLV_DPIO_TX_C_LANES_23_POWER_DOMAINS,
> + .ops = &vlv_dpio_power_well_ops,
> + .data = PUNIT_POWER_WELL_DPIO_TX_C_LANES_01,
> + },
> + {
> + .name = "dpio-tx-c-23",
> +
t; 16) | crtc_x);
>
> @@ -492,6 +612,9 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc
> *crtc,
> I915_WRITE(DVSSURF(pipe),
> i915_gem_obj_ggtt_offset(obj) + dvssurf_offset);
> POSTING_READ(DVSSURF(pipe));
> +
> + if (atomic_update)
> + intel_pipe_update_end(intel_crtc, start_vbl_count);
> }
>
> static void
> @@ -500,7 +623,12 @@ ilk_disable_plane(struct drm_plane *plane, struct
> drm_crtc *crtc)
> struct drm_device *dev = plane->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> int pipe = intel_plane->pipe;
> + u32 start_vbl_count;
> + bool atomic_update;
> +
> + atomic_update = intel_pipe_update_start(intel_crtc, &start_vbl_count);
>
> I915_WRITE(DVSCNTR(pipe), I915_READ(DVSCNTR(pipe)) & ~DVS_ENABLE);
> /* Disable the scaler */
> @@ -509,6 +637,9 @@ ilk_disable_plane(struct drm_plane *plane, struct
> drm_crtc *crtc)
> I915_WRITE(DVSSURF(pipe), 0);
> POSTING_READ(DVSSURF(pipe));
>
> + if (atomic_update)
> + intel_pipe_update_end(intel_crtc, start_vbl_count);
> +
> /*
>* Avoid underruns when disabling the sprite.
>* FIXME remove once watermark updates are done properly.
Yeah looks like this will work ok.
I don't understand the prepare_to_wait() comment, since we're both
holding the crtc mutex and prepare_to_wait() will take the crtc
vbl_wait queue lock, but since things look safe as-is I guess it's not
a big deal.
Reviewed-by: Jesse Barnes
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Early at init time, we can try to read out the plane config structure
and try to preserve it if possible.
v2: alloc fb obj at init time after fetching plane config
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/intel_display.c | 92
This should allow BIOS fb inheritance to work on ILK+ machines too.
v2: handle tiled BIOS fbs (Kristian)
split out common bits (Jesse)
v3: alloc fb obj out in _init
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 62
1 file
As of IVB, the memory controller does internal swizzling already, so we
shouldn't need to enable these. Based on an earlier fix from Kristian.
Reported-by: Kristian Høgsberg
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_gem.c| 7 +++
drivers/gpu/drm
n error (Daniel)
take fbdev fb ref and remove unused error path (Daniel)
Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 145 ---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_
401 - 500 of 3350 matches
Mail list logo
