From: Mukesh mukeshx.ar...@intel.com
The code implements hsw_hdmi_audio_disable func which sets the
relevant registers for disabling the audio codec in a call to
intel_disable_ddi func.This audio codec disbale sequence is
implemented as per the recommendation of the Bspec.
Change-Id:
From: Mukesh mukeshx.ar...@intel.com
The code defines a new function intel_disable_audio() to implement the
entire audio codec disable sequence, called by intel_disable_ddi() in
DDI port disablement. This audio codec disbale sequence is implemented
as per the recommendation of the Bspec.
[Patch
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.
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 chon.ming@intel.com
This is a neat idea and
On Fri, 30 Aug 2013, Chon Ming Lee chon.ming@intel.com 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
[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 chon.ming@intel.com wrote:
For DP pll settings, there is only two golden configs. Instead of running
through the algorithm to determine
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.
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
Passing the appropriate crtc to intel_update_watermarks() should help
in avoiding needless work in the future.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
hsw_pipe_wm_parameters and hsw_wm_maximums typically are read only. Make
them const.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 20 ++--
1 file changed, 10 insertions(+), 10
From: Ville Syrjälä ville.syrj...@linux.intel.com
Unify the code a bit to use ilk_compute_wm_level for all watermark
levels.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 44 -
1 file changed, 21
From: Ville Syrjälä ville.syrj...@linux.intel.com
Pull the expected max WM level determinations out to a separate
function. Will have another user soon.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 19 +++
1 file changed, 11
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 19
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä ville.syrj...@linux.intel.com
From: Ville Syrjälä ville.syrj...@linux.intel.com
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.
From: Ville Syrjälä ville.syrj...@linux.intel.com
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ä
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
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
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
Score and action reveal what the rings were doing
when hang was declared.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 22 ++
2 files changed, 24 insertions(+)
diff --git
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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
---
On Mon, Aug 26, 2013 at 07:50:53PM -0300, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
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
On Mon, Aug 26, 2013 at 07:50:55PM -0300, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
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
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 damien.lesp...@intel.com
Reviewd-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris
--
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 damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
Notifying the bios lets it enter power saving states.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers/gpu/drm/i915/intel_opregion.c | 27 +++
2 files changed, 34 insertions(+)
diff --git
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 jani.nik...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
Paulo, still okay with the r-b?
---
drivers/gpu/drm/i915/intel_display.c |8
v2:
- go to PCI_D3cold
- shuffle the call site a bit
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
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
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]
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 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
In preparation for followup work.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
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
On Fri, Aug 23, 2013 at 07:51:28PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
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
2013/8/30 Jani Nikula jani.nik...@intel.com:
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
2013/8/30 Jani Nikula jani.nik...@intel.com:
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
2013/8/30 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Passing the appropriate crtc to intel_update_watermarks() should help
in avoiding needless work in the future.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
I like the fact that now
2013/8/30 Jani Nikula jani.nik...@intel.com:
Notifying the bios lets it enter power saving states.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |7 +++
2013/8/30 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
2013/8/30 Jani Nikula jani.nik...@intel.com:
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 jani.nik...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
Paulo, still okay with the r-b?
On Fri, Aug 30, 2013 at 05:09:49PM -0300, Paulo Zanoni wrote:
2013/8/30 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Passing the appropriate crtc to intel_update_watermarks() should help
in avoiding needless work in the future.
Signed-off-by: Ville
2013/8/30 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
hsw_pipe_wm_parameters and hsw_wm_maximums typically are read only. Make
them const.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: GCC 4.7.3
Reviewed-by: Paulo Zanoni
On Fri, Aug 30, 2013 at 05:26:29PM -0300, Paulo Zanoni wrote:
2013/8/30 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Make the call to intel_update_watermarks() just once or twice during
modeset. Ideally it should happen independently when each plane
2013/8/30 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Unify the code a bit to use ilk_compute_wm_level for all watermark
levels.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Looks correct and doesn't change the WM values set on my specific
2013/8/30 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Pull the expected max WM level determinations out to a separate
function. Will have another user soon.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Paulo Zanoni
On Fri, Aug 30, 2013 at 02:40:26PM +0100, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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
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
As we'll see in the next patch, being able to evict for just 1 VM is
handy.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_evict.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git
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
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
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 b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_evict.c | 4 ++--
drivers/gpu/drm/i915/i915_trace.h | 12 ++--
2 files changed, 8
From: Ben Widawsky b...@bwidawsk.net
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:
From: Ben Widawsky b...@bwidawsk.net
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
From: Ben Widawsky b...@bwidawsk.net
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
From: Ben Widawsky b...@bwidawsk.net
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
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.
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 b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_evict.c | 28 ++--
1 file changed, 22
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: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 in
On Fri, Aug 30, 2013 at 04:43:58PM -0700, Ben Widawsky wrote:
From: Ben Widawsky b...@bwidawsk.net
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
On Fri, Aug 30, 2013 at 04:43:59PM -0700, Ben Widawsky wrote:
From: Ben Widawsky b...@bwidawsk.net
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
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
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
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 b...@bwidawsk.net
---
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_everything for
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 b...@bwidawsk.net
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
75 matches
Mail list logo
