On Thu, 25 Jul 2013, Jani Nikula wrote:
> On muxed systems, the other vgaswitcheroo client may depend on i915 to
> handle the backlight. We began switching off the backlight since
>
> commit a261b246ebd552fd5d5a8ed84cc931bb821c427f
> Author: Daniel Vetter
> Date: Thu Jul 26 19:21:47 2012 +0200
On Wed, Aug 07, 2013 at 12:45:14AM +0200, Daniel Vetter wrote:
> We'll loop forever, but if we wake up before the hangcheck time has a
> chance to complain that we're stuck waiting for the interrupt we'll
> loose that valuable debug tool. And silently blocking for 1 second is
> just not the right a
I have a BayTrail board with two HDMI ports and running the default Tizen 3.0M1
release. The first HDMI shows up just fine but I can't get the second screen
to display anything. I tried enabling the second screen through the kernel
command line parameters (video=HDMI-1:e video=HDMI-2:e) and ru
Patches 1-5, 10, 11 are:
Reviewed-by: Alex Deucher
On Tue, Aug 6, 2013 at 3:32 PM, Damien Lespiau wrote:
> Cc: Thierry Reding
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Damien Lespiau
> ---
> drivers/video/hdmi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --gi
Rather than continue to fix up the timeouts to work around the interface
impedence in wait_event_*(), open code the combination of
wait_event[_interruptible][_timeout]. And note the code size reduction,
and dare say readability?, in doing so..
Food for thought.
---
drivers/gpu/drm/i915/i915_gem.c
On Tue, Aug 06, 2013 at 06:57:17PM -0300, Paulo Zanoni wrote:
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 2ef4335..7f6ec9e 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -159
On Tue, Aug 06, 2013 at 06:57:14PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I did some brief tests and the "new_val = pmimr" condition usually
> happens a few times after exiting games.
>
> Signed-off-by: Paulo Zanoni
I'm not sure of the value of this patch by itself. It did make me
On Tue, Aug 06, 2013 at 09:38:41PM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 05:00:14PM -0700, Ben Widawsky wrote:
> > formerly: "drm/i915: Create VMAs (part 5) - move mm_list"
> >
> > The mm_list is used for the active/inactive LRUs. Since those LRUs are
> > per address space, the lin
On Wed, Aug 7, 2013 at 1:25 AM, Ben Widawsky wrote:
> On Wed, Aug 07, 2013 at 12:59:29AM +0200, Daniel Vetter wrote:
>> On Wed, Aug 7, 2013 at 12:57 AM, Ben Widawsky wrote:
>> >> > We need evict_everything for #1. For #2, we call evict_something already
>> >> > for the vm when we go through the o
>
> In the same exaggerated view, Jesse's premises:
> - Actual user/developer testing is more valuable than review and refactoring
> - Colorary: merging code with bugs is acceptable, we want the bug reports
> - Endless code churn due to review/refactoring may actually introduce
> bugs not present
On Wed, Aug 07, 2013 at 12:59:29AM +0200, Daniel Vetter wrote:
> On Wed, Aug 7, 2013 at 12:57 AM, Ben Widawsky wrote:
> >> > We need evict_everything for #1. For #2, we call evict_something already
> >> > for the vm when we go through the out of space path. If that failed,
> >> > evicting everythi
On Wed, Aug 7, 2013 at 12:57 AM, Ben Widawsky wrote:
>> > We need evict_everything for #1. For #2, we call evict_something already
>> > for the vm when we go through the out of space path. If that failed,
>> > evicting everything for a specific VM is just the same operation. But
>> > maybe I've gl
On Tue, Aug 06, 2013 at 11:29:49PM +0200, Daniel Vetter wrote:
> On Tue, Aug 06, 2013 at 02:27:39PM -0700, Ben Widawsky wrote:
> > On Tue, Aug 06, 2013 at 08:39:50PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 31, 2013 at 05:00:11PM -0700, Ben Widawsky wrote:
> > > > @@ -183,9 +186,11 @@ i915_gem
We'll loop forever, but if we wake up before the hangcheck time has a
chance to complain that we're stuck waiting for the interrupt we'll
loose that valuable debug tool. And silently blocking for 1 second is
just not the right approach.
Noticed since Paulo reported a suspicious 2 fps when running
On Tue, Aug 06, 2013 at 06:57:10PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Hi
>
> Here's my next attempt at the Haswell PC8+ feature.
>
> What's new?
>
> 1. I hope I implemented the feedback from Chris. Many function renames, a few
> style changes. Chris' biggest concern was a
From: Paulo Zanoni
This should be working, so enable it by default. Also easy to revert.
v2: Rebase, s/allow/enable/.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drive
From: Paulo Zanoni
For now it just prints the value of the forbid_refcount and allowing
variables.
v2: Update to recent renames and add the new fields.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 25 insertions(+)
diff --
From: Paulo Zanoni
This patch allows PC8+ states on Haswell. These states can only be
reached when all the display outputs are disabled, and they allow some
more power savings.
The fact that the graphics device is allowing PC8+ doesn't mean that
the machine will actually enter PC8+: all the othe
From: Paulo Zanoni
If the error interrupts are already disabled, don't disable and
reenable them. This is going to be needed when we're in PC8+, where
all the interrupts are disabled so we won't risk re-enabling
DE_ERR_INT_IVB.
v2: Use dev_priv->irq_mask (Chris)
Signed-off-by: Paulo Zanoni
---
From: Paulo Zanoni
Just like irq_mask and gt_irq_mask, use it to track the status of
GEN6_PMIMR so we don't need to read it again every time we call
snb_update_pm_irq.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 12 +++-
2 f
From: Paulo Zanoni
I did some brief tests and the "new_val = pmimr" condition usually
happens a few times after exiting games.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: Paulo Zanoni
Just like we're doing with the other IMR changes.
One of the functional changes is that not every caller was doing the
POSTING_READ.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 47 -
drivers/gpu/drm/i915/intel_dr
From: Paulo Zanoni
Just like the functions that touch DEIMR and SDEIMR, but for GTIMR.
The new functions contain a POSTING_READ(GTIMR) which was not present
at the 2 callers inside i915_irq.c.
The implementation is based on ibx_display_interrupt_update.
Signed-off-by: Paulo Zanoni
---
drivers
From: Paulo Zanoni
We already have code to disable LCPLL and switch to FCLK, so we need this too.
We still don't call the code to disable LCPLL, but we'll call it when we add
support for Package C8+.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 9 ++---
1 file changed
From: Paulo Zanoni
Hi
Here's my next attempt at the Haswell PC8+ feature.
What's new?
1. I hope I implemented the feedback from Chris. Many function renames, a few
style changes. Chris' biggest concern was about the interrupts. So in this
series you'll see patches 2-6 moving some inte
On Tue, Aug 06, 2013 at 08:43:42PM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 05:00:12PM -0700, Ben Widawsky wrote:
> > In some places, we want to know if an object is bound in any address
> > space, and not just the global GTT. This often applies when there is a
> > single global resour
On Tue, Aug 06, 2013 at 02:27:39PM -0700, Ben Widawsky wrote:
> On Tue, Aug 06, 2013 at 08:39:50PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 31, 2013 at 05:00:11PM -0700, Ben Widawsky wrote:
> > > @@ -183,9 +186,11 @@ i915_gem_evict_everything(struct drm_device *dev)
> > > i915_gem_retire_reque
On Tue, Aug 06, 2013 at 08:39:50PM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 05:00:11PM -0700, Ben Widawsky wrote:
> > Eviction code, like the rest of the converted code needs to be aware of
> > the address space for which it is evicting (or the everything case, all
> > addresses). With
On Wed, Jul 31, 2013 at 05:00:21PM -0700, Ben Widawsky wrote:
> Building on the last patch which created the new function pointers in
> the VM for bind/unbind, here we actually put those new function pointers
> to use.
>
> Split out as a separate patch to aid in review. I'm fine with squashing
> i
On Tue, Aug 06, 2013 at 10:24:02PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Refactor the watermarks computation for one level to a separate
> function. This function will now set the ->enable flat to true,
s/flat/flag/
Though I did think you meant a flatten value at
On Wed, Jul 31, 2013 at 05:00:19PM -0700, Ben Widawsky wrote:
> Even though we track object activeness and not VMA, because we have the
> active_list be based on the VM, it makes the most sense to use VMAs in
> the APIs.
>
> NOTE: Daniel intends to eventually rip out active/inactive LRUs, but for
On Tue, Aug 06, 2013 at 10:43:08PM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 05:00:18PM -0700, Ben Widawsky wrote:
> > This attempts to convert all the execbuf code to speak in vmas. Since
> > the execbuf code is very self contained it was a nice isolated
> > conversion.
> >
> > The me
On Tue, Aug 06, 2013 at 10:24:03PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We don't need to store the FBC WM enabled status in each watermark
> level. We anyway have to reduce it down to a single boolean, so just
> delay checking the FBC WM limit until we're computin
2013/8/6 Daniel Vetter :
> On Tue, Aug 06, 2013 at 04:33:53PM -0300, Paulo Zanoni wrote:
>> 2013/8/5 Daniel Vetter :
>> > On Mon, Aug 05, 2013 at 10:42:08AM -0300, Paulo Zanoni wrote:
>> >> 2013/8/5 Daniel Vetter :
>> >> > On Mon, Jul 29, 2013 at 05:53:27PM -0300, Paulo Zanoni wrote:
>> >> The prob
On Wed, Jul 31, 2013 at 05:00:18PM -0700, Ben Widawsky wrote:
> This attempts to convert all the execbuf code to speak in vmas. Since
> the execbuf code is very self contained it was a nice isolated
> conversion.
>
> The meat of the code is about turning eb_objects into eb_vma, and then
> wiring u
On Tue, Aug 06, 2013 at 10:24:06PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There are quite a few variables we need to take into account to
> determine the maximum watermark levels, so it feels a bit cleaner
> to calculate those rather than just have a bunch of what l
On Tue, Aug 06, 2013 at 10:24:09PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We're going to want to know which CRTC we're dealing with, so pass it
> down to the update/disable_plane hooks.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
--
Chris
On Tue, Aug 06, 2013 at 10:24:04PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We're going to use the 1/2 vs. 5/6 split option already on IVB so the
> HSW name is not proper. Just give it an intel_ prefix and move it to
> i915_drv.h so that we can use it there later.
>
On Tue, Aug 06, 2013 at 10:24:10PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Check plane->fb in intel_disable_plane() to determine if the plane
> is already disabled.
>
> If the plane has an fb, then it must also have a crtc, so we can drop
> the plane->crtc check and
On Tue, Aug 06, 2013 at 10:24:11PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We're going to want to know the crtc in the watermark code to avoid
> doing more work than we have to. We should also pass the plane we're
> disabling so that we know where to stick our waterm
Mabye I should actually cc Damien when I poke him ...
-Daniel
On Tue, Aug 06, 2013 at 10:11:02PM +0200, Daniel Vetter wrote:
> On Tue, Aug 06, 2013 at 04:33:53PM -0300, Paulo Zanoni wrote:
> > 2013/8/5 Daniel Vetter :
> > > On Mon, Aug 05, 2013 at 10:42:08AM -0300, Paulo Zanoni wrote:
> > >> 2013/
On Tue, Aug 06, 2013 at 10:24:05PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Let's call hsw_lp_wm_result intel_wm_level from now on and move it to
> i915_drv.h for later use.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel
On Tue, Aug 06, 2013 at 04:33:53PM -0300, Paulo Zanoni wrote:
> 2013/8/5 Daniel Vetter :
> > On Mon, Aug 05, 2013 at 10:42:08AM -0300, Paulo Zanoni wrote:
> >> 2013/8/5 Daniel Vetter :
> >> > On Mon, Jul 29, 2013 at 05:53:27PM -0300, Paulo Zanoni wrote:
> >> The problem is: let's imagine there's so
On Tue, Aug 06, 2013 at 10:24:08PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Give a name to the plane watermark related data we have currently
> stored under intel_plane->wm.
>
> We also observe that this data is more or less the same that we have
> in the hsw_pipe_wm
On Tue, Aug 06, 2013 at 10:24:12PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> ILK and VLV codepaths didn't update sprite watermarks when disabling a
> sprite. Make them do that.
>
> Signed-off-by: Ville Syrjälä
I am totally loving the naming confusion between intel_p
On Tue, Aug 06, 2013 at 10:24:07PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> There is a bunch of global state that needs to be considered when
> checking watermarks for validity. Move most of that to a new
> structure intel_wm_config, to avoid having to pass around so
On Wed, Jul 31, 2013 at 05:00:14PM -0700, Ben Widawsky wrote:
> formerly: "drm/i915: Create VMAs (part 5) - move mm_list"
>
> The mm_list is used for the active/inactive LRUs. Since those LRUs are
> per address space, the link should be per VMx .
>
> Because we'll only ever have 1 VMA before this
On Tue, Aug 06, 2013 at 10:24:01PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Refactor the code a bit to split the watermark level validity check into
> a separate function.
>
> Also add hack there that allows us to use it even for LP0 watermarks.
> ATM we don't pre-co
s/consistentnly/consistently/ in subject.
-Chris, who is always ashamed of his sentence construction and spelling
in changelogs.
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists
2013/8/5 Daniel Vetter :
> On Mon, Aug 05, 2013 at 10:42:08AM -0300, Paulo Zanoni wrote:
>> 2013/8/5 Daniel Vetter :
>> > On Mon, Jul 29, 2013 at 05:53:27PM -0300, Paulo Zanoni wrote:
>> >> From: Paulo Zanoni
>> >>
>> >> This test chekcs our code that enables Package C8+. The environment
>> >> req
set_frame() wraps the write_frame() vfunc. Be consistent and name the
wrapping function like the vfunc being called.
It's doubly confusing as we also have a set_infoframes() vfunc and
set_infoframe() doesn't wrap it.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/
I cannot find any evidence what we shouldn't try to set those fields
when setting a non-CEA mode on an HDMI sink. So just kill that return.
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/d
Suggested-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_edid.c| 3 +++
drivers/gpu/drm/i915/intel_hdmi.c | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 8d1139f..a9c8980 100644
All the HDMI infoframe code has been ported to use video/hdmi.c, so it's
time to say bye bye to this code.
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_drv.h | 61 ---
drivers/gpu/drm/i915/intel_hdmi.c | 15
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
Signed-off-by: Paulo Zanoni
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/i915/intel_sdvo.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.
Let's use the drivers/video/hmdi.c and drm infoframe helpers to build
our infoframes.
v2: Simplify the logic to compute the buffer size. We can just take the
maximum infoframe size rounded to 32, which happens to be what the
hardware let us write anyway.
v3: Remove unnecessary memset() (Ville Syr
First step in the move to the shared infoframe infrastructure, let's
move the different infoframe helpers and the write_infoframe() vfunc to
a type (enum hdmi_infoframe_type) and a buffer + len instead of using
our struct dip_infoframe.
v2: constify the infoframe pointer and don't mix signs (Ville
From CEA-861:
Data Byte 1, bit A0 indicates whether Active Format Data is present in
Data Byte 2 bits R3 through R0. A source device shall set A0=1 when
any of the AFD bits are set.
ie. if we want to set active_aspect, we need to set the
active_info_valid bit to 1 as well.
Cc: Thierry Redi
If the user if this API is providing a bigger buffer than the infoframe
size, it could be for a could reason. For instance it could be because
it gives the buffer that will be written to the hardware, up to the
maximum of an infoframe size.
Instead of just zeroing up to the infoframe size, let's z
Cc: Thierry Reding
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
include/linux/hdmi.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index 0f3f82e..bc6743e 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -23,6 +2
And a way to pack hdmi_infoframe generically.
Cc: Thierry Reding
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/video/hdmi.c | 43 +++
include/linux/hdmi.h | 17 +
2 files changed, 60 insertions(+)
diff --git a/driv
Cc: Thierry Reding
Reviewed-by: Ville Syrjälä
Signed-off-by: Damien Lespiau
---
drivers/video/hdmi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 4017833..dbd882f 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video
Re-posting the whole series because I forgot dri-devel in the first version and
also added a few patches from the review.
Version 2 of the series:
http://lists.freedesktop.org/archives/intel-gfx/2013-August/031183.html
With Ville's comments so far addressed.
I've also added the already posted
On Tue, Aug 06, 2013 at 10:08:38PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 06, 2013 at 07:45:40PM +0100, Chris Wilson wrote:
> > On Tue, Aug 06, 2013 at 09:03:01PM +0300, Ville Syrjälä wrote:
> > > On Tue, Aug 06, 2013 at 05:16:14PM +0100, Chris Wilson wrote:
> > > > On Tue, Aug 06, 2013 at 05:24
From: Ville Syrjälä
There is a bunch of global state that needs to be considered when
checking watermarks for validity. Move most of that to a new
structure intel_wm_config, to avoid having to pass around so
many variables.
One notable thing left out is the DDB partitioning information,
since we
From: Ville Syrjälä
ILK and VLV codepaths didn't update sprite watermarks when disabling a
sprite. Make them do that.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/
From: Ville Syrjälä
Give a name to the plane watermark related data we have currently
stored under intel_plane->wm.
We also observe that this data is more or less the same that we have
in the hsw_pipe_wm_parameters structure, so use it there as well.
Signed-off-by: Ville Syrjälä
---
drivers/g
From: Ville Syrjälä
We're going to want to know the crtc in the watermark code to avoid
doing more work than we have to. We should also pass the plane we're
disabling so that we know where to stick our watermark parameters
without having to go look the plane up.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Let's call hsw_lp_wm_result intel_wm_level from now on and move it to
i915_drv.h for later use.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/intel_pm.c | 20 ++--
2 files changed, 14 insertions(+), 14 d
From: Ville Syrjälä
Check plane->fb in intel_disable_plane() to determine if the plane
is already disabled.
If the plane has an fb, then it must also have a crtc, so we can drop
the plane->crtc check and just call intel_enable_primary() directly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/d
From: Ville Syrjälä
We're going to use the 1/2 vs. 5/6 split option already on IVB so the
HSW name is not proper. Just give it an intel_ prefix and move it to
i915_drv.h so that we can use it there later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/
From: Ville Syrjälä
We're going to want to know which CRTC we're dealing with, so pass it
down to the update/disable_plane hooks.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h| 4 +++-
drivers/gpu/drm/i915/intel_sprite.c | 21 -
2 files changed, 15
From: Ville Syrjälä
There are quite a few variables we need to take into account to
determine the maximum watermark levels, so it feels a bit cleaner
to calculate those rather than just have a bunch of what look like
magic numbers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm
From: Ville Syrjälä
We don't need to store the FBC WM enabled status in each watermark
level. We anyway have to reduce it down to a single boolean, so just
delay checking the FBC WM limit until we're computing the final
value.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c |
From: Ville Syrjälä
Refactor the watermarks computation for one level to a separate
function. This function will now set the ->enable flat to true,
even if the watermark level wasn't actually checked yet. In the
future we will delay the checking so we must consider all unchecked
watermarks as pos
From: Ville Syrjälä
Refactor the code a bit to split the watermark level validity check into
a separate function.
Also add hack there that allows us to use it even for LP0 watermarks.
ATM we don't pre-compute/check the LP0 watermarks, so we just have to
clamp them to the maximum and hope things
From: Ville Syrjälä
Let's be consistent and always call our variables 'enabled' insted of
the occasional 'enable'.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/driv
Next installment of ILK+ watermark prep patches.
This set doesn't really achieve much of anything, but the patches are
quite small and should not be very controversial. It gets us almost all
the way to the big watermark code replacement patch of the original series,
and so if we get these in I can
On Mon, Aug 05, 2013 at 04:12:11PM +0300, Ville Syrjälä wrote:
> > static void intel_set_infoframe(struct drm_encoder *encoder,
> > - struct dip_infoframe *frame)
> > + union hdmi_infoframe *frame)
> > {
> > struct intel_hdmi *intel_hdmi = e
On Wed, Jul 31, 2013 at 05:00:13PM -0700, Ben Widawsky wrote:
> formerly: "drm/i915: Create VMAs (part 3.5) - map and fenceable
> tracking"
>
> The map_and_fenceable tracking is per object. GTT mapping, and fences
> only apply to global GTT. As such, object operations which are not
> performed on
On Tue, Aug 06, 2013 at 07:45:40PM +0100, Chris Wilson wrote:
> On Tue, Aug 06, 2013 at 09:03:01PM +0300, Ville Syrjälä wrote:
> > On Tue, Aug 06, 2013 at 05:16:14PM +0100, Chris Wilson wrote:
> > > On Tue, Aug 06, 2013 at 05:24:25PM +0300, Ville Syrjälä wrote:
> > > > On Tue, Aug 06, 2013 at 01:17
On Tue, Aug 06, 2013 at 08:29:47PM +0200, Daniel Vetter wrote:
> On Wed, Jul 31, 2013 at 05:00:10PM -0700, Ben Widawsky wrote:
[snip]
> > @@ -3643,33 +3672,39 @@ i915_gem_object_pin(struct drm_i915_gem_object *obj,
> > bool map_and_fenceable,
> > bool nonblocking)
On Tue, Aug 06, 2013 at 09:03:01PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 06, 2013 at 05:16:14PM +0100, Chris Wilson wrote:
> > On Tue, Aug 06, 2013 at 05:24:25PM +0300, Ville Syrjälä wrote:
> > > On Tue, Aug 06, 2013 at 01:17:04PM +0100, Chris Wilson wrote:
> > > > +static bool cpu_write_needs_
On Wed, Jul 31, 2013 at 05:00:12PM -0700, Ben Widawsky wrote:
> In some places, we want to know if an object is bound in any address
> space, and not just the global GTT. This often applies when there is a
> single global resource (object, pages, etc.)
>
> function |
On Wed, Jul 31, 2013 at 05:00:11PM -0700, Ben Widawsky wrote:
> Eviction code, like the rest of the converted code needs to be aware of
> the address space for which it is evicting (or the everything case, all
> addresses). With the updated bind/unbind interfaces of the last patch,
> we can now saf
On Wed, Jul 31, 2013 at 05:00:10PM -0700, Ben Widawsky wrote:
> As alluded to in several patches, and it will be reiterated later... A
> VMA is an abstraction for a GEM BO bound into an address space.
> Therefore it stands to reason, that the existing bind, and unbind are
> the ones which will be t
On Tue, Aug 06, 2013 at 08:01:34PM +0200, Daniel Vetter wrote:
> On Tue, Aug 6, 2013 at 7:49 PM, Damien Lespiau
> wrote:
> > On Mon, Aug 05, 2013 at 08:50:45PM +0300, Ville Syrjälä wrote:
> >> On Fri, Aug 02, 2013 at 06:22:58PM +0100, Damien Lespiau wrote:
> >> > set_frame() wraps the write_frame
On Wed, Jul 31, 2013 at 05:00:07PM -0700, Ben Widawsky wrote:
> I can't remember why I added this initially.
>
> TODO: Throw out if not necessary
>
> Signed-off-by: Ben Widawsky
Oops. I vaguely remember that there was some shuffling around with where
the ppgtt pdes are written once we have real
On Tue, Aug 06, 2013 at 08:13:04PM +0300, Ville Syrjälä wrote:
> On Tue, Aug 06, 2013 at 05:43:07PM +0100, Chris Wilson wrote:
> > Rather than open-code the teardown of a framebuffer, export the routine
> > from intel_display.c. This then make intel_fbdev symmetric in its use of
> > the common inte
On Tue, Aug 6, 2013 at 7:42 PM, Toralf Förster wrote:
> On 07/26/2013 07:58 PM, Daniel Vetter wrote:
>> On Wed, Jul 24, 2013 at 05:51:41PM +0200, Toralf Förster wrote:
>>> Realized this today while booting a ThinkPad T420 with integrated intel
>>> graphic :
>>
>> Can you please retest with latest
On Tue, Aug 06, 2013 at 05:16:14PM +0100, Chris Wilson wrote:
> On Tue, Aug 06, 2013 at 05:24:25PM +0300, Ville Syrjälä wrote:
> > On Tue, Aug 06, 2013 at 01:17:04PM +0100, Chris Wilson wrote:
> > > +static bool cpu_write_needs_clflush(struct drm_i915_gem_object *obj)
> > > +{
> > > + if (!cpu_cach
On Tue, Aug 6, 2013 at 7:49 PM, Damien Lespiau wrote:
> On Mon, Aug 05, 2013 at 08:50:45PM +0300, Ville Syrjälä wrote:
>> On Fri, Aug 02, 2013 at 06:22:58PM +0100, Damien Lespiau wrote:
>> > set_frame() wraps the write_frame() vfunc. Be consistent and name the
>> > wrapping function like the vfunc
After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write t
On Mon, Aug 05, 2013 at 08:50:45PM +0300, Ville Syrjälä wrote:
> On Fri, Aug 02, 2013 at 06:22:58PM +0100, Damien Lespiau wrote:
> > set_frame() wraps the write_frame() vfunc. Be consistent and name the
> > wrapping function like the vfunc being called.
> >
> > It's doubly confusing as we also hav
On 08/06/2013 07:38 PM, Toralf Förster wrote:
> with kernel 3.10.5 at a ThinkPad T420 at a 32bit stable Gentoo Linux I
> got the attached trace today.
>
> I'm not sure if it is a regression of 3.10.4 or if it is new.
>
>
>
ick - overlooked an existing thread to thais - forget this mail
--
MfG
On 07/26/2013 07:58 PM, Daniel Vetter wrote:
> On Wed, Jul 24, 2013 at 05:51:41PM +0200, Toralf Förster wrote:
>> Realized this today while booting a ThinkPad T420 with integrated intel
>> graphic :
>
> Can you please retest with latest upstream git from Linus' tree?
erm, that patch won't apply
with kernel 3.10.5 at a ThinkPad T420 at a 32bit stable Gentoo Linux I
got the attached trace today.
I'm not sure if it is a regression of 3.10.4 or if it is new.
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Aug 6 17:37:52 n22 kernel: PM:
On Tue, Aug 06, 2013 at 05:43:07PM +0100, Chris Wilson wrote:
> Rather than open-code the teardown of a framebuffer, export the routine
> from intel_display.c. This then make intel_fbdev symmetric in its use of
> the common intel_framebuffer routines to initialise and clean up the
> struct intel_fr
On Tue, Aug 6, 2013 at 4:50 PM, Paulo Zanoni wrote:
> A few direct responses and my 2 cents at the end. This is all my
> humble opinion, feel free to disagree or ignore it :)
I think you make some excellent points, so thanks a lot for joining
the discussion.
> 2013/8/6 Daniel Vetter :
>>
>> I of
Rather than open-code the teardown of a framebuffer, export the routine
from intel_display.c. This then make intel_fbdev symmetric in its use of
the common intel_framebuffer routines to initialise and clean up the
struct intel_framebuffer. (And new features need only be added in one
location!)
Sig
1 - 100 of 122 matches
Mail list logo
