Re: [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote: The primary goal of these patches is to introduce what I've started calling, prelocations on Broadwell. A prelocation is like a relocation, except not. When a GPU client specifies a prelocation, it is instructing the kernel where in the GPU address the buffer should be mapped. The mechanic works very similarly to a relocation except it uses the execbuffer object to obtain the offset, and bind if needed. You are mixing two APIs. One to preallocate an offset at creation and one to presume relocations during execbuffer. I'd much rather keep the flexible execbuffer approach outlined and first submitted a couple of years ago. If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, Close to zero if the client uses existing interfaces. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION BISECTED] backlight control stops workin with 3.14 and later
On Fri, 22 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On 19-8-2014 3:29, Jani Nikula wrote: On Tue, 19 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On Sun, 17 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On 15-8-2014 3:43, Jani Nikula wrote: On Thu, 14 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: Attached is dmesg output from booting kernel 3.14-2 (debian unstable) with drm.debug=0xe and the samsung_laptop module enabled, from my Samsung N150plus netbook. Have you tried 3.15? I've built the v3.15 kernel (using the .config file from debian unstable and doing make oldconfig). The backlight is at maximum brightness after boot and I can't control it using the backlight buttons, nor by writing to /sys/class/backlight/samsung/brightness (say half the value or 1/10th of max_brightness) Backlight does work when writing /sys/class/backlight/intel_backlight/brightness How about disabling samsung backlight module with 3.15? I'm not sure what you mean by that. As I understand it, there are three ways to control the backlight on this netbook: using intel_backlight, samsung_laptop (using a sabi interface) and acpi_video. Backlight control using the samsung_laptop driver no longer seems to work after the change. If I disable it (e.g. by blacklisting it), I expect it to no longer work at all obviously. What do you want me to test exactly? If the intel_backlight interface works in 3.15, I presume the problem is that you have a non-functional samsung backlight interface that is preferred over intel_backlight by your userspace. I tested the intel_backlight interface in linux v3.15 with the samsung backlight module blacklisted. The intel_backlight interface still works. I read that as, I no longer have problems with backlight. Jani. Regards, Bertrik -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Friday, August 22, 2014 07:30:37 AM Chris Wilson wrote: On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote: The primary goal of these patches is to introduce what I've started calling, prelocations on Broadwell. A prelocation is like a relocation, except not. When a GPU client specifies a prelocation, it is instructing the kernel where in the GPU address the buffer should be mapped. The mechanic works very similarly to a relocation except it uses the execbuffer object to obtain the offset, and bind if needed. You are mixing two APIs. One to preallocate an offset at creation and one to presume relocations during execbuffer. I'd much rather keep the flexible execbuffer approach outlined and first submitted a couple of years ago. If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, Close to zero if the client uses existing interfaces. -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver. It wasn't invasive at all---I was surprised. With both the CPU and GPU using 48-bit addressing, using the same virtual address on both sides and never changing it seems quite appealing. I'm not sure why we would need to do anything different than that. As I understand it, we still need to let the kernel know what buffers we need pinned during the course of the batchbuffer, since we can't take a page fault and fetch them as needed. Reusing the existing relocation list but just not doing relocations seems like a simple way to do that without having to invent much new API... What is the 'flexible execbuffer' approach you mention from a few years back? I don't remember hearing about it (sorry)... --Ken signature.asc Description: This is a digitally signed message part. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add 180 degree primary plane rotation support
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc-fb is changed to
crtc-primary-fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to
drm_mode_config, so drm layer will take care of resetting. Adding updation of
fbc when rotation is set to 0. Allowing rotation only if value is
different than old one.
v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
set_property(Daniel).
v11: Using same set_property function for both primary and sprite, Adding
primary plane specific code in the same function (Matt).
v12: Removing disabling/ enabling of fbc from set_property because it is done
from intel_pipe_set_base. Other formatting (Ville).
Testcase: igt/kms_rotation_crc
Signed-off-by: Uma Shankar uma.shan...@intel.com
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 56 +++---
drivers/gpu/drm/i915/intel_drv.h |3 ++
drivers/gpu/drm/i915/intel_pm.c |6
drivers/gpu/drm/i915/intel_sprite.c |4 +--
5 files changed, 64 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 203062e..142ac52 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4214,6 +4214,7 @@ enum punit_power_well {
#define DISPPLANE_NO_LINE_DOUBLE 0
#define DISPPLANE_STEREO_POLARITY_FIRST 0
#define DISPPLANE_STEREO_POLARITY_SECOND (118)
+#define DISPPLANE_ROTATE_180 (115)
#define DISPPLANE_TRICKLE_FEED_DISABLE (114) /* Ironlake */
#define DISPPLANE_TILED (110)
#define _DSPAADDR 0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f2a8797..241234d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2384,6 +2384,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg = DSPCNTR(plane);
+ int pixel_size;
+
+ pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
if (!intel_crtc-primary_enabled) {
I915_WRITE(reg, 0);
@@ -2450,8 +2453,6 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb-pitches[0] + x * (fb-bits_per_pixel / 8);
if (INTEL_INFO(dev)-gen = 4) {
@@ -2464,6 +2465,21 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
intel_crtc-dspaddr_offset = linear_offset;
}
+ if (to_intel_plane(crtc-primary)-rotation == BIT(DRM_ROTATE_180)) {
+ dspcntr |= DISPPLANE_ROTATE_180;
+
+ x += (intel_crtc-config.pipe_src_w - 1);
+ y += (intel_crtc-config.pipe_src_h - 1);
+
+ /* Finding the last pixel of the last line of the display
+ data and adding to linear_offset*/
+ linear_offset +=
+ (intel_crtc-config.pipe_src_h - 1) * fb-pitches[0] +
+ (intel_crtc-config.pipe_src_w - 1) * pixel_size;
+ }
+
+ I915_WRITE(reg, dspcntr);
+
DRM_DEBUG_KMS(Writing base %08lX %08lX %d %d %d\n,
i915_gem_obj_ggtt_offset(obj), linear_offset, x, y,
Re: [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Thu, Aug 21, 2014 at 11:59:04PM -0700, Kenneth Graunke wrote: On Friday, August 22, 2014 07:30:37 AM Chris Wilson wrote: On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote: The primary goal of these patches is to introduce what I've started calling, prelocations on Broadwell. A prelocation is like a relocation, except not. When a GPU client specifies a prelocation, it is instructing the kernel where in the GPU address the buffer should be mapped. The mechanic works very similarly to a relocation except it uses the execbuffer object to obtain the offset, and bind if needed. You are mixing two APIs. One to preallocate an offset at creation and one to presume relocations during execbuffer. I'd much rather keep the flexible execbuffer approach outlined and first submitted a couple of years ago. If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, Close to zero if the client uses existing interfaces. -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver. It wasn't invasive at all---I was surprised. Indeed, you could do everything inside libdrm with the code I posted 2 years ago. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: improve assert_panel_unlocked
On Thu, Aug 21, 2014 at 12:01:07PM -0300, Paulo Zanoni wrote:
2014-08-21 11:56 GMT-03:00 Ville Syrjälä ville.syrj...@linux.intel.com:
On Thu, Aug 21, 2014 at 03:06:26PM +0300, Jani Nikula wrote:
Fix assert_panel_unlocked for vlv/chv, and improve it a bit for
non-LVDS. Also don't pretend it works for DDI. There's still work to do
to get this right for eDP on PCH platforms, but this is a start.
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
So I wanted to quickly fix assert_panel_unlocked, but for such a short
piece of code it's too involved to _quickly_ get right across all
platforms. I think this is a worthwhile improvement though.
---
drivers/gpu/drm/i915/intel_display.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe1d00dc9ef5..d6b48496d7f4 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1193,17 +1193,33 @@ void assert_fdi_rx_pll(struct drm_i915_private
*dev_priv,
static void assert_panel_unlocked(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
- int pp_reg, lvds_reg;
+ struct drm_device *dev = dev_priv-dev;
+ int pp_reg;
u32 val;
enum pipe panel_pipe = PIPE_A;
bool locked = true;
- if (HAS_PCH_SPLIT(dev_priv-dev)) {
+ if (HAS_DDI(dev)) {
+ /* XXX: this neither works nor gets called for DDI */
Not sure why the XXX here. Seems to me there's nothing to fix here for
DDI. Maybe just make that a WARN_ON(HAS_DDI()) or just remove the check
entirely.
As far as I remember, the abcd stuff is not even used/needed on DDI.
But this is just what my memory tells me, it may be wrong. Someone
needs to double-check.
Bspec just says spare for those bits.
+ return;
+ } else if (HAS_PCH_SPLIT(dev)) {
+ u32 port_sel;
+
pp_reg = PCH_PP_CONTROL;
- lvds_reg = PCH_LVDS;
+ port_sel = I915_READ(PCH_PP_ON_DELAYS)
PANEL_PORT_SELECT_MASK;
+
+ if (port_sel == PANEL_PORT_SELECT_LVDS
+ I915_READ(PCH_LVDS) LVDS_PIPEB_SELECT)
+ panel_pipe = PIPE_B;
+ /* XXX: else fix for eDP */
+ } else if (IS_VALLEYVIEW(dev)) {
+ /* presumably write lock depends on pipe, not port select */
Hmm. This is a good question. Needs a bit if testing I suppose. In the
worst case it somehow gets tied in with how the power sequencer gets locked
to the port. For that we'd probably just have to check both power sequencers
here and complain if either has the registers locked. Or maybe we should
just do that anyway because it's such a simple solution? But we could
do that simply by calling assert_panel_unlocked() twice (once for each pipe)
from VLV specific code, so this patch seems to be exactly what we need as
a first step.
Apart from the XXX in the comment:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
+ pp_reg = VLV_PIPE_PP_CONTROL(pipe);
+ panel_pipe = pipe;
} else {
pp_reg = PP_CONTROL;
- lvds_reg = LVDS;
+ if (I915_READ(LVDS) LVDS_PIPEB_SELECT)
+ panel_pipe = PIPE_B;
}
val = I915_READ(pp_reg);
@@ -1211,9 +1227,6 @@ static void assert_panel_unlocked(struct
drm_i915_private *dev_priv,
((val PANEL_UNLOCK_MASK) == PANEL_UNLOCK_REGS))
locked = false;
- if (I915_READ(lvds_reg) LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
-
WARN(panel_pipe == pipe locked,
panel assertion failure, pipe %c regs locked\n,
pipe_name(pipe));
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add 180 degree primary plane rotation support
On Fri, Aug 22, 2014 at 09:29:56AM +0530, Jindal, Sonika wrote:
On 8/21/2014 7:07 PM, Ville Syrjälä wrote:
On Thu, Aug 21, 2014 at 05:14:35PM +0530, Jindal, Sonika wrote:
On 8/21/2014 2:03 PM, Ville Syrjälä wrote:
On Thu, Aug 21, 2014 at 11:45:41AM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in
intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property
change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc-fb is changed
to
crtc-primary-fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing
reset
of rotation property from lastclose. rotation_property is moved to
drm_mode_config, so drm layer will take care of resetting. Adding
updation of
fbc when rotation is set to 0. Allowing rotation only if value is
different than old one.
v10: Calling intel_primary_plane_setplane instead of
update_primary_plane in
set_property(Daniel).
v11: Using same set_property function for both primary and sprite, Adding
primary plane specific code in the same function (Matt).
Testcase: igt/kms_rotation_crc
Signed-off-by: Uma Shankar uma.shan...@intel.com
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 57
+++---
drivers/gpu/drm/i915/intel_drv.h |3 ++
drivers/gpu/drm/i915/intel_pm.c |6
drivers/gpu/drm/i915/intel_sprite.c | 33 ++--
5 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 203062e..142ac52 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4214,6 +4214,7 @@ enum punit_power_well {
#define DISPPLANE_NO_LINE_DOUBLE0
#define DISPPLANE_STEREO_POLARITY_FIRST 0
#define DISPPLANE_STEREO_POLARITY_SECOND(118)
+#define DISPPLANE_ROTATE_180 (115)
#define DISPPLANE_TRICKLE_FEED_DISABLE (114) /* Ironlake */
#define DISPPLANE_TILED (110)
#define _DSPAADDR 0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f2a8797..22851a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2384,6 +2384,9 @@ static void i9xx_update_primary_plane(struct
drm_crtc *crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg = DSPCNTR(plane);
+int pixel_size;
+
+pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
if (!intel_crtc-primary_enabled) {
I915_WRITE(reg, 0);
@@ -2411,6 +2414,7 @@ static void i9xx_update_primary_plane(struct
drm_crtc *crtc,
(intel_crtc-config.pipe_src_w - 1));
I915_WRITE(DSPPOS(plane), 0);
}
+dspcntr = ~DISPPLANE_ROTATE_180;
No longer needed. We start building DSPCNTR from scratch.
switch (fb-pixel_format) {
case DRM_FORMAT_C8:
@@ -2450,8 +2454,6 @@ static void i9xx_update_primary_plane(struct
drm_crtc *crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
-I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb-pitches[0] + x * (fb-bits_per_pixel /
8);
if (INTEL_INFO(dev)-gen = 4) {
@@ -2464,6 +2466,21 @@ static void i9xx_update_primary_plane(struct
drm_crtc *crtc,
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add 180 degree primary plane rotation support
On 8/22/2014 1:44 PM, Ville Syrjälä wrote:
On Fri, Aug 22, 2014 at 09:29:56AM +0530, Jindal, Sonika wrote:
On 8/21/2014 7:07 PM, Ville Syrjälä wrote:
On Thu, Aug 21, 2014 at 05:14:35PM +0530, Jindal, Sonika wrote:
On 8/21/2014 2:03 PM, Ville Syrjälä wrote:
On Thu, Aug 21, 2014 at 11:45:41AM +0530, sonika.jin...@intel.com wrote:
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc-fb is changed to
crtc-primary-fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to
drm_mode_config, so drm layer will take care of resetting. Adding updation of
fbc when rotation is set to 0. Allowing rotation only if value is
different than old one.
v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
set_property(Daniel).
v11: Using same set_property function for both primary and sprite, Adding
primary plane specific code in the same function (Matt).
Testcase: igt/kms_rotation_crc
Signed-off-by: Uma Shankar uma.shan...@intel.com
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 57
+++---
drivers/gpu/drm/i915/intel_drv.h |3 ++
drivers/gpu/drm/i915/intel_pm.c |6
drivers/gpu/drm/i915/intel_sprite.c | 33 ++--
5 files changed, 94 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 203062e..142ac52 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4214,6 +4214,7 @@ enum punit_power_well {
#define DISPPLANE_NO_LINE_DOUBLE 0
#define DISPPLANE_STEREO_POLARITY_FIRST 0
#define DISPPLANE_STEREO_POLARITY_SECOND (118)
+#define DISPPLANE_ROTATE_180 (115)
#define DISPPLANE_TRICKLE_FEED_DISABLE(114) /* Ironlake */
#define DISPPLANE_TILED (110)
#define _DSPAADDR 0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f2a8797..22851a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2384,6 +2384,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg = DSPCNTR(plane);
+ int pixel_size;
+
+ pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
if (!intel_crtc-primary_enabled) {
I915_WRITE(reg, 0);
@@ -2411,6 +2414,7 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
(intel_crtc-config.pipe_src_w - 1));
I915_WRITE(DSPPOS(plane), 0);
}
+ dspcntr = ~DISPPLANE_ROTATE_180;
No longer needed. We start building DSPCNTR from scratch.
switch (fb-pixel_format) {
case DRM_FORMAT_C8:
@@ -2450,8 +2454,6 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb-pitches[0] + x * (fb-bits_per_pixel / 8);
if (INTEL_INFO(dev)-gen = 4) {
@@ -2464,6 +2466,21 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
intel_crtc-dspaddr_offset = linear_offset;
}
+ if (to_intel_plane(crtc-primary)-rotation == BIT(DRM_ROTATE_180)) {
+ dspcntr |= DISPPLANE_ROTATE_180;
+
+
[Intel-gfx] [PATCH] drm/i915: Add 180 degree primary plane rotation support
From: Sonika Jindal sonika.jin...@intel.com
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.
v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.
v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.
v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.
v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.
v8: update_plane is changed to update_primary_plane, crtc-fb is changed to
crtc-primary-fb and return value of update_primary_plane is ignored.
v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to
drm_mode_config, so drm layer will take care of resetting. Adding updation of
fbc when rotation is set to 0. Allowing rotation only if value is
different than old one.
v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
set_property(Daniel).
v11: Using same set_property function for both primary and sprite, Adding
primary plane specific code in the same function (Matt).
v12: Removing disabling/ enabling of fbc from set_property because it is done
from intel_pipe_set_base. Other formatting
v13: we need to call disable_fbc before changing the rotation to 180,
disable_fbc from intel_pipe_set_base gets called very late, that will
be used to re-enable fbc if rotation is set to 0 (Ville).
Testcase: igt/kms_rotation_crc
Signed-off-by: Uma Shankar uma.shan...@intel.com
Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 69 --
drivers/gpu/drm/i915/intel_drv.h |3 ++
drivers/gpu/drm/i915/intel_pm.c |6 +++
drivers/gpu/drm/i915/intel_sprite.c |4 +-
5 files changed, 77 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 203062e..142ac52 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4214,6 +4214,7 @@ enum punit_power_well {
#define DISPPLANE_NO_LINE_DOUBLE 0
#define DISPPLANE_STEREO_POLARITY_FIRST 0
#define DISPPLANE_STEREO_POLARITY_SECOND (118)
+#define DISPPLANE_ROTATE_180 (115)
#define DISPPLANE_TRICKLE_FEED_DISABLE (114) /* Ironlake */
#define DISPPLANE_TILED (110)
#define _DSPAADDR 0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f2a8797..0c77438 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2384,6 +2384,9 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg = DSPCNTR(plane);
+ int pixel_size;
+
+ pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
if (!intel_crtc-primary_enabled) {
I915_WRITE(reg, 0);
@@ -2450,8 +2453,6 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb-pitches[0] + x * (fb-bits_per_pixel / 8);
if (INTEL_INFO(dev)-gen = 4) {
@@ -2464,6 +2465,21 @@ static void i9xx_update_primary_plane(struct drm_crtc
*crtc,
intel_crtc-dspaddr_offset = linear_offset;
}
+ if (to_intel_plane(crtc-primary)-rotation == BIT(DRM_ROTATE_180)) {
+ dspcntr |= DISPPLANE_ROTATE_180;
+
+ x += (intel_crtc-config.pipe_src_w - 1);
+ y += (intel_crtc-config.pipe_src_h - 1);
+
+ /* Finding the last pixel of the last line of the display
+ data and adding to linear_offset*/
+ linear_offset +=
+ (intel_crtc-config.pipe_src_h - 1) * fb-pitches[0] +
+ (intel_crtc-config.pipe_src_w - 1) * pixel_size;
+ }
+
+
Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert
On Thu, Aug 21, 2014 at 10:23:43AM -0700, Clint Taylor wrote:
On 08/20/2014 04:23 AM, Ville Syrjälä wrote:
On Mon, Aug 18, 2014 at 01:48:35PM -0700, clinton.a.tay...@intel.com wrote:
From: Clint Taylor clinton.a.tay...@intel.com
Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
duty cycle take affect at the end of the current PWM cycle.
Measured time for the PWM cycle is 5ms. 5 additional ms must be
added to the backlight_on_delay to get correct VBT timing of
PWM to backlight enable assert.
V2: Rebase to Jani Nikula backlight power patch 1/4
Change-Id: I2982f9785d92e8d64c04ca25c8bd4c5d1dc8067c
Signed-off-by: Clint Taylor clinton.a.tay...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 6 --
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60..aed923b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp
*intel_dp)
static void wait_backlight_on(struct intel_dp *intel_dp)
{
- wait_remaining_ms_from_jiffies(intel_dp-last_power_on,
+ wait_remaining_ms_from_jiffies(intel_dp-last_backlight_on,
intel_dp-backlight_on_delay);
}
@@ -1418,6 +1418,7 @@ void intel_edp_backlight_on(struct intel_dp
*intel_dp)
DRM_DEBUG_KMS(\n);
intel_panel_enable_backlight(intel_dp-attached_connector);
+ intel_dp-last_backlight_on = jiffies;
Seems to me we should just have a msleep(PWM_CYCLE_DELAY) here since
(assuming I understood correctly) only the PWM cycle time is important
between these two steps, and the t8 (vbt spec says t7 actually) is
relevant only from end of link training to backlight on.
The driver has overloaded both T8 and T9 VBT timing entries. The eDP
specification really doesn't have timing data defined for this
requirement, but the panel manufacturers have it in their panel
specification and they use various names like (Te, t17, etc...) for this
delay.
Hmm, no actually your idea might be better since on VLV/CHV we turn the
pipe on after link training, and I assume t7/t8 should really start
counting from the pipe on on those platforms. So I guess the most
appropriate solution might be somehting like
{
intel_dp-last_backlight_on = jiffies;
intel_panel_enable_backlight(intel_dp-attached_connector);
msleep(POWER_CYCLE_DELAY);
_intel_edp_backlight_on(intel_dp);
}
But I'm not sure the distinction makes any difference since
intel_panel_enable_backlight() shouldn't take a significant amount of
time, and msleep() is itself rather inaccurate.
There is also a need to add this delay when turning off the PWM enable
bit through intel_panel_disable_backlight(). If the PWM enable bit is
turned off while the PWM signal is high then the signal remains high. If
the bit is turned off when the signal is low the PWM will remain low.
Since we don't know the current state of the PWM signal we must set the
duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.
Actually it might be better if we never turn off the PWM enable bit in
intel_panel_disable_backlight() and we just use the duty cycle register
to control the PWM.
So I guess your approach is the simplest option here.
_intel_edp_backlight_on(intel_dp);
}
@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct
drm_device *dev,
assign_final(t11_t12);
#undef assign_final
+#define PWM_CYCLE_DELAY 5
Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
cycle here is exactly. Just one full period of the signal?
The PWM cycle in this case turns out to be 1 full cycle of the PWM
waveform though it depends on which display core clock (128 or
25Mhz(S0ix) is being used. Since we only care about the minimum elapsed
time to meet the panel specification a value of 5ms will work even
though more or less PWM cycles would take place before the BL_ENABLE is
asserted. I would prefer not to add complexity to switch between panel
timings for normal and S0ix display clock modes. How often does the
backlight get enabled while in S0ix?
I'm not sure how this could even be a problem for s0ix. The driver would
be suspended by the time we enter s0ix.
I'm more worried about other platforms that may have different pwm
cycle. So it seems to me that we should calculate the pwm cycle as
DIV_ROUND_UP(1000, intel_hrawclk()), assuming it's hrawclk instead of
cdclk that's used (which is the impression I get from the docs).
Also would be nice to have a
Re: [Intel-gfx] [REGRESSION BISECTED] backlight control stops workin with 3.14 and later
On Fri, 22 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On 19-8-2014 3:29, Jani Nikula wrote: On Tue, 19 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On Sun, 17 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: On 15-8-2014 3:43, Jani Nikula wrote: On Thu, 14 Aug 2014, Bertrik Sikken bert...@sikken.nl wrote: Attached is dmesg output from booting kernel 3.14-2 (debian unstable) with drm.debug=0xe and the samsung_laptop module enabled, from my Samsung N150plus netbook. Have you tried 3.15? I've built the v3.15 kernel (using the .config file from debian unstable and doing make oldconfig). The backlight is at maximum brightness after boot and I can't control it using the backlight buttons, nor by writing to /sys/class/backlight/samsung/brightness (say half the value or 1/10th of max_brightness) Backlight does work when writing /sys/class/backlight/intel_backlight/brightness How about disabling samsung backlight module with 3.15? I'm not sure what you mean by that. As I understand it, there are three ways to control the backlight on this netbook: using intel_backlight, samsung_laptop (using a sabi interface) and acpi_video. Backlight control using the samsung_laptop driver no longer seems to work after the change. If I disable it (e.g. by blacklisting it), I expect it to no longer work at all obviously. What do you want me to test exactly? If the intel_backlight interface works in 3.15, I presume the problem is that you have a non-functional samsung backlight interface that is preferred over intel_backlight by your userspace. I tested the intel_backlight interface in linux v3.15 with the samsung backlight module blacklisted. The intel_backlight interface still works. I read that as, I no longer have problems with backlight. The problem as I see it, is that the bisected backlight change in the intel-gfx driver caused the samsung_laptop backlight mechanism to break, while they apparently were able to play nice with each other before. You could consider having two drivers trying to access the same hardware as a more general linux kernel bug. As I understand it now, the intel-gfx driver talks directly to the hardware and the samsung_laptop driver talks through a BIOS interface (SABI = Samsung advanced BIOS interface). I'm not trying to put the blame on any of the two drivers, just looking for the best solution to a practical problem. With kind regards, Bertrik Sikken ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/bdw: Apply workarounds using the golden render state
Ville Syrjälä ville.syrj...@linux.intel.com writes: On Wed, Aug 20, 2014 at 03:19:17PM +0100, Arun Siluvery wrote: Workarounds for bdw are currently applied in init_clock_gating() but they are lost following a gpu reset. Some of the WA registers are part of register state context and they are restored with every context switch so initializing them in golden render state ensures that they are applied even when we start with an uninitialized context or during hw initlialization followed by a reset. v2: Add comments corresponding to WAs in golden render state (Chris). The generation of render state is not a straighforward process, it would be ideal to augment WA values from during the setup state as opposed to using a tool but that would be a follow up patch. I'd still prefer just emitting the LRIs from code rather tha mucking about with null batch. Less hoops to jump through when adding a new w/a. I agree with this. We should aim to keep null state as per gen. Workaround set is different for gtX inside particular gen so we would need then multiple null states per gen. After brief chat with Ville, I think that the correct spot to init the context specific workarounds is after MI_SET_CONTEXT to default and right before null batch is run. If we do these with emitting LRIs to ring, we should be safe as they are then saved with default ctx. The default ctx is then used as a 'parent' for newly created contexts. Ofcource if registers get globbered, then we inherit crap. If we have the per gen null state and the ring is initializing workarounds for the default context, then in future we can save this state as 'read only golden context'. And use it as the initial state for all newly created contexts. Then the full plan how to init would look like this: #1 reset the gpu (on driver load, on resume or on hang recovery) #2 if we have 'read only golden context', copy it to default ctx #3 switch to default context #4 if we had 'read only golden context' we are done with the init. --- #5 if this is driver load thus there is no 'read only golden context' yet. #6 init workarounds through ring LRIs #7 run null/golden state batch #8 save this state as a 'read only golden context' --- #9 for each new context, initialize ctx obj with 'read only golden context' (either by memcpy or restoring from it when switching to new) -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/i915: improve assert_panel_unlocked
Fix assert_panel_unlocked for vlv/chv, and improve it a bit for
non-LVDS. Also don't pretend it works for DDI. There's still work to do
to get this right for eDP on PCH platforms, but this is a start.
v2: WARN_ON(HAS_DDI)
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe1d00dc9ef5..51b4cd29f932 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1193,17 +1193,33 @@ void assert_fdi_rx_pll(struct drm_i915_private
*dev_priv,
static void assert_panel_unlocked(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
- int pp_reg, lvds_reg;
+ struct drm_device *dev = dev_priv-dev;
+ int pp_reg;
u32 val;
enum pipe panel_pipe = PIPE_A;
bool locked = true;
- if (HAS_PCH_SPLIT(dev_priv-dev)) {
+ if (WARN_ON(HAS_DDI(dev)))
+ return;
+
+ if (HAS_PCH_SPLIT(dev)) {
+ u32 port_sel;
+
pp_reg = PCH_PP_CONTROL;
- lvds_reg = PCH_LVDS;
+ port_sel = I915_READ(PCH_PP_ON_DELAYS) PANEL_PORT_SELECT_MASK;
+
+ if (port_sel == PANEL_PORT_SELECT_LVDS
+ I915_READ(PCH_LVDS) LVDS_PIPEB_SELECT)
+ panel_pipe = PIPE_B;
+ /* XXX: else fix for eDP */
+ } else if (IS_VALLEYVIEW(dev)) {
+ /* presumably write lock depends on pipe, not port select */
+ pp_reg = VLV_PIPE_PP_CONTROL(pipe);
+ panel_pipe = pipe;
} else {
pp_reg = PP_CONTROL;
- lvds_reg = LVDS;
+ if (I915_READ(LVDS) LVDS_PIPEB_SELECT)
+ panel_pipe = PIPE_B;
}
val = I915_READ(pp_reg);
@@ -1211,9 +1227,6 @@ static void assert_panel_unlocked(struct drm_i915_private
*dev_priv,
((val PANEL_UNLOCK_MASK) == PANEL_UNLOCK_REGS))
locked = false;
- if (I915_READ(lvds_reg) LVDS_PIPEB_SELECT)
- panel_pipe = PIPE_B;
-
WARN(panel_pipe == pipe locked,
panel assertion failure, pipe %c regs locked\n,
pipe_name(pipe));
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: don't check for i830 in vlv specific code
Signed-off-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 51b4cd29f932..83eabd758ed9 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1546,7 +1546,7 @@ static void vlv_enable_pll(struct intel_crtc *crtc) BUG_ON(!IS_VALLEYVIEW(dev_priv-dev)); /* PLL is protected by panel, make sure we can write it */ - if (IS_MOBILE(dev_priv-dev) !IS_I830(dev_priv-dev)) + if (IS_MOBILE(dev_priv-dev)) assert_panel_unlocked(dev_priv, crtc-pipe); I915_WRITE(reg, dpll); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/bdw: Apply workarounds using the golden render state
On 22/08/2014 12:06, Mika Kuoppala wrote: Ville Syrjälä ville.syrj...@linux.intel.com writes: On Wed, Aug 20, 2014 at 03:19:17PM +0100, Arun Siluvery wrote: Workarounds for bdw are currently applied in init_clock_gating() but they are lost following a gpu reset. Some of the WA registers are part of register state context and they are restored with every context switch so initializing them in golden render state ensures that they are applied even when we start with an uninitialized context or during hw initlialization followed by a reset. v2: Add comments corresponding to WAs in golden render state (Chris). The generation of render state is not a straighforward process, it would be ideal to augment WA values from during the setup state as opposed to using a tool but that would be a follow up patch. I'd still prefer just emitting the LRIs from code rather tha mucking about with null batch. Less hoops to jump through when adding a new w/a. I agree with this. We should aim to keep null state as per gen. Workaround set is different for gtX inside particular gen so we would need then multiple null states per gen. After brief chat with Ville, I think that the correct spot to init the context specific workarounds is after MI_SET_CONTEXT to default and right before null batch is run. If we do these with emitting LRIs to ring, we should be safe as they are then saved with default ctx. The default ctx is then used as a 'parent' for newly created contexts. Ofcource if registers get globbered, then we inherit crap. If we have the per gen null state and the ring is initializing workarounds for the default context, then in future we can save this state as 'read only golden context'. And use it as the initial state for all newly created contexts. Then the full plan how to init would look like this: #1 reset the gpu (on driver load, on resume or on hang recovery) #2 if we have 'read only golden context', copy it to default ctx #3 switch to default context #4 if we had 'read only golden context' we are done with the init. --- #5 if this is driver load thus there is no 'read only golden context' yet. #6 init workarounds through ring LRIs #7 run null/golden state batch #8 save this state as a 'read only golden context' --- #9 for each new context, initialize ctx obj with 'read only golden context' (either by memcpy or restoring from it when switching to new) I understand applying WAs using null batch has its issues but as I mentioned in the commit msg I will fix this as a follow up patch. It is going to take some time though to change the patch as per the new sequence. The patch in its current state helps fix WA issues after reset; so it can only be accepted if it is updated as per the new sequence? regards Arun -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] i965: First step toward prelocation
On Thu, Aug 21, 2014 at 11:12 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
This was a quick proof of concept to show the new API for prelocating
buffers.
What are prelocated buffers?
Alex
It needs way more testing, to not ifdef the no-relocs, and to do a
libdrm ABI dep bump.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
src/mesa/drivers/dri/i965/brw_program.c | 5 +++--
src/mesa/drivers/dri/i965/brw_queryobj.c| 6 +++---
src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 +++
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 8
7 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index 5809dc6..4b20d36 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -24,6 +24,7 @@
include Makefile.sources
AM_CFLAGS = \
+-DNO_RELOC \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
index edfa3d2..e30c527 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
@@ -1105,13 +1105,13 @@ brw_begin_perf_monitor(struct gl_context *ctx,
* wasting memory for contexts that don't use performance monitors.
*/
if (!brw-perfmon.bookend_bo) {
- brw-perfmon.bookend_bo = drm_intel_bo_alloc(brw-bufmgr,
+ brw-perfmon.bookend_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr,
OA bookend BO,
BOOKEND_BO_SIZE_BYTES,
64);
}
monitor-oa_bo =
- drm_intel_bo_alloc(brw-bufmgr, perf. monitor OA bo, 4096, 64);
+ drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor OA bo,
4096, 64);
#ifdef DEBUG
/* Pre-filling the BO helps debug whether writes landed. */
drm_intel_bo_map(monitor-oa_bo, true);
@@ -1146,7 +1146,7 @@ brw_begin_perf_monitor(struct gl_context *ctx,
if (monitor_needs_statistics_registers(brw, m)) {
monitor-pipeline_stats_bo =
- drm_intel_bo_alloc(brw-bufmgr, perf. monitor stats bo, 4096, 64);
+ drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor stats bo,
4096, 64);
/* Take starting snapshots. */
snapshot_statistics_registers(brw, monitor, 0);
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index d782b4f..74ff40c 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -43,6 +43,7 @@
#include brw_context.h
#include brw_wm.h
+#include intel_batchbuffer.h
static unsigned
get_new_program_id(struct intel_screen *screen)
@@ -242,7 +243,7 @@ brw_get_scratch_bo(struct brw_context *brw,
}
if (!old_bo) {
- *scratch_bo = drm_intel_bo_alloc(brw-bufmgr, scratch bo, size,
4096);
+ *scratch_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, scratch bo,
size, 4096);
}
}
@@ -265,7 +266,7 @@ void
brw_init_shader_time(struct brw_context *brw)
{
const int max_entries = 4096;
- brw-shader_time.bo = drm_intel_bo_alloc(brw-bufmgr, shader time,
+ brw-shader_time.bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, shader
time,
max_entries * SHADER_TIME_STRIDE,
4096);
brw-shader_time.shader_programs = rzalloc_array(brw, struct
gl_shader_program *,
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index c053c34..cf5a2a5 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -230,7 +230,7 @@ brw_begin_query(struct gl_context *ctx, struct
gl_query_object *q)
* the system was doing other work, such as running other applications.
*/
drm_intel_bo_unreference(query-bo);
- query-bo = drm_intel_bo_alloc(brw-bufmgr, timer query, 4096, 4096);
+ query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, timer query,
4096, 4096);
brw_write_timestamp(brw, query-bo, 0);
break;
@@ -388,7 +388,7 @@ ensure_bo_has_space(struct gl_context *ctx, struct
brw_query_object *query)
brw_queryobj_get_results(ctx, query);
}
- query-bo = drm_intel_bo_alloc(brw-bufmgr, query, 4096, 1);
+ query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, query, 4096, 1);
query-last_index = 0;
}
}
@@ -474,7 +474,7 @@ brw_query_counter(struct gl_context *ctx, struct
gl_query_object *q)
assert(q-Target ==
[Intel-gfx] WARNING in 3.17-rc1 for i915
My Toshiba A50 with graphics adapter described by 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) gets the following warning on 3.17-rc1: [ 1271.563533] [ cut here ] [ 1271.563568] WARNING: CPU: 1 PID: 1050 at drivers/gpu/drm/i915/intel_display.c:1234 assert_cursor.constprop.79+0x99/0xa0 [i915]() [ 1271.563571] cursor on pipe A assertion failure (expected off, current on) [ 1271.563573] Modules linked in: ctr ccm fuse nfs bnep bluetooth af_packet fscache arc4 x86_pkg_temp_thermal kvm_intel iwlmvm kvm mac80211 crct10dif_pclmul crc32_pclmul crc32c_intel snd_hda_codec_generic i915 snd_hda_intel ghash_clmulni_intel aesni_intel aes_x86_64 snd_hda_controller lrw gf128mul snd_hda_codec glue_helper iwlwifi ablk_helper rtsx_pci_sdmmc cryptd snd_hwdep snd_pcm rtsx_pci_ms memstick mmc_core snd_seq acpi_cpufreq cfg80211 drm_kms_helper processor drm microcode pcspkr serio_raw thermal video thermal_sys sr_mod cdrom lpc_ich snd_seq_device snd_timer rfkill rtsx_pci mfd_core snd soundcore e1000e i2c_algo_bit hwmon ptp pps_core wmi xhci_hcd ac battery button sg dm_mod autofs4 [ 1271.563659] CPU: 1 PID: 1050 Comm: Xorg Not tainted 3.17.0-rc1+ #9 [ 1271.563661] Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.20 04/17/2014 [ 1271.563664] 0009 8800c72f7aa8 816a009b 8800c72f7af0 [ 1271.563670] 8800c72f7ae0 8105bdfd [ 1271.563675] 0003 8800c6741000 8800c6741000 8800c72f7b40 [ 1271.563681] Call Trace: [ 1271.563688] [816a009b] dump_stack+0x4d/0x6f [ 1271.563695] [8105bdfd] warn_slowpath_common+0x7d/0xa0 [ 1271.563699] [8105be6c] warn_slowpath_fmt+0x4c/0x50 [ 1271.563720] [a04d2029] assert_cursor.constprop.79+0x99/0xa0 [i915] [ 1271.563737] [a04d4cb9] intel_enable_pipe+0x49/0x1f0 [i915] [ 1271.563757] [a04dd806] haswell_crtc_enable+0x486/0xa80 [i915] [ 1271.563774] [a04d9662] __intel_set_mode+0x822/0xac0 [i915] [ 1271.563793] [a04e1246] intel_set_mode+0x16/0x30 [i915] [ 1271.563811] [a04e221c] intel_crtc_set_config+0x92c/0xe70 [i915] [ 1271.563828] [a018e727] drm_mode_set_config_internal+0x67/0xf0 [drm] [ 1271.563843] [a019304c] drm_mode_setcrtc+0xdc/0x590 [drm] [ 1271.563855] [a0185016] drm_ioctl+0x1a6/0x640 [drm] [ 1271.563862] [811ebf15] ? __fget+0x5/0xe0 [ 1271.563867] [811e0f40] do_vfs_ioctl+0x300/0x520 [ 1271.563871] [811ebfbd] ? __fget+0xad/0xe0 [ 1271.563876] [811ebf15] ? __fget+0x5/0xe0 [ 1271.563880] [811e11e1] SyS_ioctl+0x81/0xa0 [ 1271.563887] [816a93d2] system_call_fastpath+0x16/0x1b [ 1271.563889] ---[ end trace 2327ac1a479ad52b ]--- Larry ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: don't check for i830 in vlv specific code
On Fri, Aug 22, 2014 at 03:06:35PM +0300, Jani Nikula wrote: Signed-off-by: Jani Nikula jani.nik...@intel.com --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 51b4cd29f932..83eabd758ed9 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -1546,7 +1546,7 @@ static void vlv_enable_pll(struct intel_crtc *crtc) BUG_ON(!IS_VALLEYVIEW(dev_priv-dev)); /* PLL is protected by panel, make sure we can write it */ - if (IS_MOBILE(dev_priv-dev) !IS_I830(dev_priv-dev)) + if (IS_MOBILE(dev_priv-dev)) assert_panel_unlocked(dev_priv, crtc-pipe); My gut feeling is that the IS_MOBILE check could also be dropped. Not quite sure though since VLV_D is not mentioned anywhere in the docs AFAICS. Anyway dropping the 830 check definitely makes sense so: Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com I915_WRITE(reg, dpll); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert
+Art
On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
There is also a need to add this delay when turning off the PWM enable
bit through intel_panel_disable_backlight(). If the PWM enable bit is
turned off while the PWM signal is high then the signal remains high. If
the bit is turned off when the signal is low the PWM will remain low.
Since we don't know the current state of the PWM signal we must set the
duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.
[citation needed]
Really, I want this in the specs if this is true.
Actually it might be better if we never turn off the PWM enable bit in
intel_panel_disable_backlight() and we just use the duty cycle register
to control the PWM.
Art, any feedback on these two?
BR,
Jani.
So I guess your approach is the simplest option here.
_intel_edp_backlight_on(intel_dp);
}
@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct
drm_device *dev,
assign_final(t11_t12);
#undef assign_final
+#define PWM_CYCLE_DELAY 5
Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
cycle here is exactly. Just one full period of the signal?
The PWM cycle in this case turns out to be 1 full cycle of the PWM
waveform though it depends on which display core clock (128 or
25Mhz(S0ix) is being used. Since we only care about the minimum elapsed
time to meet the panel specification a value of 5ms will work even
though more or less PWM cycles would take place before the BL_ENABLE is
asserted. I would prefer not to add complexity to switch between panel
timings for normal and S0ix display clock modes. How often does the
backlight get enabled while in S0ix?
Also would be nice to have a comment in the code explaining what this is
and why we need to add it to the delay.
Sure, As you may have noticed in other patches I really like comments.
#define get_delay(field) (DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
- intel_dp-backlight_on_delay = get_delay(t8);
+ intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 3abc915..ad6fcc1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
+ unsigned long last_backlight_on;
unsigned long last_backlight_off;
struct notifier_block edp_notifier;
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, Close to zero if the client uses existing interfaces. -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver. It wasn't invasive at all---I was surprised. Indeed, you could do everything inside libdrm with the code I posted 2 years ago. I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need to walk all the reloc tables (if nothing moved) because userspace didn't go insane and reuse reloc trees. So you'd need to implement a flag + a libdrm function to set that (iirc mesa has been non-stupid since years). And yeah I kinda expect any new reloc-less thing to get benchmarked against an implementation using that, since the 48bit specific thing proposed looks like a fairly short-lived stop-gap, and since the current no-reloc we already have would work everywhere. And yeah I've been poking people to look at this for years. too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote: On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, Close to zero if the client uses existing interfaces. -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver. It wasn't invasive at all---I was surprised. Indeed, you could do everything inside libdrm with the code I posted 2 years ago. I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need to walk all the reloc tables (if nothing moved) because userspace didn't go insane and reuse reloc trees. So you'd need to implement a flag + a libdrm function to set that (iirc mesa has been non-stupid since years). And yeah I kinda expect any new reloc-less thing to get benchmarked against an implementation using that, since the 48bit specific thing proposed looks like a fairly short-lived stop-gap, and since the current no-reloc we already have would work everywhere. And yeah I've been poking people to look at this for years. too. Here, I was referring to soft-pinning. The API here is essentially comprised of two parts: 1: a pin into the vm upon creation 2: implicit no-relocation upon execbuffer By making those two steps independent, the API as I see is, is more flexible and powerful. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Differentiate between LLC or snooped for the user
Rather than describing an object as either snooped or LLC, we can do
better as we should know what machine we are running on!
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 4 +++-
drivers/gpu/drm/i915/i915_gpu_error.c | 8 +---
drivers/gpu/drm/i915/i915_sysfs.c | 2 +-
4 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 19f27d7f1d9b..eb1859f87a88 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -137,7 +137,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
i915_request_seqno(rq),
i915_request_seqno(obj-last_write.request),
i915_request_seqno(obj-last_fence.request),
- i915_cache_level_str(obj-cache_level),
+ i915_cache_level_str(to_i915(obj-base.dev),
obj-cache_level),
obj-dirty ? dirty : ,
obj-madv == I915_MADV_DONTNEED ? purgeable : );
if (obj-base.name)
@@ -1014,7 +1014,7 @@ static ssize_t i915_error_state_read(struct file *file,
char __user *userbuf,
ssize_t ret_count = 0;
int ret;
- ret = i915_error_state_buf_init(error_str, count, *pos);
+ ret = i915_error_state_buf_init(error_str, to_i915(error_priv-dev),
count, *pos);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1e3179faef7c..1439da02f6f2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1162,6 +1162,7 @@ struct i915_gem_mm {
};
struct drm_i915_error_state_buf {
+ struct drm_i915_private *i915;
unsigned bytes;
unsigned size;
int err;
@@ -2748,6 +2749,7 @@ void i915_error_printf(struct drm_i915_error_state_buf
*e, const char *f, ...);
int i915_error_state_to_str(struct drm_i915_error_state_buf *estr,
const struct i915_error_state_file_priv *error);
int i915_error_state_buf_init(struct drm_i915_error_state_buf *eb,
+ struct drm_i915_private *i915,
size_t count, loff_t pos);
static inline void i915_error_state_buf_release(
struct drm_i915_error_state_buf *eb)
@@ -2762,7 +2764,7 @@ void i915_error_state_put(struct
i915_error_state_file_priv *error_priv);
void i915_destroy_error_state(struct drm_device *dev);
void i915_get_extra_instdone(struct drm_device *dev, uint32_t *instdone);
-const char *i915_cache_level_str(int type);
+const char *i915_cache_level_str(struct drm_i915_private *i915, int type);
/* i915_cmd_parser.c */
int i915_cmd_parser_get_version(void);
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index b3d6e913917d..51e45eaafc2e 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -208,7 +208,7 @@ static void print_error_buffers(struct
drm_i915_error_state_buf *m,
err_puts(m, err-userptr ? userptr : );
err_puts(m, err-ring != -1 ? : );
err_puts(m, ring_str(err-ring));
- err_puts(m, i915_cache_level_str(err-cache_level));
+ err_puts(m, i915_cache_level_str(m-i915, err-cache_level));
if (err-name)
err_printf(m, (name: %d), err-name);
@@ -502,9 +502,11 @@ out:
}
int i915_error_state_buf_init(struct drm_i915_error_state_buf *ebuf,
+ struct drm_i915_private *i915,
size_t count, loff_t pos)
{
memset(ebuf, 0, sizeof(*ebuf));
+ ebuf-i915 = i915;
/* We need to have enough room to store any i915_error_state printf
* so that we can move it to start position.
@@ -1367,11 +1369,11 @@ void i915_destroy_error_state(struct drm_device *dev)
kref_put(error-ref, i915_error_state_free);
}
-const char *i915_cache_level_str(int type)
+const char *i915_cache_level_str(struct drm_i915_private *i915, int type)
{
switch (type) {
case I915_CACHE_NONE: return uncached;
- case I915_CACHE_LLC: return snooped or LLC;
+ case I915_CACHE_LLC: return HAS_LLC(i915) ? LLC : snooped;
case I915_CACHE_L3_LLC: return L3+LLC;
case I915_CACHE_WT: return WT;
default: return ;
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index ae7fd8fc27f0..503847f18fdd 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -540,7 +540,7 @@ static ssize_t error_state_read(struct file *filp, struct
kobject *kobj,
memset(error_priv, 0, sizeof(error_priv));
- ret = i915_error_state_buf_init(error_str, count, off);
+ ret =
[Intel-gfx] [PATCH v2 10.1/14] drm/i915: Reset power sequencer pipe tracking when disp2d is off
From: Ville Syrjälä ville.syrj...@linux.intel.com
The power sequencer loses its state when the disp2d power well is down.
Clear the dev_priv-pps_pipe tracking so that the power sequencer state
gets reinitialized the next time it's needed.
v2: Fix the pps_mutex vs. power_domain mutex deadlock by taking power
domain reference first
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Imre noticed my previouys attempt was utter garbage. Let's try again. Again
maybe
we want to squash with 10/14 or at least move the edp_pps_{lock,unlock}()
introduction
there to avoid churn.
The alternative of trying to plumb all the power domain calls out from under
pps_mutex seemed a bit too nasty to me, so I opted for this approach instead.
drivers/gpu/drm/i915/intel_dp.c | 157 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 2 +
3 files changed, 106 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d6fe1a2..3468315 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -389,6 +389,67 @@ vlv_initial_power_sequencer_setup(struct intel_dp
*intel_dp)
power_seq);
}
+void vlv_power_sequencer_reset(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+ struct intel_encoder *encoder;
+
+ if (WARN_ON(!IS_VALLEYVIEW(dev)))
+ return;
+
+ /*
+* We can't grab pps_mutex here due to deadlock with power_domain
+* mutex when power_domain functions are called while holding pps_mutex.
+* That also means that in order to use pps_pipe the code needs to
+* hold both a power domain reference and pps_mutex, and the power
domain
+* reference get/put must be done while _not_ holding pps_mutex.
+* edp_pps_{lock,unlock}() do these steps in the correct order, so one
+* should use them always.
+*/
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
{
+ struct intel_dp *intel_dp;
+
+ if (encoder-type != INTEL_OUTPUT_EDP)
+ continue;
+
+ intel_dp = enc_to_intel_dp(encoder-base);
+ intel_dp-pps_pipe = INVALID_PIPE;
+ }
+}
+
+static void edp_pps_lock(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = intel_dig_port-base;
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ enum intel_display_power_domain power_domain;
+
+ /*
+* See vlv_power_sequencer_reset() why we need
+* a power domain reference here.
+*/
+ power_domain = intel_display_port_power_domain(encoder);
+ intel_display_power_get(dev_priv, power_domain);
+
+ mutex_lock(dev_priv-pps_mutex);
+}
+
+static void edp_pps_unlock(struct intel_dp *intel_dp)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct intel_encoder *encoder = intel_dig_port-base;
+ struct drm_device *dev = encoder-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ enum intel_display_power_domain power_domain;
+
+ mutex_unlock(dev_priv-pps_mutex);
+
+ power_domain = intel_display_port_power_domain(encoder);
+ intel_display_power_put(dev_priv, power_domain);
+}
+
static u32 _pp_ctrl_reg(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -425,7 +486,7 @@ static int edp_notify_handler(struct notifier_block *this,
unsigned long code,
if (!IS_VALLEYVIEW(dev) || !is_edp(intel_dp) || code != SYS_RESTART)
return 0;
- mutex_lock(dev_priv-pps_mutex);
+ edp_pps_lock(intel_dp);
pipe = vlv_power_sequencer_pipe(intel_dp);
@@ -439,7 +500,7 @@ static int edp_notify_handler(struct notifier_block *this,
unsigned long code,
I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
msleep(intel_dp-panel_power_cycle_delay);
- mutex_unlock(dev_priv-pps_mutex);
+ edp_pps_unlock(intel_dp);
return 0;
}
@@ -458,17 +519,13 @@ static bool edp_have_panel_vdd(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
- struct intel_encoder *intel_encoder = intel_dig_port-base;
- enum intel_display_power_domain power_domain;
lockdep_assert_held(dev_priv-pps_mutex);
- power_domain = intel_display_port_power_domain(intel_encoder);
- return intel_display_power_enabled(dev_priv, power_domain)
-
Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert
I'll check it out. I haven't heard any complaint about this before, but it may
be one of those things that started back on i745 and never got documented.
-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
Sent: Friday, August 22, 2014 6:07 AM
To: Taylor, Clinton A; Ville Syrjälä; Runyan, Arthur J
Cc: Intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL
Enable assert
+Art
On Thu, 21 Aug 2014, Clint Taylor clinton.a.tay...@intel.com wrote:
There is also a need to add this delay when turning off the PWM enable
bit through intel_panel_disable_backlight(). If the PWM enable bit is
turned off while the PWM signal is high then the signal remains high. If
the bit is turned off when the signal is low the PWM will remain low.
Since we don't know the current state of the PWM signal we must set the
duty_cycle to 0, wait PWM_CYCLE_DELAY, and then turn off the enable bit.
[citation needed]
Really, I want this in the specs if this is true.
Actually it might be better if we never turn off the PWM enable bit in
intel_panel_disable_backlight() and we just use the duty cycle register
to control the PWM.
Art, any feedback on these two?
BR,
Jani.
So I guess your approach is the simplest option here.
_intel_edp_backlight_on(intel_dp);
}
@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct
drm_device *dev,
assign_final(t11_t12);
#undef assign_final
+#define PWM_CYCLE_DELAY 5
Shoduln't this be calculated from the PWM frequqncy? Not sure what a PWM
cycle here is exactly. Just one full period of the signal?
The PWM cycle in this case turns out to be 1 full cycle of the PWM
waveform though it depends on which display core clock (128 or
25Mhz(S0ix) is being used. Since we only care about the minimum elapsed
time to meet the panel specification a value of 5ms will work even
though more or less PWM cycles would take place before the BL_ENABLE is
asserted. I would prefer not to add complexity to switch between panel
timings for normal and S0ix display clock modes. How often does the
backlight get enabled while in S0ix?
Also would be nice to have a comment in the code explaining what this is
and why we need to add it to the delay.
Sure, As you may have noticed in other patches I really like comments.
#define get_delay(field) (DIV_ROUND_UP(final.field, 10))
intel_dp-panel_power_up_delay = get_delay(t1_t3);
- intel_dp-backlight_on_delay = get_delay(t8);
+ intel_dp-backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp-backlight_off_delay = get_delay(t9);
intel_dp-panel_power_down_delay = get_delay(t10);
intel_dp-panel_power_cycle_delay = get_delay(t11_t12);
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 3abc915..ad6fcc1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
+ unsigned long last_backlight_on;
unsigned long last_backlight_off;
struct notifier_block edp_notifier;
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH] i965: First step toward prelocation
On Fri, Aug 22, 2014 at 08:15:28AM -0400, Alex Deucher wrote:
On Thu, Aug 21, 2014 at 11:12 PM, Ben Widawsky
benjamin.widaw...@intel.com wrote:
This was a quick proof of concept to show the new API for prelocating
buffers.
What are prelocated buffers?
http://lists.freedesktop.org/archives/mesa-dev/2014-August/066432.html
Alex
It needs way more testing, to not ifdef the no-relocs, and to do a
libdrm ABI dep bump.
---
src/mesa/drivers/dri/i965/Makefile.am | 1 +
src/mesa/drivers/dri/i965/brw_performance_monitor.c | 6 +++---
src/mesa/drivers/dri/i965/brw_program.c | 5 +++--
src/mesa/drivers/dri/i965/brw_queryobj.c| 6 +++---
src/mesa/drivers/dri/i965/brw_state_cache.c | 4 ++--
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 3 +++
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 8
7 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/Makefile.am
b/src/mesa/drivers/dri/i965/Makefile.am
index 5809dc6..4b20d36 100644
--- a/src/mesa/drivers/dri/i965/Makefile.am
+++ b/src/mesa/drivers/dri/i965/Makefile.am
@@ -24,6 +24,7 @@
include Makefile.sources
AM_CFLAGS = \
+-DNO_RELOC \
-I$(top_srcdir)/include \
-I$(top_srcdir)/src/ \
-I$(top_srcdir)/src/mapi \
diff --git a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
index edfa3d2..e30c527 100644
--- a/src/mesa/drivers/dri/i965/brw_performance_monitor.c
+++ b/src/mesa/drivers/dri/i965/brw_performance_monitor.c
@@ -1105,13 +1105,13 @@ brw_begin_perf_monitor(struct gl_context *ctx,
* wasting memory for contexts that don't use performance monitors.
*/
if (!brw-perfmon.bookend_bo) {
- brw-perfmon.bookend_bo = drm_intel_bo_alloc(brw-bufmgr,
+ brw-perfmon.bookend_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr,
OA bookend BO,
BOOKEND_BO_SIZE_BYTES, 64);
}
monitor-oa_bo =
- drm_intel_bo_alloc(brw-bufmgr, perf. monitor OA bo, 4096, 64);
+ drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor OA bo,
4096, 64);
#ifdef DEBUG
/* Pre-filling the BO helps debug whether writes landed. */
drm_intel_bo_map(monitor-oa_bo, true);
@@ -1146,7 +1146,7 @@ brw_begin_perf_monitor(struct gl_context *ctx,
if (monitor_needs_statistics_registers(brw, m)) {
monitor-pipeline_stats_bo =
- drm_intel_bo_alloc(brw-bufmgr, perf. monitor stats bo, 4096,
64);
+ drm_intel_bo_alloc_wrapper(brw-bufmgr, perf. monitor stats bo,
4096, 64);
/* Take starting snapshots. */
snapshot_statistics_registers(brw, monitor, 0);
diff --git a/src/mesa/drivers/dri/i965/brw_program.c
b/src/mesa/drivers/dri/i965/brw_program.c
index d782b4f..74ff40c 100644
--- a/src/mesa/drivers/dri/i965/brw_program.c
+++ b/src/mesa/drivers/dri/i965/brw_program.c
@@ -43,6 +43,7 @@
#include brw_context.h
#include brw_wm.h
+#include intel_batchbuffer.h
static unsigned
get_new_program_id(struct intel_screen *screen)
@@ -242,7 +243,7 @@ brw_get_scratch_bo(struct brw_context *brw,
}
if (!old_bo) {
- *scratch_bo = drm_intel_bo_alloc(brw-bufmgr, scratch bo, size,
4096);
+ *scratch_bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, scratch bo,
size, 4096);
}
}
@@ -265,7 +266,7 @@ void
brw_init_shader_time(struct brw_context *brw)
{
const int max_entries = 4096;
- brw-shader_time.bo = drm_intel_bo_alloc(brw-bufmgr, shader time,
+ brw-shader_time.bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, shader
time,
max_entries *
SHADER_TIME_STRIDE,
4096);
brw-shader_time.shader_programs = rzalloc_array(brw, struct
gl_shader_program *,
diff --git a/src/mesa/drivers/dri/i965/brw_queryobj.c
b/src/mesa/drivers/dri/i965/brw_queryobj.c
index c053c34..cf5a2a5 100644
--- a/src/mesa/drivers/dri/i965/brw_queryobj.c
+++ b/src/mesa/drivers/dri/i965/brw_queryobj.c
@@ -230,7 +230,7 @@ brw_begin_query(struct gl_context *ctx, struct
gl_query_object *q)
* the system was doing other work, such as running other
applications.
*/
drm_intel_bo_unreference(query-bo);
- query-bo = drm_intel_bo_alloc(brw-bufmgr, timer query, 4096,
4096);
+ query-bo = drm_intel_bo_alloc_wrapper(brw-bufmgr, timer query,
4096, 4096);
brw_write_timestamp(brw, query-bo, 0);
break;
@@ -388,7 +388,7 @@ ensure_bo_has_space(struct gl_context *ctx, struct
brw_query_object *query)
brw_queryobj_get_results(ctx, query);
}
- query-bo =
[Intel-gfx] [PATCH 0/2] Apply BDW workarounds using LRIs in render init fn
Workarounds for BDW are applied using LRIs during render ring initialization. Only those WA registers that are part of register state are initialized in this fn, remaining are still in its current place init_clock_gating() which are not affected by a gpu reset. I can send another patch where they can be moved to render ring init function but during testing I found their state doesn't change after reset. Arun Siluvery (2): drm/i915/bdw: Apply workarounds in render ring init function drm/i915/bdw: Export workaround data to debugfs drivers/gpu/drm/i915/i915_debugfs.c | 40 + drivers/gpu/drm/i915/i915_drv.h | 14 ++ drivers/gpu/drm/i915/i915_gem_context.c | 6 +++ drivers/gpu/drm/i915/intel_pm.c | 48 drivers/gpu/drm/i915/intel_ringbuffer.c | 77 + drivers/gpu/drm/i915/intel_ringbuffer.h | 17 6 files changed, 154 insertions(+), 48 deletions(-) -- 2.0.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/bdw: Export workaround data to debugfs
The workarounds that are applied are exported to a debugfs file;
this is used to verify their state after the test case (reset or
suspend/resume etc). This patch is only required to support i-g-t.
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 40 +
drivers/gpu/drm/i915/i915_drv.h | 14
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 14 ++--
4 files changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d42db6b..f0d63f6 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2451,20 +2451,59 @@ static int i915_shared_dplls_info(struct seq_file *m,
void *unused)
seq_printf(m, dpll_md: 0x%08x\n, pll-hw_state.dpll_md);
seq_printf(m, fp0: 0x%08x\n, pll-hw_state.fp0);
seq_printf(m, fp1: 0x%08x\n, pll-hw_state.fp1);
seq_printf(m, wrpll: 0x%08x\n, pll-hw_state.wrpll);
}
drm_modeset_unlock_all(dev);
return 0;
}
+static int intel_wa_registers(struct seq_file *m, void *unused)
+{
+ int i;
+ int ret;
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!IS_BROADWELL(dev)) {
+ DRM_DEBUG_DRIVER(Workaround table not available !!\n);
+ return -EINVAL;
+ }
+
+ ret = mutex_lock_interruptible(dev-struct_mutex);
+ if (ret)
+ return ret;
+
+ intel_runtime_pm_get(dev_priv);
+
+ seq_printf(m, Workarounds applied: %d\n, dev_priv-num_wa_regs);
+ for (i = 0; i dev_priv-num_wa_regs; ++i) {
+ u32 addr, mask;
+
+ addr = dev_priv-intel_wa_regs[i].addr;
+ mask = dev_priv-intel_wa_regs[i].mask;
+ dev_priv-intel_wa_regs[i].value = I915_READ(addr) | mask;
+ if (dev_priv-intel_wa_regs[i].addr)
+ seq_printf(m, 0x%X: 0x%08X, mask: 0x%08X\n,
+ dev_priv-intel_wa_regs[i].addr,
+ dev_priv-intel_wa_regs[i].value,
+ dev_priv-intel_wa_regs[i].mask);
+ }
+
+ intel_runtime_pm_put(dev_priv);
+ mutex_unlock(dev-struct_mutex);
+
+ return 0;
+}
+
struct pipe_crc_info {
const char *name;
struct drm_device *dev;
enum pipe pipe;
};
static int i915_dp_mst_info(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *) m-private;
struct drm_device *dev = node-minor-dev;
@@ -3980,20 +4019,21 @@ static const struct drm_info_list i915_debugfs_list[] =
{
{i915_llc, i915_llc, 0},
{i915_edp_psr_status, i915_edp_psr_status, 0},
{i915_sink_crc_eDP1, i915_sink_crc, 0},
{i915_energy_uJ, i915_energy_uJ, 0},
{i915_pc8_status, i915_pc8_status, 0},
{i915_power_domain_info, i915_power_domain_info, 0},
{i915_display_info, i915_display_info, 0},
{i915_semaphore_status, i915_semaphore_status, 0},
{i915_shared_dplls_info, i915_shared_dplls_info, 0},
{i915_dp_mst_info, i915_dp_mst_info, 0},
+ {intel_wa_registers, intel_wa_registers, 0}
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
static const struct i915_debugfs_files {
const char *name;
const struct file_operations *fops;
} i915_debugfs_files[] = {
{i915_wedged, i915_wedged_fops},
{i915_max_freq, i915_max_freq_fops},
{i915_min_freq, i915_min_freq_fops},
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index bcf79f0..49b7be7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1546,20 +1546,34 @@ struct drm_i915_private {
wait_queue_head_t pending_flip_queue;
#ifdef CONFIG_DEBUG_FS
struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
#endif
int num_shared_dpll;
struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
+ /*
+* workarounds are currently applied at different places and
+* changes are being done to consolidate them so exact count is
+* not clear at this point, use a max value for now.
+*/
+#define I915_MAX_WA_REGS 16
+ struct {
+ u32 addr;
+ u32 value;
+ /* bitmask representing WA bits */
+ u32 mask;
+ } intel_wa_regs[I915_MAX_WA_REGS];
+ u32 num_wa_regs;
+
/* Reclocking support */
bool render_reclock_avail;
bool lvds_downclock_avail;
/* indicates the reduced downclock for
[Intel-gfx] [PATCH 1/2] drm/i915/bdw: Apply workarounds in render ring init function
For BDW workarounds are currently initialized in init_clock_gating() but
they are lost during reset, suspend/resume etc; this patch moves the WAs
that are part of register state context to render ring init fn otherwise
default context ends up with incorrect values as they don't get initialized
until init_clock_gating fn.
v2: Add workarounds to golden render state
This method has its own issues, first of all this is different for
each gen and it is generated using a tool so adding new workaround
and mainitaining them across gens is not a straightforward process.
v3: Use LRIs to emit these workarounds (Ville)
Instead of modifying the golden render state the same LRIs are
emitted from within the driver.
For: VIZ-4092
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
drivers/gpu/drm/i915/i915_gem_context.c | 6 +++
drivers/gpu/drm/i915/intel_pm.c | 48 --
drivers/gpu/drm/i915/intel_ringbuffer.c | 70 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 7
4 files changed, 83 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 9683e62..2debce4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -631,20 +631,26 @@ static int do_switch(struct intel_engine_cs *ring,
}
uninitialized = !to-legacy_hw_ctx.initialized from == NULL;
to-legacy_hw_ctx.initialized = true;
done:
i915_gem_context_reference(to);
ring-last_context = to;
if (uninitialized) {
+ if (IS_BROADWELL(ring-dev)) {
+ ret = bdw_init_workarounds(ring);
+ if (ret)
+ DRM_ERROR(init workarounds: %d\n, ret);
+ }
+
ret = i915_gem_render_state_init(ring);
if (ret)
DRM_ERROR(init render state: %d\n, ret);
}
return 0;
unpin_out:
if (ring-id == RCS)
i915_gem_object_ggtt_unpin(to-legacy_hw_ctx.rcs_state);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c8f744c..668acd9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5507,101 +5507,53 @@ static void gen8_init_clock_gating(struct drm_device
*dev)
struct drm_i915_private *dev_priv = dev-dev_private;
enum pipe pipe;
I915_WRITE(WM3_LP_ILK, 0);
I915_WRITE(WM2_LP_ILK, 0);
I915_WRITE(WM1_LP_ILK, 0);
/* FIXME(BDW): Check all the w/a, some might only apply to
* pre-production hw. */
- /* WaDisablePartialInstShootdown:bdw */
- I915_WRITE(GEN8_ROW_CHICKEN,
- _MASKED_BIT_ENABLE(PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE));
-
- /* WaDisableThreadStallDopClockGating:bdw */
- /* FIXME: Unclear whether we really need this on production bdw. */
- I915_WRITE(GEN8_ROW_CHICKEN,
- _MASKED_BIT_ENABLE(STALL_DOP_GATING_DISABLE));
- /*
-* This GEN8_CENTROID_PIXEL_OPT_DIS W/A is only needed for
-* pre-production hardware
-*/
- I915_WRITE(HALF_SLICE_CHICKEN3,
- _MASKED_BIT_ENABLE(GEN8_CENTROID_PIXEL_OPT_DIS));
- I915_WRITE(HALF_SLICE_CHICKEN3,
- _MASKED_BIT_ENABLE(GEN8_SAMPLER_POWER_BYPASS_DIS));
I915_WRITE(GAMTARBMODE, _MASKED_BIT_ENABLE(ARB_MODE_BWGTLB_DISABLE));
I915_WRITE(_3D_CHICKEN3,
_MASKED_BIT_ENABLE(_3D_CHICKEN_SDE_LIMIT_FIFO_POLY_DEPTH(2)));
- I915_WRITE(COMMON_SLICE_CHICKEN2,
- _MASKED_BIT_ENABLE(GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE));
-
- I915_WRITE(GEN7_HALF_SLICE_CHICKEN1,
- _MASKED_BIT_ENABLE(GEN7_SINGLE_SUBSCAN_DISPATCH_ENABLE));
-
- /* WaDisableDopClockGating:bdw May not be needed for production */
- I915_WRITE(GEN7_ROW_CHICKEN2,
- _MASKED_BIT_ENABLE(DOP_CLOCK_GATING_DISABLE));
/* WaSwitchSolVfFArbitrationPriority:bdw */
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
/* WaPsrDPAMaskVBlankInSRD:bdw */
I915_WRITE(CHICKEN_PAR1_1,
I915_READ(CHICKEN_PAR1_1) | DPA_MASK_VBLANK_SRD);
/* WaPsrDPRSUnmaskVBlankInSRD:bdw */
for_each_pipe(pipe) {
I915_WRITE(CHICKEN_PIPESL_1(pipe),
I915_READ(CHICKEN_PIPESL_1(pipe)) |
BDW_DPRS_MASK_VBLANK_SRD);
}
- /* Use Force Non-Coherent whenever executing a 3D context. This is a
-* workaround for for a possible hang in the unlikely event a TLB
-* invalidation occurs during a PSD flush.
-*/
- I915_WRITE(HDC_CHICKEN0,
- I915_READ(HDC_CHICKEN0) |
- _MASKED_BIT_ENABLE(HDC_FORCE_NON_COHERENT));
-
/*
[Intel-gfx] [PATCH] igt/gem_workarounds: igt to test workaround registers
Some of the workarounds are lost followed by a gpu reset, suspend/resume;
this patch adds a test which compares register state before and after
the test scenario.
This test currently verifies only bdw workarounds.
v2: address patch cleanup comments (ThomasW)
Add binary to ignore list and use igt_debugfs helper fns
to read debugfs file and igt_info for printing debug info.
Signed-off-by: Arun Siluvery arun.siluv...@linux.intel.com
---
tests/.gitignore| 1 +
tests/Makefile.sources | 1 +
tests/gem_workarounds.c | 233
3 files changed, 235 insertions(+)
create mode 100644 tests/gem_workarounds.c
diff --git a/tests/.gitignore b/tests/.gitignore
index 985afbd..1103e2e 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -97,20 +97,21 @@ gem_tiled_fence_blits
gem_tiled_partial_pwrite_pread
gem_tiled_pread
gem_tiled_pread_pwrite
gem_tiled_swapping
gem_tiling_max_stride
gem_unfence_active_buffers
gem_unref_active_buffers
gem_userptr_blits
gem_wait_render_timeout
gem_write_read_ring_switch
+gem_workarounds
gen3_mixed_blits
gen3_render_linear_blits
gen3_render_mixed_blits
gen3_render_tiledx_blits
gen3_render_tiledy_blits
gen7_forcewake_mt
igt_fork_helper
igt_list_only
igt_no_exit
igt_no_exit_list_only
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 0eb9369..a17acd1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -127,20 +127,21 @@ TESTS_progs = \
gem_storedw_loop_vebox \
gem_threaded_access_tiled \
gem_tiled_fence_blits \
gem_tiled_pread \
gem_tiled_pread_pwrite \
gem_tiled_swapping \
gem_tiling_max_stride \
gem_unfence_active_buffers \
gem_unref_active_buffers \
gem_wait_render_timeout \
+ gem_workarounds \
gen3_mixed_blits \
gen3_render_linear_blits \
gen3_render_mixed_blits \
gen3_render_tiledx_blits \
gen3_render_tiledy_blits \
gen7_forcewake_mt \
kms_force_connector \
kms_sink_crc_basic \
kms_fence_pin_leak \
pm_psr \
diff --git a/tests/gem_workarounds.c b/tests/gem_workarounds.c
new file mode 100644
index 000..72e714f
--- /dev/null
+++ b/tests/gem_workarounds.c
@@ -0,0 +1,233 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ * Arun Siluvery arun.siluv...@linux.intel.com
+ *
+ */
+
+#define _GNU_SOURCE
+#include stdbool.h
+#include unistd.h
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include fcntl.h
+#include inttypes.h
+#include errno.h
+#include sys/stat.h
+#include sys/ioctl.h
+#include sys/mman.h
+#include time.h
+#include signal.h
+
+#include ioctl_wrappers.h
+#include drmtest.h
+#include igt_debugfs.h
+#include igt_aux.h
+#include intel_chipset.h
+#include intel_io.h
+
+enum operation {
+ GPU_RESET = 0x01,
+ SUSPEND_RESUME = 0x02,
+};
+
+struct intel_wa_reg {
+ uint32_t addr;
+ uint32_t value;
+ uint32_t mask;
+};
+
+int drm_fd;
+uint32_t devid;
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+int num_wa_regs;
+struct intel_wa_reg *wa_regs;
+
+
+static void test_hang_gpu(void)
+{
+ int retry_count = 30;
+ enum stop_ring_flags flags;
+ struct drm_i915_gem_execbuffer2 execbuf;
+ struct drm_i915_gem_exec_object2 gem_exec;
+ uint32_t b[2] = {MI_BATCH_BUFFER_END};
+
+ igt_assert(retry_count);
+ igt_set_stop_rings(STOP_RING_DEFAULTS);
+
+ memset(gem_exec, 0, sizeof(gem_exec));
+ gem_exec.handle = gem_create(drm_fd, 4096);
+ gem_write(drm_fd, gem_exec.handle, 0, b, sizeof(b));
+
+ memset(execbuf, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = (uintptr_t)gem_exec;
+ execbuf.buffer_count = 1;
+ execbuf.batch_len = sizeof(b);
+
+ drmIoctl(drm_fd,
Re: [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote: On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, Close to zero if the client uses existing interfaces. -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver. It wasn't invasive at all---I was surprised. Indeed, you could do everything inside libdrm with the code I posted 2 years ago. I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need to walk all the reloc tables (if nothing moved) because userspace didn't go insane and reuse reloc trees. So you'd need to implement a flag + a libdrm function to set that (iirc mesa has been non-stupid since years). And yeah I kinda expect any new reloc-less thing to get benchmarked against an implementation using that, since the 48bit specific thing proposed looks like a fairly short-lived stop-gap, and since the current no-reloc we already have would work everywhere. And yeah I've been poking people to look at this for years. too. Here, I was referring to soft-pinning. The API here is essentially comprised of two parts: 1: a pin into the vm upon creation 2: implicit no-relocation upon execbuffer By making those two steps independent, the API as I see is, is more flexible and powerful. Well I admit to not having read the patches over the terrible wifi here, but I presumed Ben's patches -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs)
On Fri, Aug 22, 2014 at 3:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Fri, Aug 22, 2014 at 03:30:12PM +0200, Daniel Vetter wrote: On Fri, Aug 22, 2014 at 9:03 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: If a GPU client uses only prelocations, the relocation process can be entirely skipped. This sounds like a big win initially, Close to zero if the client uses existing interfaces. -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a few patches to libdrm and virtually zero Mesa changes, he's apparently eliminated our need to do any relocations for the 3D driver. It wasn't invasive at all---I was surprised. Indeed, you could do everything inside libdrm with the code I posted 2 years ago. I915_EXEC_NO_RELOC can be used to tell the kernel that it doesn't need to walk all the reloc tables (if nothing moved) because userspace didn't go insane and reuse reloc trees. So you'd need to implement a flag + a libdrm function to set that (iirc mesa has been non-stupid since years). And yeah I kinda expect any new reloc-less thing to get benchmarked against an implementation using that, since the 48bit specific thing proposed looks like a fairly short-lived stop-gap, and since the current no-reloc we already have would work everywhere. And yeah I've been poking people to look at this for years. too. Here, I was referring to soft-pinning. The API here is essentially comprised of two parts: 1: a pin into the vm upon creation 2: implicit no-relocation upon execbuffer By making those two steps independent, the API as I see is, is more flexible and powerful. Well I admit to not having read the patches over the terrible wifi here, but I presumed Ben's patches did implement softpin. I guess I've made a mess of all of this now. In any case I still want to see relative improvements over what we have since the prelocated stuff looks like a gen8 oneshot. And we still can't do relocation-less execbuf because the gpu can't fault, so I'm not sure at all whether this is actually useful for opencl 2.0. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Updated drm-intel-testing
Hi all, New -testing cycle with cool stuff: - basic code for execlist, which is the fancy new cmd submission on gen8. Still disabled by default (Ben, Oscar Mateo, Thomas Daniel et al) - remove the useless usage of console_lock for I915_FBDEV=n (Chris) - clean up relations between ctx and ppgtt - clean up ppgtt lifetime handling (Michel Thierry) - various cursor code improvements from Ville - execbuffer code cleanups and secure batch fixes (Chris) - prep work for dev - dev_priv transition (Chris) - some of the prep patches for the seqno - request object transition (Chris) - various small improvements all over Happy testing! Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
