diff mbox

[3/3] drm/i915: Drop the 64k linear scanout alignment on gen2/3

Message ID 1434029476-958-3-git-send-email-ville.syrjala@linux.intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Ville Syrjala June 11, 2015, 1:31 p.m. UTC 
From: Ville Syrjälä <ville.syrjala@linux.intel.com>

The docs don't support the 64k linear scanout alignment we impose
on gen2/3. And it really makes no sense since we have no DSPSURF
register, so the only thing that the hardware will see is the linear
offset which will be just pixel aligned anyway.

There is one case where 64k comes into the picture, and that's FBC.
The start of the line length buffer corresponds to a 64k aligned
address of the uncompressed framebuffer. So if the uncompressed fb is
not 64k aligned, the first actually used entry in the line length
buffer will not be byte 0. There are 32 extra entries in the line
length buffer to account for this extra alignment so we shouldn't
have to worry about it when mapping the uncompressed fb to the GTT.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Chris Wilson June 11, 2015, 1:52 p.m. UTC | #1 
On Thu, Jun 11, 2015 at 04:31:16PM +0300, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The docs don't support the 64k linear scanout alignment we impose
> on gen2/3. And it really makes no sense since we have no DSPSURF
> register, so the only thing that the hardware will see is the linear
> offset which will be just pixel aligned anyway.
> 
> There is one case where 64k comes into the picture, and that's FBC.
> The start of the line length buffer corresponds to a 64k aligned
> address of the uncompressed framebuffer. So if the uncompressed fb is
> not 64k aligned, the first actually used entry in the line length
> buffer will not be byte 0. There are 32 extra entries in the line
> length buffer to account for this extra alignment so we shouldn't
> have to worry about it when mapping the uncompressed fb to the GTT.
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

I could not find any rationale either, and it worked this way ~10 years
ago, so
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
Shuang He June 14, 2015, 11:18 p.m. UTC | #2 
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6570
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
PNV                                  276/276              276/276
ILK                                  303/303              303/303
SNB                                  312/312              312/312
IVB                                  343/343              343/343
BYT                                  287/287              287/287
BDW                                  321/321              321/321
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
Note: You need to pay more attention to line start with '*'
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 2221323..b48c237 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2335,7 +2335,7 @@  static unsigned int intel_linear_alignment(struct drm_i915_private *dev_priv)
 	else if (INTEL_INFO(dev_priv)->gen >= 4)
 		return 4 * 1024;
 	else
-		return 64 * 1024;
+		return 0;
 }
 
 int