nter_do_call+0x12/0x28
> [ 161.003505] Code: 0f b6 4d f3 8d 51 0f 83 e1 f0 83 e2 0f 09 d1 84 d2 88 48
> 54 75 07 80 a7 91 00 00 00 7f 83 c4 04 5b 5e 5f 5d c3 8d b6 00 00 00 00 <0f>
> 0b 8d b6 00 00 00 00 55 89 e5 57 56 53 83 ec 64 3e 8d 74 26
> [ 161.003586] EIP: [] i915_gem_o
Forgot to convert to using the refclk variable when I added refclk
readout support, and Paulo noticed the resulting calculation was off due
to the way p & r are stored.
Reported-by: Paulo Zanoni
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
1 file change
(p * r);
> }
>
> static void intel_ddi_clock_get(struct intel_encoder *encoder,
Yep, looks like units fail. And I failed to replace LC_FREQ with
refclk when I added the WRPLL refclk fetching... I'll post an updated
patch with both fixed.
Thanks,
--
Jesse Barnes, Intel Open Source T
On Wed, 22 Jan 2014 22:07:53 +0530
"S, Deepak" wrote:
>
>
> On 1/22/2014 10:04 PM, Jesse Barnes wrote:
> > On Tue, 21 Jan 2014 17:18:59 +0200
> > Ville Syrjälä wrote:
> >
> >> On Mon, Jan 20, 2014 at 06:40:26PM +0530, deepa...@intel.com wro
st code makes sense, so you'd have to port those
changes from the gen6_pm_rps_work() from Chris and measure again...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Just like we have for connector type etc.
v2: just return the string directly to avoid repeating the mistakes of
the past (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 16
include/drm/drm_crtc.h | 1 +
2 files changed, 17 insertions(+)
diff
On Tue, 21 Jan 2014 09:05:04 +
Chris Wilson wrote:
> On Mon, Jan 20, 2014 at 03:54:59PM -0800, Jesse Barnes wrote:
> > Just like we have for connector type etc.
>
> Then we might as well take a similar defensive approach if we want to
> expand the number of contexts we ca
additional SPLL freqs (Ville)
clean up port/crtc clock calc (Ville)
fix up crtc_clock conditionals (Ville)
drop superfluous dp_get_m_n from get_config (Ville)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h | 10 +
drivers/gpu/drm/i915/intel_ddi.c | 92
&pipe_config->dp_m_n);
>
> else
> .crtc_clock = link_clock; // or port_clock if you take my suggestion
> above
Fixed.
> > + intel_cpu_transcoder_get_m_n(crtc, pipe_config->cpu_transcoder,
> > +
Can be expanded up on to include all sorts of things (HDMI infoframe
data, more DP status, etc). Should be useful for bug reports to get a
baseline on the display config and info.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c | 155
Just like we have for connector type etc.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 20
include/drm/drm_crtc.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 266a01d..3982dd9
Read out and calculate the port and pixel clocks on DDI configs as well.
This means we have to grab the DP divider values and look at the port
mapping to figure out which clock select reg to read out.
v2: do the work from ddi_get_config (Ville)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm
Now that we have DDI support, we can check these all the time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
On Sat, 18 Jan 2014 16:01:06 +0200
Ville Syrjälä wrote:
> On Fri, Jan 17, 2014 at 01:16:56PM -0800, Jesse Barnes wrote:
> > In DDI configs, we need to get the encoder to CRTC mapping early on so
> > we can read out and calculate the clock state correctly, as it depends
In DDI configs, we need to get the encoder to CRTC mapping early on so
we can read out and calculate the clock state correctly, as it depends
on the port.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 59 +++-
1 file changed, 44
Read out and calculate the port and pixel clocks on DDI configs as well.
This means we have to grab the DP divider values and look at the port
mapping to figure out which clock select reg to read out.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_reg.h | 6
drivers/gpu
Now that we have DDI support, we can check these all the time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
/* The fixup needs to happen before cursor is enabled */
Looks fine, though I echo Jani's comment. Might be better to have an
explicitly named intel_enable_pipe_wait variant to make the code more
readable (likewise for DSI and PCH probably, if we don't need every
combination), but that can be a separate cleanup.
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
false);
>
> if (intel_crtc->config.has_pch_encoder)
> lpt_pch_enable(crtc);
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
vblank before returning to avoid strange things
> - * happening.
> - */
> - intel_wait_for_vblank(dev, intel_crtc->pipe);
> }
>
> static void ironlake_pfit_disable(struct intel_crtc *crtc)
Yeah, really seems like this is taken care of by the earlier bits...
Re
et_vco(struct drm_i915_private *dev_priv);
> +void intel_encoder_resume(struct drm_device *dev);
>
> /* intel_dp.c */
> void intel_dp_init(struct drm_device *dev, int output_reg, enum port port);
> @@ -734,6 +736,7 @@ void ironlake_edp_panel_vdd_off(struct intel_dp
> *in
On Tue, 14 Jan 2014 15:06:46 -0800
Kristen Carlson Accardi wrote:
> On Tue, 14 Jan 2014 11:19:44 -0800
> Jesse Barnes wrote:
>
> > On Tue, 14 Jan 2014 10:26:02 +0100
> > Daniel Vetter wrote:
> >
> > > On Mon, Jan 13, 2014 at 01:32:45PM -0800, Kriste
On Mon, 13 Jan 2014 17:55:27 -0200
Paulo Zanoni wrote:
> 2014/1/8 Jesse Barnes :
> > No idea if this is correct or not, all the WRPLL programming is new to
> > me. Paulo, can you take a look? At least it doesn't complain on my BDW
> > here...
>
> As a side
dw/vlv and
> all the further stuff?
Doc # would help too, even if it's CDI or internal only... I don't know
where to find this info, or if I did I've forgotten.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
It ought to work ok in 3.14. We have some fun stuff coming after that,
but all the basics are in place now and seem relatively stable.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers
> + dev_priv->rps.rp_down_masked = false;
> + }
I've looked at this too much and confused myself. It looks like the
old logic of the delay numbers being in reverse order has changed
(or maybe that was just ILK?)... so I guess the above
is ok (I
f we need to bring the gfx clocks up (which makes sense) then I
guess we need this. I'm not sure about the wait on the punit though;
that could end up penalizing us in bursty workloads, since the punit
can take quite some time to update the freq, but I don't actually see a
wait here?
Also, is the 500ms timeout really required for the gfx clock? That's a
long time to potentially hold the mutex and delay any clock boosting or
other activity...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Mon, 13 Jan 2014 17:55:27 -0200
Paulo Zanoni wrote:
> 2014/1/8 Jesse Barnes :
> > No idea if this is correct or not, all the WRPLL programming is new to
> > me. Paulo, can you take a look? At least it doesn't complain on my BDW
> > here...
>
> As a side
On Fri, 10 Jan 2014 19:17:02 -0200
Paulo Zanoni wrote:
> 2014/1/10 Jesse Barnes :
> > We were apparently relying on the defaults on BDW, which resulted in no
> > hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to
> > enable all interrupts.
> >
>
: https://bugs.freedesktop.org/show_bug.cgi?id=72833
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 261254a..69b0b71 100644
--- a/drivers/gpu/drm/i915
On Fri, 10 Jan 2014 13:02:20 -0800
Jesse Barnes wrote:
> We were apparently relying on the defaults on BDW, which resulted in no
> hotplug or AUX interrupts.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
> References: https://bugs.freedesktop.org/show_b
We need to read out the CDclk to calculate the DP aux divider correctly.
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 7df5085..4ac1da5 100644
--- a
We were apparently relying on the defaults on BDW, which resulted in no
hotplug or AUX interrupts.
References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
References: https://bugs.freedesktop.org/show_bug.cgi?id=72833
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_irq.c | 4
No idea if this is correct or not, all the WRPLL programming is new to
me. Paulo, can you take a look? At least it doesn't complain on my BDW
here...
Thanks,
Jesse
---
drivers/gpu/drm/i915/i915_reg.h | 6
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/intel_displa
Otherwise we won't check the state until the next DPMS transition, which
may never happen.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm
On Tue, 7 Jan 2014 17:49:05 -0200
Paulo Zanoni wrote:
> 2014/1/6 Jesse Barnes :
> > According to Art, we don't have a way to read back the state reliably at
> > runtime, at least not without risking disabling it again. So drop the
> > readout and checking on BDW.
&
ranch in disable (Paulo)
always report IPS as enabled on BDW (Paulo)
References: https://bugs.freedesktop.org/show_bug.cgi?id=71906
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 19 +++
2 files change
On Tue, 7 Jan 2014 08:07:13 +0100
Daniel Vetter wrote:
> On Tue, Jan 7, 2014 at 12:31 AM, Jesse Barnes
> wrote:
> > On Thu, 19 Dec 2013 10:48:01 -0800
> > Jesse Barnes wrote:
> >
> >> When fastbooting, we read out the pipe timings early on, and then in a
>
On Tue, 7 Jan 2014 08:07:13 +0100
Daniel Vetter wrote:
> On Tue, Jan 7, 2014 at 12:31 AM, Jesse Barnes
> wrote:
> > On Thu, 19 Dec 2013 10:48:01 -0800
> > Jesse Barnes wrote:
> >
> >> When fastbooting, we read out the pipe timings early on, and then in a
>
According to Art, we don't have a way to read back the state reliably at
runtime, at least not without risking disabling it again. So drop the
readout and checking on BDW.
References: https://bugs.freedesktop.org/show_bug.cgi?id=71906
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm
On Thu, 19 Dec 2013 10:48:01 -0800
Jesse Barnes wrote:
> When fastbooting, we read out the pipe timings early on, and then in a
> panel fitted config, disable the fitter later. But we weren't updating
> the pipe src h/w, which meant the mouse cursor was clipped to the
> pfitted
uthor: Jesse Barnes
Date: Wed Nov 27 11:10:26 2013 -0800
drm/i915: use crtc_htotal in watermark calculations to match fastboot v2
It's needed for ILK+ platforms to fastboot without crashing on a divide
by 0 after a DPMS on action.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/
sible in the new mode.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4d1357a..7e46d75 100644
--- a/drivers/gpu/drm/i915/intel_disp
On Thu, 19 Dec 2013 09:38:45 -0800
Jesse Barnes wrote:
> On Thu, 19 Dec 2013 14:29:43 -0200
> Paulo Zanoni wrote:
>
> > From: Paulo Zanoni
> >
> > Function ironlake_wait_panel_off should just wait for the power off
> > delay, while function ironlake_wait_
On Thu, 19 Dec 2013 11:54:52 -0200
Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We'll need this when we merge PC8 and Runtime PM: the PC8
> enable/disable functions need that lock.
>
> Also, it's good practice to not hold a lock for longer than strictly
> needed.
>
> Signed-off-by: Paulo Zano
NEL_POWER_UP_DELAY_SHIFT) |
> - (seq->t8 << PANEL_LIGHT_ON_DELAY_SHIFT);
> - pp_off = (seq->t9 << PANEL_LIGHT_OFF_DELAY_SHIFT) |
> + (1 << PANEL_LIGHT_ON_DELAY_SHIFT);
> + pp_off = (1 << PANEL_LIGHT_OF
_OFF_VALUE (0 | PP_SEQUENCE_NONE | 0
> | 0)
>
> #define IDLE_CYCLE_MASK (PP_ON | PP_SEQUENCE_MASK |
> PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK)
> #define IDLE_CYCLE_VALUE (0 | PP_SEQUENCE_NONE | 0
>
CE_STATE_MASK)
> +#define IDLE_CYCLE_VALUE (0 | PP_SEQUENCE_NONE | 0
> | PP_SEQUENCE_STATE_OFF_IDLE)
>
> static void ironlake_wait_panel_status(struct intel_dp *intel_dp,
> u32 mask,
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 19 Dec 2013 14:29:41 -0200
Paulo Zanoni wrote:
> + * Reset everything, otherwise when suspend/resume gets very fast, we
> + * delay the resume based on the values that were set when we were still
> + * suspending.
> + */
> + intel_dp->last_power_on = tmp_jiffies -
diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 46aea6c..92de688 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -485,6 +485,9 @@ struct intel_dp {
> int backlight_off_delay;
> struct delayed_work panel_vdd_work;
> bool want_panel_vdd;
> + unsigned long last_power_cycle;
> + unsigned long last_power_on;
> + unsigned long last_backlight_off;
> bool psr_setup_done;
> struct intel_connector *attached_connector;
> };
We could bikeshed the name all day, but this looks like a great
improvement.
Reviewed-by: Jesse Barnes
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
fbe0a188
> Author: Paulo Zanoni
> Date: Wed Jun 12 17:27:24 2013 -0300
> drm/i915: extract intel_edp_init_connector
>
> v2: - Rewrite commit message.
>
> Reviewed-by: Jesse Barnes
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/in
even knew that when I was writing it... will fix.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
buffer if preallocated (Chris)
alloc ifbdev up front and pass to init_bios (Chris)
check for bad ifbdev in restore_mode too (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 111 ++---
2 file
.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 91 ++
1 file changed, 91 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index ee4b3c1..9e7f6d1 100644
--- a/drivers/gpu/drm/i915
Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 27 +++
3 files
Along with refcounting changes and breakage.
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 39 ++
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_fbdev.c | 19 -
4 files cha
: split out init ordering changes (Daniel)
don't fetch config if !CONFIG_FB
v8: use proper height in get_plane_config (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 130 +++
driver
For use by get_plane_config.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b8a058a..367d64d 100644
We only need to init the reg offset for DPIO once, but we need to reset
DPIO at resume time and at init time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
Just add an early init since we may need to access DPIO regs early on.
The init call in modeset_init_hw is also needed for the resume case,
when we need to reset DPIO to keep things happy.
v2: split reset and reg init
v3: split patches (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2d20390..f91cb12 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2119,9 +2119,9
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Tue, 17 Dec 2013 19:29:00 +
Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> > int intel_fbdev_init(struct drm_device *dev)
> > @@ -268,17 +461,25 @@ int intel_fbdev_init(struct drm_device *dev)
> > struct drm_i915_pr
On Tue, 17 Dec 2013 22:17:22 +0100
Daniel Vetter wrote:
> On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes
> wrote:
> >> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> >> > @@ -333,7 +535,8 @@ MODULE_LICENSE("GPL and a
On Tue, 17 Dec 2013 10:34:39 +
Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
> > @@ -333,7 +535,8 @@ MODULE_LICENSE("GPL and additional rights");
> > void intel_fbdev_output_poll_changed(struct drm_device *dev)
> > {
On Tue, 17 Dec 2013 10:03:12 +
Chris Wilson wrote:
> On Mon, Dec 16, 2013 at 04:34:26PM -0800, Jesse Barnes wrote:
> > + if (INTEL_INFO(dev)->gen >= 4) {
> > + if (plane_config->tiled)
> > + offset = I915_READ(DSPTILEOFF
On Tue, 17 Dec 2013 09:38:36 +0100
Daniel Vetter wrote:
> On Mon, Dec 16, 2013 at 04:01:41PM -0800, Jesse Barnes wrote:
> > On Sat, 14 Dec 2013 12:01:47 +0100
> > Daniel Vetter wrote:
> > > But I still think the fb lifetime management is a bit broken here and we
> &
> >
> > Signed-off-by: Todd Previte
>
> Reviewed-by: Jani Nikula
Did this ever go in?
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
roken state?
>
> Please file a bug report on bugs.freedesktop.org against DRI ->
> DRM(Intel). Also please always cc relevant mailing lists when
> reporting kernel issues.
Are you using X with a recent (well not ancient) X driver? Do you have
any other console drivers built in,
esse)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 4 +-
drivers/gpu/drm/i915/intel_fbdev.c | 235 ---
3 files changed, 224 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/
The BIOS code will need this to properly inherit the mode.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index af3717a..1ae3d44
: split out init ordering changes (Daniel)
don't fetch config if !CONFIG_FB
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 126 +++
drivers/gpu/drm/i915/intel_drv.h | 8 +++
3
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915
Otherwise subsequent fb activity will try to do blank/unblank on outputs
that were never fully enabled.
v2: drop unnecessary enabled[] modifications in failure cases (Chris)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a
We want to preserve the BIOS/bootloader contents for later.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index db75f22..53675d2
Just add an early init since we may need to access DPIO regs early on.
The init call in modeset_init_hw is also needed for the resume case,
when we need to reset DPIO to keep things happy.
v2: split reset and reg init
v3: split patches (Daniel)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm
We only need to init the reg offset for DPIO once, but we need to reset
DPIO at resume time and at init time.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915
On Thu, 12 Dec 2013 14:44:33 -0800
Jesse Barnes wrote:
> On Thu, 12 Dec 2013 23:39:39 +0100
> Daniel Vetter wrote:
>
> > On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote:
> > > On Thu, 12 Dec 2013 22:21:29 +0100
> > > Daniel Vetter wrote:
> >
On Thu, 12 Dec 2013 22:30:41 +
Chris Wilson wrote:
> On Thu, Dec 12, 2013 at 12:41:57PM -0800, Jesse Barnes wrote:
> > Otherwise subsequent fb activity will try to do blank/unblank on outputs
> > that were never fully enabled.
>
> Hmm, actually this highlights a b
On Sat, 14 Dec 2013 12:28:49 +0100
Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 12:41:55PM -0800, Jesse Barnes wrote:
> > We want to preserve the BIOS/bootloader contents for later.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i
On Sat, 14 Dec 2013 11:47:36 +0100
Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 12:41:56PM -0800, Jesse Barnes wrote:
> > It's needed for early mode state readout, which is in turn needed to
> > inherit the BIOS config. So split out the reset, which we need on
> >
rm_mode_config_reset(dev);
> > - intel_modeset_setup_hw_state(dev, false);
> > - drm_modeset_unlock_all(dev);
>
> As mention in the dpio fixup patch I'd like this code block move to be
> split out in a small prep patch.
Ok will do.
Thanks,
--
Jesse Barnes, Intel Op
On Fri, 13 Dec 2013 21:47:45 +0100
Daniel Vetter wrote:
> On Fri, Dec 13, 2013 at 8:09 PM, Jesse Barnes
> wrote:
> > On Thu, 12 Dec 2013 23:54:37 +0100
> > Daniel Vetter wrote:
> >
> >> > @@ -258,8 +357,102 @@ static void intel_fbdev_de
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.
---
drivers/gpu/drm/i915/i915_irq.c | 10 +-
drivers/gpu/drm/i915/intel_display.c | 27
Obviously still need a lot of work (and I didn't quite get the patch
split correctly, I meant commit the first bits earlier).
I think the approach may be sound though, and is actually not too hard
to get right with all the cross checking we have in place. Things to
fix:
- modeset cross check -
This allows us to hide queuing of enable/disable later.
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/intel_display.c | 83 +---
drivers/gpu/drm/i915/intel_drv.h | 1 +
4 files changed, 71 i
ting wrong, but given how tricky it can be, can you explain
where we'll take the ref here, and show that the right thing will
happen if/when we mode set away from this buffer?
I haven't actually seen a bug here with or without this patch (no
crashes or warns), but I thought I neede
On Thu, 12 Dec 2013 23:54:37 +0100
Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 12:41:54PM -0800, Jesse Barnes wrote:
> > Retrieve current framebuffer config info from the regs and create an fb
> > object for the buffer the BIOS or boot loader left us. This should
>
On Thu, 12 Dec 2013 23:39:39 +0100
Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote:
> > On Thu, 12 Dec 2013 22:21:29 +0100
> > Daniel Vetter wrote:
> >
> > > On Thu, Dec 12, 2013 at 12:41:52PM -0800, Jesse Barnes wrote:
> &
On Thu, 12 Dec 2013 22:30:41 +
Chris Wilson wrote:
> On Thu, Dec 12, 2013 at 12:41:57PM -0800, Jesse Barnes wrote:
> > Otherwise subsequent fb activity will try to do blank/unblank on outputs
> > that were never fully enabled.
>
> Hmm, actually this highlights a b
On Thu, 12 Dec 2013 22:21:29 +0100
Daniel Vetter wrote:
> On Thu, Dec 12, 2013 at 12:41:52PM -0800, Jesse Barnes wrote:
> > The BIOS code will need this to properly inherit the mode.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/gpu/drm/i915/i
e
the sprite bits went in, but for some reason they've never been
merged. They're need to make the sprite stuff more usable by e.g.
Weston.
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freed
;
> local_irq_disable();
>
> + trace_i915_pipe_update_start(crtc, min, max);
> +
> intel_crtc->vbl_received = false;
> scanline = i915_get_crtc_scanline(crtc);
>
> @@ -78,10 +80,14 @@ static void intel_pipe_update_start(struct drm_crtc *crtc)
951,8 +963,8 @@ intel_update_plane(struct drm_plane *plane, struct
> drm_crtc *crtc,
> else
> intel_plane->disable_plane(plane, crtc);
>
> - if (disable_primary)
> - intel_disable_primary(crtc);
> +
9,8 @@ ilk_update_plane(struct drm_plane *plane, struct drm_crtc
> *crtc,
> I915_MODIFY_DISPBASE(DVSSURF(pipe),
>i915_gem_obj_ggtt_offset(obj) + dvssurf_offset);
> POSTING_READ(DVSSURF(pipe));
> +
> + intel_pipe_update_end(crtc);
> }
>
> static void
> @@ -503,6 +571,8 @@ ilk_disable_plane(struct drm_plane *plane, struct
> drm_crtc *crtc)
> struct intel_plane *intel_plane = to_intel_plane(plane);
> int pipe = intel_plane->pipe;
>
> + intel_pipe_update_start(crtc);
> +
> I915_WRITE(DVSCNTR(pipe), I915_READ(DVSCNTR(pipe)) & ~DVS_ENABLE);
> /* Disable the scaler */
> I915_WRITE(DVSSCALE(pipe), 0);
> @@ -510,6 +580,8 @@ ilk_disable_plane(struct drm_plane *plane, struct
> drm_crtc *crtc)
> I915_MODIFY_DISPBASE(DVSSURF(pipe), 0);
> POSTING_READ(DVSSURF(pipe));
>
> + intel_pipe_update_end(crtc);
> +
> intel_update_sprite_watermarks(plane, crtc, 0, 0, false, false);
> }
>
It looks like we may need to check for preemption again on
local_irq_enable() according to preempt-locking.txt? Otherwise it
looks like this does the right thing.
With the above addressed or explained away:
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
pixel_size, fb->pitches[0]);
> linear_offset -= dvssurf_offset;
>
> + I915_WRITE(DVSSTRIDE(pipe), fb->pitches[0]);
> + I915_WRITE(DVSPOS(pipe), (crtc_y << 16) | crtc_x);
> +
> if (obj->tiling_mode != I915_TILING_NONE)
> I915_WRITE(DVSTILEOFF(pipe), (y << 16) | x);
> else
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_drv.h
> @@ -580,6 +580,7 @@ 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);
> +int i915_get_crtc_scanline(struct drm_crtc *crtc);
>
>
> /* intel_crt.c */
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
imary = drm_rect_equals(&dst, &clip);
> + disable_primary = drm_rect_equals(&dst, &clip) &&
> !colorkey_enabled(intel_plane);
> WARN_ON(disable_primary && !visible && intel_crtc->active);
>
> mutex_lock(&dev->struct_mutex
Otherwise subsequent fb activity will try to do blank/unblank on outputs
that were never fully enabled.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_fbdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915
esse)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 4 +-
drivers/gpu/drm/i915/intel_drv.h | 4 +-
drivers/gpu/drm/i915/intel_fbdev.c | 235 ---
3 files changed, 224 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/
901 - 1000 of 3350 matches
Mail list logo
