On Mon, Oct 29, 2012 at 04:59:26PM +0200, Mika Kuoppala wrote:
> Make intel_render_ring_init_dri and intel_init_ring_buffer symmetrical
> with regards of workaround introduced by:
>
> commit 27c1cbd06a7620b354cbb363834f3bb8df4f410d
> Author: Chris Wilson
> Date: Mon Apr 9 13:59:46 2012 +0100
>
On Tue, 30 Oct 2012 21:32:17 +
Chris Wilson wrote:
> On Tue, 30 Oct 2012 18:59:31 +0100, Daniel Vetter wrote:
> > On Fri, Oct 26, 2012 at 10:08:38AM -0700, Jesse Barnes wrote:
> > > The BIOS shouldn't be touching this memory across suspend/resume, so
> > > just leave it alone. This saves us
On Tue, Oct 30, 2012 at 10:32 PM, Chris Wilson wrote:
> On Tue, 30 Oct 2012 18:59:31 +0100, Daniel Vetter wrote:
>> On Fri, Oct 26, 2012 at 10:08:38AM -0700, Jesse Barnes wrote:
>> > The BIOS shouldn't be touching this memory across suspend/resume, so
>> > just leave it alone. This saves us ~50m
On Tue, Oct 30, 2012 at 12:51:11PM +, Damien Lespiau wrote:
> On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it
> > inits the encoder and then calls the proper init_connector functions.
>
On Tue, 30 Oct 2012 18:59:31 +0100, Daniel Vetter wrote:
> On Fri, Oct 26, 2012 at 10:08:38AM -0700, Jesse Barnes wrote:
> > The BIOS shouldn't be touching this memory across suspend/resume, so
> > just leave it alone. This saves us ~50ms on resume on my T420.
> >
> > v2: change gtt restore defa
On Tue, Oct 30, 2012 at 07:16:34PM +0800, Zhenyu Wang wrote:
> Fix power well control state by reading real register offset.
>
> Signed-off-by: Zhenyu Wang
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffw
On Tue, Oct 30, 2012 at 09:01:57AM -0200, Paulo Zanoni wrote:
> Hi
>
> 2012/10/29 Damien Lespiau :
> > From: Damien Lespiau
> >
> > We were writing DSP_ADDR and DSP_SURF unconditionally. This did not
> > trigger an unclaimed write before HSW as the address of DSP_ADDR has
> > been repurposed as D
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h |3 ++-
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_display.c | 30 +-
3 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_d
This lets us pass down flags the drivers might be interested in, e.g. async.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c|2 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c |5 +++--
drivers/gpu/drm/i915/intel_display.c |3 ++-
drivers/gpu/drm/nouveau/
The hw supports async flips through the render ring, so why not expose it?
It gives us one more "tear me harder" option we can use in the DDX and
for other cases where simply flipping to the latest buffer is more
important than visual quality.
Jesse
___
On Fri, Oct 26, 2012 at 10:08:38AM -0700, Jesse Barnes wrote:
> The BIOS shouldn't be touching this memory across suspend/resume, so
> just leave it alone. This saves us ~50ms on resume on my T420.
>
> v2: change gtt restore default on pre-gen4 (Chris)
> move needs_gtt_restore flag into dev_p
On Fri, Oct 26, 2012 at 7:08 PM, Jesse Barnes wrote:
> Communicating via the mailbox registers with the PCU can take quite
> awhile. And updating the ring frequency or enabling turbo is not
> something that needs to happen synchronously, so take it out of our init
> and resume paths to speed thin
On Tue, Oct 30, 2012 at 6:03 PM, Rodrigo Vivi wrote:
> I was here trying to cheking init values and change forcewake set
> during init, etc and nothing was getting RC6 running after resume
> besides that msleep(50) workaround after setting CACHE_MODE_0...
>
> Now with your patch my RC6 is back to
I was here trying to cheking init values and change forcewake set
during init, etc and nothing was getting RC6 running after resume
besides that msleep(50) workaround after setting CACHE_MODE_0...
Now with your patch my RC6 is back to life after resume: RC6 35.8% :D
Well, but when looking at BSPe
On Tue, 30 Oct 2012 14:53:15 -0200
Rodrigo Vivi wrote:
> Reviewed and tested on My SNB fixing bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=54089
>
> Reviewed-by: Rodrigo Vivi
> Tested-by: Rodrigo Vivi
Cool, thanks for testing. It really fixed that bug? I had my
doubts. :)
--
Jesse
Reviewed-by: Rodrigo Vivi
On Fri, Oct 26, 2012 at 3:08 PM, Jesse Barnes wrote:
> The console lock can be contended, so rather than prevent other drivers
> after us from being held up, queue the console suspend into the global
> work queue that can happen anytime. I've measured this to take arou
From: Tomeu Vizoso
When i915 driver decides to fallback to software, the texture's Map
gets replaced by its Buffer attribute, which is NULL because the
texture hasn't been allocated by swrast yet.
The attached patch makes sure that the image buffer for the texture
gets allocated
---
src/mesa/
Reviewed and tested on My SNB fixing bug:
https://bugs.freedesktop.org/show_bug.cgi?id=54089
Reviewed-by: Rodrigo Vivi
Tested-by: Rodrigo Vivi
On Fri, Oct 26, 2012 at 3:08 PM, Jesse Barnes wrote:
> Communicating via the mailbox registers with the PCU can take quite
> awhile. And updating the
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it
> inits the encoder and then calls the proper init_connector functions.
> Notice that for non-eDP ports we call both HDMI and DP connector init,
> s
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We need this since now on DDI we will have 2 connectors on each
> encoder.
>
> Signed-off-by: Paulo Zanoni
Reviewed-by: Damien Lespiau
--
Damien
___
Intel-gfx mailing li
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Both "intel_dp" and "intel_hdmi" structs had a "port" field, which
> always had the same value. It makes more sense to move this to
> intel_digital_port, so we can know the port independently of the
> connector type.
>
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> When intel_hdmi_detect detects a monitor, set intel_encoder->type with
> INTEL_OUTPUT_HDMI. Same for DP.
>
> This should not break the current code because these variables never
> change. This will be used after we cre
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Same reason as the previous HDMI commit: the DDI code will have its
> own encoder init function but still use the DP and HDMI connectors.
>
> Signed-off-by: Paulo Zanoni
> +intel_dp_init(struct drm_device *dev, int o
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We want to split the HDMI connector and encoder initialization because
> in the future the DDI code will have its own "encoder init" function,
> but it will still call intel_hdmi_init_connector. The DDI encoder will
>
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The goal is to have one single encoder capable of controlling both DP
> and HDMI outputs. This patch just adds the initial infrastructure, no
> functional changes.
>
> Previously, both intel_dp and intel_hdmi were inte
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> When we add struct intel_digital_port, there will be no direct way of
> going from intel_{dp,hdmi} to drm_device: we will need to call
> container_of().
>
> This patch adds functions to go from intel_{dp,hdmi} to drm_d
On Fri, Oct 26, 2012 at 10:05 PM, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> - Replace container_of with enc_to_intel_dp.
> - Walk through less structures when making assignments.
> - Rename some variables to keep our naming standards.
>
> As a bonus, this will reduce the usage of "struct in
Hi
2012/10/29 Damien Lespiau :
> From: Damien Lespiau
>
> We were writing DSP_ADDR and DSP_SURF unconditionally. This did not
> trigger an unclaimed write before HSW as the address of DSP_ADDR has
> been repurposed as DSP_LINOFF.
>
> On HSW, though, DSP_LINOFF has been removed and then writting t
Hi Daniel,
Thanks for the patch.
On Saturday 27 October 2012 15:52:04 Daniel Vetter wrote:
> Userspace seems to like this, see
>
> commit cb0953d734348e8862d6d7edc666cfb3bf6d8fae
> Author: Adam Jackson
> Date: Fri Jul 16 14:46:29 2010 -0400
>
> drm/i915: Initialize LVDS and eDP outputs b
Fix power well control state by reading real register offset.
Signed-off-by: Zhenyu Wang
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 838d67d..3bcaad6 100644
---
30 matches
Mail list logo
