On Sat, Aug 31, 2013 at 01:12:55AM +0100, Chris Wilson wrote:
> On Fri, Aug 30, 2013 at 04:43:59PM -0700, Ben Widawsky wrote:
> > From: Ben Widawsky
> >
> > As we plumb the code with more VM information, it has become more
> > obvious that the easiest way to deal with bind and unbind is to simply
On Sat, Aug 31, 2013 at 01:06:02AM +0100, Chris Wilson wrote:
> On Fri, Aug 30, 2013 at 04:43:57PM -0700, Ben Widawsky wrote:
> > Tracing vm eviction is really the event we care about. For the cases we
> > evict everything, we still will get the trace.
>
> Keep both until you retire evict_everythi
On Sat, Aug 31, 2013 at 12:50:30AM +0100, Chris Wilson wrote:
> On Fri, Aug 30, 2013 at 04:43:54PM -0700, Ben Widawsky wrote:
> > lifted from Daniel:
> > pread/pwrite isn't about the object's domain at all, but purely about
> > synchronizing for outstanding rendering. Replacing the call to
> > set_
On Sat, Aug 31, 2013 at 12:52:03AM +0100, Chris Wilson wrote:
> On Fri, Aug 30, 2013 at 04:43:55PM -0700, Ben Widawsky wrote:
> > As we'll see in the next patch, being able to evict for just 1 VM is
> > handy.
> >
> > Signed-off-by: Ben Widawsky
> > ---
> > drivers/gpu/drm/i915/i915_gem_evict.c
Both of these were taking the mode_config mutex but executed from the
same work queue. If intel_crtc_page_flip happened to flush a work queue
containing an HPD event handler work item, deadlock resulted, since the
mutex required by the HPD handler was taken before the flush. Instead
use a separat
On Fri, Aug 30, 2013 at 04:43:59PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> As we plumb the code with more VM information, it has become more
> obvious that the easiest way to deal with bind and unbind is to simply
> put the function pointers in the vm, and let those choose the correct
On Fri, Aug 30, 2013 at 04:43:58PM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> Even though we track object activity 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/
On Fri, Aug 30, 2013 at 04:43:57PM -0700, Ben Widawsky wrote:
> Tracing vm eviction is really the event we care about. For the cases we
> evict everything, we still will get the trace.
Keep both until you retire evict_everything for good. Sometimes you need
flashing neon lights to explain things i
On Fri, Aug 30, 2013 at 04:43:56PM -0700, Ben Widawsky wrote:
> When reserving objects during execbuf, it is possible to come across an
> object which will not fit given the current fragmentation of the address
> space. We do not have any defragment in drm_mm, so the strategy is to
> instead evict
On Fri, Aug 30, 2013 at 04:43:55PM -0700, Ben Widawsky wrote:
> As we'll see in the next patch, being able to evict for just 1 VM is
> handy.
>
> Signed-off-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_gem_evict.c | 28 ++--
> 1 file changed, 22 insertions(+), 6 del
On Fri, Aug 30, 2013 at 04:43:54PM -0700, Ben Widawsky wrote:
> lifted from Daniel:
> pread/pwrite isn't about the object's domain at all, but purely about
> synchronizing for outstanding rendering. Replacing the call to
> set_to_gtt_domain with a wait_rendering would imo improve code
> readability
From: Ben Widawsky
With bind/unbind function pointers in place, we no longer need
insert_entries. We could, and want, to remove clear_range, however it's
not totally easy at this point. Since it's used in a couple of place
still that don't only deal in objects: setup, ppgtt init, and restore
gtt
From: Ben Widawsky
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
into the previous patch if people request it.
v2: Upd
From: Ben Widawsky
As we plumb the code with more VM information, it has become more
obvious that the easiest way to deal with bind and unbind is to simply
put the function pointers in the vm, and let those choose the correct
way to handle the page table updates. This change allows many places in
From: Ben Widawsky
Even though we track object activity 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
now, leave them be.
Signed-off-by: Ben Widawsky
Co
Tracing vm eviction is really the event we care about. For the cases we
evict everything, we still will get the trace.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_evict.c | 4 ++--
drivers/gpu/drm/i915/i915_trace.h | 12 ++--
2 files changed, 8 insertions(+), 8 del
When reserving objects during execbuf, it is possible to come across an
object which will not fit given the current fragmentation of the address
space. We do not have any defragment in drm_mm, so the strategy is to
instead evict everything, and reallocate objects.
With the upcoming addition of mul
lifted from Daniel:
pread/pwrite isn't about the object's domain at all, but purely about
synchronizing for outstanding rendering. Replacing the call to
set_to_gtt_domain with a wait_rendering would imo improve code
readability. Furthermore we could pimp pread to only block for
outstanding writes a
As we'll see in the next patch, being able to evict for just 1 VM is
handy.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_evict.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu
Now that [hopefully all] of the fallout from the last round of VMA merging has
been taken care of - Resending the remaining VMA patches which are required for
the full PPGTT support.
Some of these patches are new as a result of the last round of review. For the
ones which are just a RESEND, I've o
On Fri, Aug 30, 2013 at 02:40:26PM +0100, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_cont
2013/8/30 :
> From: Ville Syrjälä
>
> Pull the expected max WM level determinations out to a separate
> function. Will have another user soon.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c | 19 +++
> 1 file changed, 11 ins
2013/8/30 :
> From: Ville Syrjälä
>
> Unify the code a bit to use ilk_compute_wm_level for all watermark
> levels.
>
> Signed-off-by: Ville Syrjälä
Looks correct and doesn't change the WM values set on my specific
eDP+HDMI config here...
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i91
On Fri, Aug 30, 2013 at 05:26:29PM -0300, Paulo Zanoni wrote:
> 2013/8/30 :
> > From: Ville Syrjälä
> >
> > Make the call to intel_update_watermarks() just once or twice during
> > modeset. Ideally it should happen independently when each plane gets
> > enabled/disabled, but for now it seems bett
2013/8/30 :
> From: Ville Syrjälä
>
> hsw_pipe_wm_parameters and hsw_wm_maximums typically are read only. Make
> them const.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: GCC 4.7.3
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_pm.c | 20 ++--
> 1 file changed,
On Fri, Aug 30, 2013 at 05:09:49PM -0300, Paulo Zanoni wrote:
> 2013/8/30 :
> > From: Ville Syrjälä
> >
> > Passing the appropriate crtc to intel_update_watermarks() should help
> > in avoiding needless work in the future.
> >
> > Signed-off-by: Ville Syrjälä
>
> I like the fact that now we're
2013/8/30 Jani Nikula :
> The spec says to notify prior to power down and after power up. It is
> unclear whether it makes a difference.
>
> Signed-off-by: Jani Nikula
> Reviewed-by: Paulo Zanoni
>
> ---
>
> Paulo, still okay with the r-b?
Yes :)
> ---
> drivers/gpu/drm/i915/intel_display.c |
2013/8/30 :
> From: Ville Syrjälä
>
> Make the call to intel_update_watermarks() just once or twice during
> modeset. Ideally it should happen independently when each plane gets
> enabled/disabled, but for now it seems better to keep it in central
> place. We can improve things when we get all th
2013/8/30 Jani Nikula :
> Notifying the bios lets it enter power saving states.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h |7 +++
> drivers/gpu/drm/i915/intel_opregion.c | 27 +++
> 2 files changed,
2013/8/30 :
> From: Ville Syrjälä
>
> Passing the appropriate crtc to intel_update_watermarks() should help
> in avoiding needless work in the future.
>
> Signed-off-by: Ville Syrjälä
I like the fact that now we're passing the CRTC, but my
only worry is that now some functions overwrite the "c
2013/8/30 Jani Nikula :
> v2:
> - go to PCI_D3cold
> - shuffle the call site a bit
Ok, so I know I'm the one who requested to shuffle the call site, but
it's because I thought that when we disable LCPLL we actually put the
device in D3. After some experimentation last week, we discovered we
need
2013/8/30 Jani Nikula :
> SWSCI is a driver to bios call interface.
>
> This checks for SWSCI availability and bios requested callbacks, and
> filters out any calls that shouldn't happen. This way the callers don't
> need to do the checks all over the place.
>
> v2: silence some checkpatch nagging
On Fri, Aug 23, 2013 at 07:51:28PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> We shouldn't disable the trickle feed bits on Haswell. Our
> documentation explicitly says the trickle feed bits of PRI_CTL and
> CUR_CTL should not be programmed to 1, and the hardware engineer also
> asked us
In preparation for followup work.
Signed-off-by: Jani Nikula
Reviewed-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915
The bios interface seems messy, and it's hard to tell what the bios
really wants. At first, only add support for DDI based machines (hsw+),
and see how it turns out.
The spec says to notify prior to power down and after power up. It is
unclear whether it makes a difference.
v2:
- squash notifica
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and
filters out any calls that shouldn't happen. This way the callers don't
need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set PCI_SWSCI bit 0 to trigger
The spec says to notify prior to power down and after power up. It is
unclear whether it makes a difference.
Signed-off-by: Jani Nikula
Reviewed-by: Paulo Zanoni
---
Paulo, still okay with the r-b?
---
drivers/gpu/drm/i915/intel_display.c |8 ++--
1 file changed, 6 insertions(+), 2 de
v2:
- go to PCI_D3cold
- shuffle the call site a bit
Signed-off-by: Jani Nikula
---
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 83d853f..e33fa6d 100644
--- a/dri
Hi all, a new version of [1] addressing Paulo's review comments. I hope
I didn't rush the changes too much; the new info about requested
vs. supported callbacks is confusing to say the least...
I'm sure Daniel will appreciate any Tested-by's!
BR,
Jani.
[1] http://mid.gmane.org/cover.1377246881
Notifying the bios lets it enter power saving states.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers/gpu/drm/i915/intel_opregion.c | 27 +++
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/d
One needs to call __sg_free_table() if __sg_alloc_table() fails, but
sg_alloc_table() does that for us already.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
i
On Fri, Aug 30, 2013 at 03:39:26PM +0100, Damien Lespiau wrote:
> One needs to call __sg_free_table() if __sg_alloc_table() fails, but
> sg_alloc_table() does that for us already.
>
> Signed-off-by: Damien Lespiau
Reviewd-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Ce
On Mon, Aug 26, 2013 at 07:50:55PM -0300, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> As we attempt to kmalloc after calling get_pages, there is a possibility
> that the shrinker may reap the pages we just acquired. To prevent this
> we need to increment the pages_pin_count early, so rearrange t
On Mon, Aug 26, 2013 at 07:50:54PM -0300, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> The comments were a little out-of-sequence with the code, forcing the
> reader to jump around whilst reading. Whilst moving the comments around,
> add one to explain the context reference.
>
> Signed-off-by: C
On Mon, Aug 26, 2013 at 07:50:53PM -0300, Rodrigo Vivi wrote:
> From: Chris Wilson
>
> We use the request to ensure we hold a reference to the context for the
> duration that it remains in use by the ring. Each request only holds a
> reference to the current context, hence we emit a request after
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 403309c..e038513 100644
--- a/drivers/gpu/drm/i915/i915_gem_contex
Score and action reveal what the rings were doing
when hang was declared.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 22 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i9
Now when we have mechanism in place to track which context
was guilty of hanging the gpu, it is possible to punish
for bad behaviour.
If context has recently submitted a faulty batchbuffers guilty of
gpu hang and submits another batch which hangs gpu in quick
succession, ban it permanently. If ctx
On Wed, Aug 28, 2013 at 09:39:08AM -0600, Alex Williamson wrote:
> This is intended to add VGA arbiter support for Intel HD graphics on
> Core processors. The old GMCH registers no longer exist, so even
> though it appears that i915 participates in VGA arbitration, it doesn't
> work. On Intel HD
On Thu, Aug 15, 2013 at 04:37:47PM -0600, Alex Williamson wrote:
> I'm trying to add support for VGA arbitration on newer Intel graphics
> devices. The existing code attempts to do this, but appear to have
> not been updated since GMCH devices roamed the Earth. On newer
> devices like Haswell, we
From: Ville Syrjälä
We may want to know what kind of watermarks got computed and programmed
into the hardware. Using tracepoints is much leaner than debug prints.
Also add trace call for the watermark state we read out of the
hardware during init, though I;m not sure there's any way to see that
From: Ville Syrjälä
We want to be able to use the masks to decode the register contents
regardless of the hardware generation. So just expand the masks to
cover all available bits, even if those are reserved on some
generations.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h
From: Ville Syrjälä
Fill out the HSW watermark s/w tracking structures with the current
hardware state in intel_modeset_setup_hw_state(). This allows us to skip
the HW state readback during watermark programming and just use the values
we keep around in dev_priv->wm. Reduces the overhead of the w
From: Ville Syrjälä
This debug print just adds overhead to the watermark merging process,
and doesn't really give enough information to be useful. Just kill
and let's add something much better a bit later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 --
1 file changed,
From: Ville Syrjälä
Currently hsw_write_vm_values() may write to certain watermark
registers needlessly. For instance it will disable LP1+ watermarks
around WM_PIPE changes even though that's not needed. Also if only,
say, LP3 changes, the current code will again disable all LP1+
watermarks even
From: Ville Syrjälä
To make it easier to check what watermark updates are actually
necessary, keep copies of the relevant bits that match the current
hardware state.
Also add DDB partitioning into hsw_wm_values as that's another piece
of state we want to track.
We don't read out the hardware st
From: Ville Syrjälä
When there are zero active pipes, all the watermarks should be zero
also. No point in wasting time w/ computing the 5/6 split watermark
config.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Ville Syrjälä
I want to convert hsw_find_best_result() to use intel_pipe_wm, so we
need to move the merging to happen outside hsw_compute_wm_results().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions
From: Ville Syrjälä
The fbc_wm_enabled member in intel_wm_config is useless for the time
being. The original idea for it was that we'd pre-compute it and so
that the WM merging process could know whether it needs to worry
about FBC watermarks at all.
But we don't have a convenient way to pre-che
From: Ville Syrjälä
On HSW the LP1,LP2,LP3 levels are either 1,2,3 or 1,3,4. We make the
conversion from LPn to to the level at one point current. Later we're
going to do it in a few places, so move it to a separate function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8
From: Ville Syrjälä
Move the watermark max computations into haswell_update_wm(). This
allows keeping the 1/2 vs. 5/6 split code in one place, and avoid having
to pass around so many things. We also save a bit of stack space by only
requiring one copy of struct hsw_wm_maximums.
Also move the int
From: Ville Syrjälä
Let's try to keep using the intermediate intel_pipe_wm representation
for as long as possible. It avoids subtle knowledge about the
internals of the hardware registers when trying to choose the
best watermark configuration.
While at it replace the memset() w/ zero initializat
From: Ville Syrjälä
No point in re-computing the watermarks for all pipes, when only one
pipe has changed. The watermarks stored under intel_crtc.wm.active are
still valid for the other pipes. We just need to redo the merging.
We can also skip the merge/update procedure completely if the new
wat
From: Ville Syrjälä
Introduce a new struct intel_pipe_wm which contains all the
watermarks for a single pipe. Use it to unify the LP0 and LP1+
watermark computations so that we can just iterate through the
watermark levels neatly and call ilk_compute_wm_level() for each.
Also add another tool il
From: Ville Syrjälä
Pull the expected max WM level determinations out to a separate
function. Will have another user soon.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i
From: Ville Syrjälä
Unify the code a bit to use ilk_compute_wm_level for all watermark
levels.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 44 -
1 file changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
From: Ville Syrjälä
hsw_pipe_wm_parameters and hsw_wm_maximums typically are read only. Make
them const.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b
From: Ville Syrjälä
Make the call to intel_update_watermarks() just once or twice during
modeset. Ideally it should happen independently when each plane gets
enabled/disabled, but for now it seems better to keep it in central
place. We can improve things when we get all the planes sorted out
in a
From: Ville Syrjälä
Passing the appropriate crtc to intel_update_watermarks() should help
in avoiding needless work in the future.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 20 -
drivers/gpu/drm/i915/in
Another big set of prep work to get the watermarks ready for the atomic
age.
The main themes here are some new structures to allow us to eventually
pre-compute the watermarks and trying to reduce the overhead of the
watermark update itself.
My plan has been to attempt to update the watermarks fro
Summary
We covered the platform: Haswell mobile, HSW desktop, HSW ULT, IvyBridge,
SandyBridge, IronLake. in this circle, 5 new bugs are filed, 31 bugs are still
opened, 1 WONTFIX bugs, 1 NOTABUG bugs,2 NOTOURBUG bugs, 0 Duplicated bugs,1
REOPENED bugs, 3 bugs are fixed, 13 bugs are closed.
Te
[Okay, I missed Daniel's review, and noticed I hadn't actually hit send
on this one either... but here goes anyway...]
On Fri, 30 Aug 2013, Chon Ming Lee wrote:
> For DP pll settings, there is only two golden configs. Instead of running
> through the algorithm to determine it, hardcode the valu
On Fri, 30 Aug 2013, Chon Ming Lee wrote:
> eDP 1.4 supports 4-5 extra link rates in additional to current 2 link
> rate. Create a structure to store the DPLL divisor data to improve
> readability.
DP 1.2 already supports 3 link rates, right?
> Signed-off-by: Chon Ming Lee
> ---
> drivers/gpu
On Sat, Aug 31, 2013 at 01:57:44AM +0800, Chon Ming Lee wrote:
> eDP 1.4 supports 4-5 extra link rates in additional to current 2 link
> rate. Create a structure to store the DPLL divisor data to improve
> readability.
>
> Signed-off-by: Chon Ming Lee
This is a neat idea and I agree it'll be mu
Hi Daniel and Mukesh,
This patch is submitted on behalf of Arora Mukesh. Please have a review.
And the 2nd version of patch is also submitted with subject: [PATCH v2]
drm/i915/hsw: Add display Audio codec disable sequence for Haswell. Please also
have a review.
http://lists.freedesktop.org/arch
75 matches
Mail list logo
