Accomplish this be removing the PDE count define which is (and has
always been) part of the PPGTT structure anyway. With the addition of
the gen specific init function, we can nicely tuck away the magic number
in there.
In this vain, make the PTE define less of a magic number.
The remaining code
Because PPGTT PDEs within the GTT are calculated in cachelines
(HW guys consistency ftw) we do a divide which will wreak havoc if this
is wrong, and I know that from experience).
If/when we move to multiple PPGTTs this will have to become a WARN, and
return an error. For now however it should
First, I have not finished implementing PPGTT. These are all the patches
I have which I can dump now and not have serious regression risk (and I
think most of them are tolerable on their own). The point is to get
review, make my plans explicit, and get these patches merged.
The main
Because our context refcounting doesn't grab a ref at lookup time, it is
unsafe to do so without the lock.
NOTE: We don't have an easy way to put the assertion in the lookup
function which is where this really belongs. Context switching is good
enough because it actually asserts even more
It also makes some sense IMO to have these two functions separate
irrespective of the number of callers.
Only the single caller for now, but that will change as we add more
PPGTTs.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 22 +++---
From: Chris Wilson ch...@chris-wilson.co.uk
Clients like i915 needs to segregate cache domains within the GTT which
can lead to small amounts of fragmentation. By allocating the uncached
buffers from the bottom and the cacheable buffers from the top, we can
reduce the amount of wasted space and
The resulting code isn't a huge improvement, but that will change in the
next patch (at least a bit).
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gem.c | 29 ++---
Scary alert.
AFAICT, we simply do not need the guard page if we have the PDEs at the
top since all prefetching is CS related, and it should always be safe to
prefetch into a PDE (provided the PDE is valid). The PDE fetching itself
should not be subject to the prefetching problem, though without
Make resets optional for fini. fini is only ever called in
module_unload. It was therefore a good assumption that the GPU reset
(see the comment in the function) was what we wanted. With an upcoming
patch, we're going to add a few more callsites, one of which is GPU
reset, where doing the extra
The aliasing ppgtt is just the ppgtt for the default context.
The obvious downside is until we actually do ppgtt switches, this wastes
a bit of memory. ie. by the end of the series, it's a don't care. The
other downside is PPGTT can't work without contexts, which *should* have
already been the
Going forward, every context will have its own address space. So rip off
the band aid now. If contexts fail, don't do ppgtt, and vice versa.
Similarly to the last patch, this is somewhat wasteful of PPGTT address
space with contexts, since we're not actually utilizing the new PPGTT.
Context init should have only been called once, ever. The code was
hackish because it predated some of the init cleanups. This patch
refactors the code to leave the part which must be run more than once
(reset, and thaw) as a distinct function.
I need this for some of my future plans to more
On the series,
Reviewed-by: Jani Nikula jani.nik...@intel.com
On Tue, 23 Apr 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
On VLV, the Punit doesn't automatically drop the GPU to it's minimum
voltage level when entering RC6, so we arm a timer to do it for us from
the RPS interrupt
Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell mobile
C3 stepping board.
Signed-off-by: Wang
Hi Guys,
Sorry I should Add Takashi and alsa maillist in loop.
I tested this patch against Daniel's drm-intel-next-queued Branch, on Haswell
Mobile C3 stepping machines.
Test steps:
1. only connect one monitor through HDMI cable
2. echo 1 /sys/module/i915/parameters/disable_power_well == I
On Tue, Apr 23, 2013 at 05:33:02PM -0700, Ben Widawsky wrote:
This reverts commit fec46b5eff854df5647a9f4724e45dd33933855a.
The latest version of our PM programming doc (which is WAY better than
previous versions, and thanks for that) says something along the lines
of, On Haswell
On Tue, Apr 23, 2013 at 10:09:27AM -0700, Jesse Barnes wrote:
Ville noticed this while doing another review; we may as well cancel
this work just to make sure we don't try anything fancy after disabling
the RPS interfaces.
Reported-by: Ville Syrjälä ville.syrj...@linux.intel.com
On Wed, Apr 24, 2013 at 09:57:42AM +0300, Jani Nikula wrote:
On the series,
Reviewed-by: Jani Nikula jani.nik...@intel.com
All merged to dinq, thanks.
-Daniel
On Tue, 23 Apr 2013, Jesse Barnes jbar...@virtuousgeek.org wrote:
On VLV, the Punit doesn't automatically drop the GPU to it's
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.
Finally add a WARN_ON to ensure we obey that piece of ordering
constraint.
On Tue, Apr 23, 2013 at 03:46:41PM -0700, Jesse Barnes wrote:
From: Zou Nanhai nanhai@intel.com
Needed on SNB to avoid some RC6 related hangs.
IIRC, the wa was not for a hang, but for render corruption.
v2: remove unneeded defines (Ken)
v3: update to agp-less driver (Jesse)
fixup
On Wed, Apr 24, 2013 at 11:19:20AM +0200, Daniel Vetter wrote:
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.
Finally
On Wed, Apr 24, 2013 at 10:35:16AM +0100, Chris Wilson wrote:
On Wed, Apr 24, 2013 at 11:19:20AM +0200, Daniel Vetter wrote:
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps
On Tue, Apr 23, 2013 at 11:15:28PM -0700, Ben Widawsky wrote:
x11perf -aa10text
before: 1925000/s
after: 1941667/s (clearly not a good test)
What are you running that is that slow? Implementing ppgtt on 830g?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
On Tue, Apr 23, 2013 at 11:15:37PM -0700, Ben Widawsky wrote:
- i915_gem_context_init(dev);
+ if (!dev_priv-hw_contexts_disabled
+ i915_gem_context_enable(dev_priv)) {
Move the hw_contexts_disabled test into i915_gem_context_enable(), just
makes this bit of code cleaner and
On Tue, Apr 23, 2013 at 11:15:40PM -0700, Ben Widawsky wrote:
Going forward, every context will have its own address space. So rip off
the band aid now. If contexts fail, don't do ppgtt, and vice versa.
Similarly to the last patch, this is somewhat wasteful of PPGTT address
space with
On Wed, 24 Apr 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.
Finally
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.
Finally add a WARN_ON to ensure we obey that piece of ordering
constraint.
On Wed, 24 Apr 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.
Finally
On Wed, Apr 24, 2013 at 12:27:59AM +0200, Daniel Vetter wrote:
On Tue, Apr 23, 2013 at 10:39:35PM +0200, Daniel Vetter wrote:
On Tue, Apr 23, 2013 at 06:27:54PM +0300, Ville Syrjälä wrote:
The g4x docs are a bit confusing though. They seem to indicate the the
PIPECONF dither controls only
On Wed, Apr 24, 2013 at 12:30:14AM +0200, Daniel Vetter wrote:
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the
On Fri, Apr 19, 2013 at 11:24:39AM +0200, Daniel Vetter wrote:
The LPT PCH only supports 8bpc, so we need to force the pipe bpp
to the right value.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
On Fri, Apr 19, 2013 at 11:24:42AM +0200, Daniel Vetter wrote:
And also move the computed m_n values into the pipe_config. This is a
prep step to move the fdi state computation completely into the
prepare phase of the modeset sequence. Which will allow us to handle
fdi link bw constraints in a
On Wed, Apr 24, 2013 at 02:23:20PM +0300, Ville Syrjälä wrote:
On Fri, Apr 19, 2013 at 11:24:41AM +0200, Daniel Vetter wrote:
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 20 ++--
1 file changed, 18 insertions(+), 2
On Wed, Apr 24, 2013 at 02:12:55PM +0300, Ville Syrjälä wrote:
On Fri, Apr 19, 2013 at 11:24:39AM +0200, Daniel Vetter wrote:
The LPT PCH only supports 8bpc, so we need to force the pipe bpp
to the right value.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Ville
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.
Note that compared to
On Wed, Apr 24, 2013 at 02:57:17PM +0200, Daniel Vetter wrote:
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the
v2: Introduce some nice #defines for the FDI lane width fields and put
them to good use. Suggested by Ville.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_reg.h | 11 +++
If we ever leak a non-DP compliant port width through here, we have a
pretty serious issue. So just rip out all these WARNs - if we need
them it's probably better to have them at a central place where we
compute the dp lane count.
Also use the new DDI width macro for FDI mode.
Cc: Paulo Zanoni
On Wed, Apr 24, 2013 at 03:46:04PM +0200, Daniel Vetter wrote:
If we ever leak a non-DP compliant port width through here, we have a
pretty serious issue. So just rip out all these WARNs - if we need
them it's probably better to have them at a central place where we
compute the dp lane count.
On Wed, Apr 24, 2013 at 02:52:52PM +0100, Chris Wilson wrote:
On Wed, Apr 24, 2013 at 03:46:04PM +0200, Daniel Vetter wrote:
If we ever leak a non-DP compliant port width through here, we have a
pretty serious issue. So just rip out all these WARNs - if we need
them it's probably better to
Jesse Barnes jbar...@virtuousgeek.org writes:
This gets the panel fitter working on eDP on VLV, and should also apply
to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one
panel as eDP anyway).
A few cleanups are still possible on top of this, for example the LVDS
border
Ben Widawsky b...@bwidawsk.net writes:
Make resets optional for fini. fini is only ever called in
module_unload. It was therefore a good assumption that the GPU reset
(see the comment in the function) was what we wanted. With an upcoming
patch, we're going to add a few more callsites, one of
On Wed, 24 Apr 2013 18:05:54 +0300
Mika Kuoppala mika.kuopp...@linux.intel.com wrote:
This is different than it was in lvds_compute_config. If we get called
with DRM_MODE_SCALE_NONE we go to fullscreen instead.
Is this intentional?
Yeah, figured I'd make it identical to the eDP case. But we
From: Ville Syrjälä ville.syrj...@linux.intel.com
struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
From: Ville Syrjälä ville.syrj...@linux.intel.com
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel
From: Ville Syrjälä ville.syrj...@linux.intel.com
These functions calculate the scaling factor based on the source and
destination rectangles.
There are two version of the functions, the strict ones that will
return an error if the min/max scaling factor is exceeded, and the
relaxed versions
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_rect_equals() tells whether two drm_rects are equal.
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
include/drm/drm_rect.h | 15 +++
1 file changed, 15
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a debug function to print the rectangle in a human readable format.
v2: Renamed drm_region to drm_rect, the function from drm_region_debug
to drm_rect_debug_print(), and use %+d instead of +%d in the format.
v3: Use %d format for
From: Ville Syrjälä ville.syrj...@linux.intel.com
Reduce the size of the the src/dst viewport to keep the scalign ratios
in check.
v2: Below min size sprite handling squashed to previous patch
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Ville Syrjälä
Here's the latest version of my plane clipping stuff.
I think it should be ready for merging. Laurent reviewed the first patch,
and Chris reviewed the whole set.
I didn't hear any bikeshedding about the location of the drm_rect
stuff from anyone, so I'm assuming it's all good.
Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
No need to zero initialize .vrefresh in DRM_MODE() since it's using
desgignated initializers.
This will also avoid some duplicate initialization warnings later.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_mode_equal_no_clocks() is like drm_mode_equal() except it doesn't
compare the clock or vrefresh values. drm_mode_equal() is now
implemented by first doing the clock checks, and then calling
drm_mode_equal_no_clocks().
v2: Add missing
The same old CEA mode 60 Hz vs. 59.94 Hz handling series.
While reviewing v1, Paulo noticed a missing EXPORT_SYMBOL(),
which is now fixed. Everything else is unchanged.
From my POV this is ready to go in. The only real questions is
whether or not we want to populate the connector's mode list
From: Ville Syrjälä ville.syrj...@linux.intel.com
Well have use for the vrefresh information of CEA modes later. Just
populate the information into the table to avoid having to calculate
it.
I'm too lazy to check if someone relies on newly allocated CEA
modes having 0 vrefresh, so just clear
From: Ville Syrjälä ville.syrj...@linux.intel.com
drm_match_cea_mode() should be able to match both the 60Hz version,
and the 59.94Hz version of modes.
We only store one pixel clock value per mode in edid_cea_modes, so the
other value must be calculated. Depending on the mode, edid_cea_modes
On Wed, Apr 24, 2013 at 11:06:12AM +0100, Chris Wilson wrote:
On Tue, Apr 23, 2013 at 11:15:40PM -0700, Ben Widawsky wrote:
Going forward, every context will have its own address space. So rip off
the band aid now. If contexts fail, don't do ppgtt, and vice versa.
Similarly to the last
On Wed, Apr 24, 2013 at 11:04:40AM +0100, Chris Wilson wrote:
On Tue, Apr 23, 2013 at 11:15:37PM -0700, Ben Widawsky wrote:
- i915_gem_context_init(dev);
+ if (!dev_priv-hw_contexts_disabled
+ i915_gem_context_enable(dev_priv)) {
Move the hw_contexts_disabled test into
On Tue, Apr 23, 2013 at 05:55:04PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for IVB,
without enabling it by default.
It adds a new function gen7_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_IVYBRIDGE checks.
v2: Fixes from
On Wed, Apr 24, 2013 at 08:29:21AM -0700, Jesse Barnes wrote:
On Wed, 24 Apr 2013 18:05:54 +0300
Mika Kuoppala mika.kuopp...@linux.intel.com wrote:
This is different than it was in lvds_compute_config. If we get called
with DRM_MODE_SCALE_NONE we go to fullscreen instead.
Is this
On Tue, Apr 23, 2013 at 02:52:17PM -0300, Rodrigo Vivi wrote:
Display register 42000h bit 22 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
On Mon, Apr 22, 2013 at 02:39:59PM +0100, Damien Lespiau wrote:
Those registers are not used, let's not keep them around for no reason.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Generally if they're not wrong I don't mind some auxialiary register
#defines hanging about. So I'll
On Tue, Apr 23, 2013 at 02:52:18PM -0300, Rodrigo Vivi wrote:
Display register 42020h bit 9 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_pm.c | 8
1 file changed,
On Tue, Apr 23, 2013 at 02:52:19PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for HSW.
FBC is tied to primary plane A in HSW.
The docs say FBC must be disabled before disabling the plane on HSW.
We're doing these steps in the opposite order on ILK+.
On Tue, Apr 23, 2013 at 02:52:20PM -0300, Rodrigo Vivi wrote:
Display register 420B0h bit 22 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
On Tue, Apr 23, 2013 at 02:52:21PM -0300, Rodrigo Vivi wrote:
Display register 46500h bit 23 must be set to 1b for the entire time that
Frame Buffer Compression is enabled.
v2: Ville suggested to enable it back when disabling fbc to avoid wasting
power.
Cc: Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the calculated FBC watermark is no good, we simply disable FBC
watermarks. But we fail to re-enable them later if the calculated
watermark becomes good again. Fix that, but remember to leave FBC
watermarks disabled on ILK since that's required
From: Ville Syrjälä ville.syrj...@linux.intel.com
If the calculated FBC watermark is no good, we simply disable FBC
watermarks. But we fail to re-enable them later if the calculated
watermark becomes good again. Fix that, but remember to leave FBC
watermarks disabled on ILK since that's required
On Fri, Apr 12, 2013 at 03:20:58PM +0300, Jani Nikula wrote:
With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |1 -
On Fri, Apr 12, 2013 at 03:20:55PM +0300, Jani Nikula wrote:
There's still stuff to do on opregion cleanup, but here are some potentially
risky and/or controversial ones...
With the small fix on patch 3, the whole series is:
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
This should
With the previous work asle and gse interrupt handlers should now be
functionally the same. Drop the duplicated code.
v2: Drop intel_opregion_gse_intr() also in the !CONFIG_ACPI path. (Damien)
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 --
This was supposed to be in-reply-to [1] but I screwed up.
Jani.
[1] http://mid.gmane.org/20130424182351.gb3...@strange.amr.corp.intel.com
On Wed, 24 Apr 2013, Jani Nikula jani.nik...@intel.com wrote:
With the previous work asle and gse interrupt handlers should now be
functionally the same.
On Tue, Apr 23, 2013 at 11:15:28PM -0700, Ben Widawsky wrote:
I haven't run performance numbers on this series specifically, but I did
run performance numbers on the slightly more invasive patches which come
after (through step 1 above)
x11perf -aa10text
before: 1925000/s
after: 1941667/s
On Thu, Apr 04, 2013 at 06:32:32PM +0300, Mika Kuoppala wrote:
Hi,
I have addressed all the feedback I got from v2 series.
Most notably the interface has changed.
Now those users who don't care about the exact counts can use batch_pending
and batch_active like they would be flags (see
Hi Daniel/Paulo,
Any comments on this?
Add Jesse and Rafael in loop.
thanks
--xingchao
-Original Message-
From: Wang, Xingchao
Sent: Wednesday, April 24, 2013 3:29 PM
To: daniel.vet...@ffwll.ch; Zanoni, Paulo R; 'Takashi Iwai'
Cc: ville.syrj...@linux.intel.com; Lin, Mengdong;
74 matches
Mail list logo
