[Intel-gfx] ns2501 DVO - success at last
Hi Daniel, hi Ville, some success at last. I couldn't stop myself playing with the NatSemi 2501 DVO in my Fujitsu S6010 and I believe I finally got a hang on this chip. I believe I understand now most of the undocumented registers. There are also a couple of additional features that are, apparently, not used by the video BIOS of the S6010, namely the chip has a ditherer on board - quite like the Intel Video Controller hub in the IBM R31. Unfortunately, to enable the scaler, the bypass must be turned off, and hence, parameters for a 1:1 through-mapping of the scaler are required. After quite some experimenting, I believe I found now the right settings to enable the scaler and configure it to pass the 1024x768 input to the output. The chip is really a bit weird. It not only requires the scaling factors, but also the input timings, (sync width, front/back porch for both horizontal and vertical) and the output timing, and the configuration of its PLL to sample the incoming data. Currently, most of the data I obtained by trail and error, at least for the 1024x768 mode in which the bios configures the DVO in bypass mode. It turned out we forgot to configure a couple of registers (and some others are pretty much blank). Thus, my question at this time is whether there is any interface how to get the precise timing of the loaded video mode from the i915 module directly instead of second-guessing the parameters, i.e. dimensions of the frame, porch sizes, size of the sync pulses, pixel clock and so on. Other than that, I'll try to clean up the code I have to so far in the next days and release it. Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers
On Tue, Apr 07, 2015 at 03:28:46PM -0700, Chandra Konduru wrote:
This patch enables skylake primary plane scaling using shared
scalers atomic desgin.
v2:
-use single copy of scaler limits (Matt)
v3:
-move detach_scalers to crtc commit path (Matt)
-use values in plane_state-src as regular integers (me)
v4:
-changes to align with updated scaler structures (Matt, me)
-keep plane src rect in 16.16 format (Matt, Daniel)
Signed-off-by: Chandra Konduru chandra.kond...@intel.com
Ok there's a real functional conflict here now with 90/270 rotation. It's
big enough that imo we also need to add igt coverage to test
rotation+scaling together (the scaled plane setup is different from the
normal one, and we need to also make sure we scale correctly itself when
rotated).
Chandra can you please figure out with Sonika who can do this rebasing/igt
extension?
Thanks, Daniel
---
drivers/gpu/drm/i915/intel_atomic.c |5 +-
drivers/gpu/drm/i915/intel_display.c | 96
--
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_sprite.c |9
4 files changed, 105 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 2fc04ec..8f759c6 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -167,7 +167,7 @@ int intel_atomic_commit(struct drm_device *dev,
plane-state-state = NULL;
}
- /* swap crtc_state */
+ /* swap crtc_scaler_state */
for (i = 0; i dev-mode_config.num_crtc; i++) {
struct drm_crtc *crtc = state-crtcs[i];
if (!crtc) {
@@ -176,6 +176,9 @@ int intel_atomic_commit(struct drm_device *dev,
to_intel_crtc(crtc)-config-scaler_state =
to_intel_crtc_state(state-crtc_states[i])-scaler_state;
+
+ if (INTEL_INFO(dev)-gen = 9)
+ skl_detach_scalers(to_intel_crtc(crtc));
}
drm_atomic_helper_commit_planes(dev, state);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index aa4da1f..c7ee232 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2978,6 +2978,14 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
int pipe = intel_crtc-pipe;
u32 plane_ctl, stride_div;
unsigned long surf_addr;
+ struct intel_crtc_state *crtc_state = intel_crtc-config;
+ struct intel_plane_state *plane_state;
+ int src_x = 0, src_y = 0, src_w = 0, src_h = 0;
+ int dst_x = 0, dst_y = 0, dst_w = 0, dst_h = 0;
+ int scaler_id = -1;
+
+ plane_state = crtc-primary ?
+ to_intel_plane_state(crtc-primary-state) : NULL;
if (!intel_crtc-primary_enabled) {
I915_WRITE(PLANE_CTL(pipe, 0), 0);
@@ -3046,12 +3054,40 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
fb-pixel_format);
surf_addr = intel_plane_obj_offset(to_intel_plane(crtc-primary), obj);
+ if (plane_state) {
+ scaler_id = plane_state-scaler_id;
+ src_x = plane_state-src.x1 16;
+ src_y = plane_state-src.y1 16;
+ src_w = drm_rect_width(plane_state-src) 16;
+ src_h = drm_rect_height(plane_state-src) 16;
+ dst_x = plane_state-dst.x1;
+ dst_y = plane_state-dst.y1;
+ dst_w = drm_rect_width(plane_state-dst);
+ dst_h = drm_rect_height(plane_state-dst);
+ }
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_POS(pipe, 0), 0);
+
+ if (src_w src_h dst_w dst_h scaler_id = 0) {
+ uint32_t ps_ctrl = 0;
+
+ WARN_ON(x != src_x || y != src_y);
+ ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(0) |
+ crtc_state-scaler_state.scalers[scaler_id].mode;
+ I915_WRITE(SKL_PS_CTRL(pipe, scaler_id), ps_ctrl);
+ I915_WRITE(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
+ I915_WRITE(SKL_PS_WIN_POS(pipe, scaler_id), (dst_x 16) |
dst_y);
+ I915_WRITE(SKL_PS_WIN_SZ(pipe, scaler_id), (dst_w 16) |
dst_h);
+
+ I915_WRITE(PLANE_SIZE(pipe, 0), ((src_h - 1) 16) | (src_w -
1));
+ } else {
+ I915_WRITE(PLANE_SIZE(pipe, 0),
+ (intel_crtc-config-pipe_src_h - 1) 16 |
+ (intel_crtc-config-pipe_src_w - 1));
+ }
+
I915_WRITE(PLANE_OFFSET(pipe, 0), (y 16) | x);
- I915_WRITE(PLANE_SIZE(pipe, 0),
-(intel_crtc-config-pipe_src_h - 1) 16 |
-(intel_crtc-config-pipe_src_w - 1));
I915_WRITE(PLANE_STRIDE(pipe, 0), fb-pitches[0] / stride_div);
I915_WRITE(PLANE_SURF(pipe, 0), surf_addr);
@@ -12778,6 +12814,36 @@
Re: [Intel-gfx] [PATCH] drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6186 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -4 276/276 272/276 ILK 301/301 301/301 SNB -22 316/316 294/316 IVB -1 328/328 327/328 BYT 285/285 285/285 HSW 394/394 394/394 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt@gem_userptr_blits@coherency-unsync CRASH(2)PASS(4) CRASH(1)PASS(1) PNV igt@gen3_render_linear_blits FAIL(4)PASS(7) FAIL(1)PASS(1) PNV igt@gen3_render_mixed_blits FAIL(5)PASS(6) FAIL(1)PASS(1) PNV igt@gen3_render_tiledx_blits FAIL(5)PASS(7) FAIL(1)PASS(1) SNB igt@kms_cursor_crc@cursor-size-change NSPT(1)PASS(1) NSPT(2) SNB igt@kms_flip_event_leak NSPT(1)PASS(1) NSPT(2) SNB igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip NSPT(2)PASS(1) NSPT(2) SNB igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip NSPT(2)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@primary-rotation NSPT(2)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@sprite-rotation NSPT(2)PASS(3) NSPT(2) SNB igt@pm_rpm@cursor NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@cursor-dpms NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-mode-unset-non-lpsp NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-non-lpsp NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@drm-resources-equal NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@fences NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@fences-dpms NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-execbuf NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-cpu NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-gtt NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-pread NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@i2c NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp-stress-no-wait NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@pci-d3-state NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@rte NSPT(2)PASS(1) NSPT(2) IVB igt@gem_pwrite_pread@uncached-copy-performance DMESG_WARN(1)PASS(7) DMESG_WARN(1)PASS(1) (dmesg patch applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...blitter_ring_idle@Hangcheck timer elapsed... blitter ring idle Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Kernel panic every other reboot/poweroff since 3.19.3 ( commit 9a6f5130143 )
On 2 April 2015 at 12:02, Jani Nikula jani.nik...@linux.intel.com wrote: On Tue, 31 Mar 2015, Steven Honeyman stevenhoney...@gmail.com wrote: On 31 March 2015 at 17:50, Matt Roper matthew.d.ro...@intel.com wrote: On Tue, Mar 31, 2015 at 08:54:19AM +0200, Daniel Vetter wrote: Adding mailing lists (and hooray for me mixing up addresses, so now there's a disclaimer at the bottom). -Daniel It looks like this is caused by 3.19.3 having commit 77f7ef95e2cf09150e5777454fd5df69af39edcd Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed Feb 25 13:45:26 2015 + drm: Don't assign fbs for universal cursor support to files without also having commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Feb 27 12:58:13 2015 +0100 drm: Fixup racy refcounting in plane_force_disable Can you try cherry-picking 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 and see if it solves the problem? Matt It does! Thanks Matt. 5 successful reboots and a successful shutdown. The only change between the two kernels was the above patch. Stable team, please ensure 8218c3f4df3bb1c637c17552405039a6dd3c1ee1, already tagged cc: stable, is picked up for v3.19.4. Just in case nobody noticed, this did not make it to 3.19.4 patch. Thanks, Steven ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Make integer overflow checking cover universal cursor updates (v2)
Our legacy SetPlane updates perform integer overflow checking on a
plane's destination rectangle in drm_mode_setplane(), and atomic updates
handled as part of a drm_atomic_state transaction do the same checking
in drm_atomic_plane_check(). However legacy cursor updates that get
routed through universal plane interfaces may bypass this overflow
checking if the driver's .update_plane is serviced by the transitional
plane helpers rather than the full atomic plane helpers.
Move the check for destination rectangle integer overflow from the
drm_mode_setplane() to __setplane_internal() so that it also covers
cursor operations.
This fixes an issue first noticed with i915 commit:
commit ff42e093e9c9c17a6e1d6aab24875a36795f926e
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Mon Mar 2 16:35:20 2015 +0100
Revert drm/i915: Switch planes from transitional helpers to full
atomic helpers
The above revert switched us from full atomic helpers back to the
transitional helpers, and in doing so we lost the overflow checking here
for universal cursor updates. Even though such extreme cursor positions
are unlikely to actually happen in the wild, we still don't want there
to be a change of behavior when drivers switch from transitional helpers
to full helpers.
v2: Move check from setplane ioctl to setplane_internal rather than
adding an additional copy of the checks to the transitional plane
helpers. (Daniel)
Cc: Daniel Vetter dan...@ffwll.ch
Testcase: igt/kms_cursor_crc
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84269
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index b914882..160647a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2507,6 +2507,17 @@ static int __setplane_internal(struct drm_plane *plane,
goto out;
}
+ /* Give drivers some help against integer overflows */
+ if (crtc_w INT_MAX ||
+ crtc_x INT_MAX - (int32_t) crtc_w ||
+ crtc_h INT_MAX ||
+ crtc_y INT_MAX - (int32_t) crtc_h) {
+ DRM_DEBUG_KMS(Invalid CRTC coordinates %ux%u+%d+%d\n,
+ crtc_w, crtc_h, crtc_x, crtc_y);
+ return -ERANGE;
+ }
+
+
fb_width = fb-width 16;
fb_height = fb-height 16;
@@ -2591,17 +2602,6 @@ int drm_mode_setplane(struct drm_device *dev, void *data,
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
- /* Give drivers some help against integer overflows */
- if (plane_req-crtc_w INT_MAX ||
- plane_req-crtc_x INT_MAX - (int32_t) plane_req-crtc_w ||
- plane_req-crtc_h INT_MAX ||
- plane_req-crtc_y INT_MAX - (int32_t) plane_req-crtc_h) {
- DRM_DEBUG_KMS(Invalid CRTC coordinates %ux%u+%d+%d\n,
- plane_req-crtc_w, plane_req-crtc_h,
- plane_req-crtc_x, plane_req-crtc_y);
- return -ERANGE;
- }
-
/*
* First, find the plane, crtc, and fb objects. If not available,
* we don't bother to call the driver.
--
1.8.5.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/skl: Add DC5 Trigger Sequence
On Mon, Apr 13, 2015 at 02:33:50PM +0300, Imre Deak wrote:
@@ -424,6 +434,25 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
I915_WRITE(HSW_PWR_WELL_DRIVER, tmp ~req_mask);
POSTING_READ(HSW_PWR_WELL_DRIVER);
DRM_DEBUG_KMS(Disabling %s\n, power_well-name);
+
+ if (GEN9_ENABLE_DC5(dev)
+ power_well-data == SKL_DISP_PW_2) {
+ if (dev_priv-csr.states = FW_LOADING) {
+ /*
+ * TODO: wait for a completion event or
+ * similar here instead of busy
+ * waiting using wait_for function.
+ */
+ if (wait_for(
+ intel_csr_load_status_get(
+ dev_priv), 1000))
+ DRM_ERROR(Timed out waiting
for CSR to be loaded!);
This waits until the state is set to FW_LOADING or FW_FAILED, whereas it
should wait until it's FW_LOADED. I think the above block becomes
clearer by returning the state from the helper:
if (GEN9_ENABLE_DC5(dev) power_well-data == SKL_DISP_PW_2) {
enum csr_state state;
wait_for((state = intel_csr_state(dev_priv)) != FW_UNINITIALIZED, 1000);
if (state != FW_LOADED)
DRM_ERROR(CSR firmware not ready (%d)\n, state);
else
gen9_enable_dc5(dev_priv);
}
Also, this level of indentation is becoming unmanageable. Maybe we
should move this code to skl_power_well_post_enable()?
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Make integer overflow checking cover universal cursor updates (v2)
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6187 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -8 276/276 268/276 ILK 301/301 301/301 SNB -22 316/316 294/316 IVB -1 328/328 327/328 BYT 285/285 285/285 HSW 394/394 394/394 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt@gem_tiled_pread_pwrite PASS(4) FAIL(1)PASS(1) PNV igt@gem_userptr_blits@coherency-sync CRASH(2)PASS(4) CRASH(2) PNV igt@gem_userptr_blits@coherency-unsync CRASH(2)PASS(5) CRASH(2) *PNV igt@gem_userptr_blits@forked-sync-swapping-mempressure-interruptible PASS(2) FAIL(1)PASS(1) PNV igt@gen3_render_linear_blits FAIL(4)PASS(8) FAIL(2) PNV igt@gen3_render_mixed_blits FAIL(5)PASS(7) FAIL(2) PNV igt@gen3_render_tiledx_blits FAIL(5)PASS(8) FAIL(2) PNV igt@gen3_render_tiledy_blits FAIL(4)PASS(7) FAIL(2) SNB igt@kms_cursor_crc@cursor-size-change NSPT(2)PASS(1) NSPT(2) SNB igt@kms_flip_event_leak NSPT(2)PASS(1) NSPT(2) SNB igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip NSPT(3)PASS(1) NSPT(2) SNB igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip NSPT(3)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@primary-rotation NSPT(3)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@sprite-rotation NSPT(3)PASS(3) NSPT(2) SNB igt@pm_rpm@cursor NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@cursor-dpms NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-mode-unset-non-lpsp NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-non-lpsp NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@drm-resources-equal NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@fences NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@fences-dpms NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-execbuf NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-cpu NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-gtt NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-pread NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@i2c NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp-stress-no-wait NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@pci-d3-state NSPT(3)PASS(1) NSPT(2) SNB igt@pm_rpm@rte NSPT(3)PASS(1) NSPT(2) IVB igt@gem_pwrite_pread@uncached-copy-performance DMESG_WARN(1)PASS(8) DMESG_WARN(1)PASS(1) (dmesg patch applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...blitter_ring_idle@Hangcheck timer elapsed... blitter ring idle Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Add a delay in Displayport AUX transactions for compliance testing
2015-04-10 13:12 GMT-03:00 Todd Previte tprev...@gmail.com:
The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
specifies that repeated AUX transactions after a failure (no response /
invalid response) must have a minimum delay of 400us before the resend can
occur. Tests 4.2.1.1 and 4.2.1.2 are two tests that require this specifically.
Also, the check for DP_AUX_CH_CTL_TIME_OUT_ERROR has been moved out into a
separate case. This case just continues with the next iteration of the loop
as the HW has already waited the required amount of time.
V2:
- Changed udelay() to usleep_range()
V3:
- Removed extraneous check for timeout
- Updated comment to reflect this change
V4:
- Reformatted a comment
V5:
- Added separate check for HW timeout on AUX transactions. A message
is logged upon detection of this case.
V6:
- Add continue statement to HW timeout detect case
- Remove the log message indicating a timeout has been
detected (review feedback)
V7:
- Updated the commit message to remove verbage about the HW timeout
case that is no longer valid.
Signed-off-by: Todd Previte tprev...@gmail.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a5dfaff..77b6b15 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -877,9 +877,18 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
DP_AUX_CH_CTL_TIME_OUT_ERROR |
DP_AUX_CH_CTL_RECEIVE_ERROR);
- if (status (DP_AUX_CH_CTL_TIME_OUT_ERROR |
- DP_AUX_CH_CTL_RECEIVE_ERROR))
+ if (status DP_AUX_CH_CTL_TIME_OUT_ERROR)
continue;
+
+ /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 4.2.1.2
+* 400us delay required for errors and timeouts
+* Timeout errors from the HW already meet this
+* requirement so skip to next iteration
+*/
+ if (status DP_AUX_CH_CTL_RECEIVE_ERROR) {
+ usleep_range(400, 500);
+ continue;
+ }
if (status DP_AUX_CH_CTL_DONE)
break;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 02/10] drm/i915/config: Add init-time configuration of bits per color.
Allow the init-time configuration to specify the bits per color value
that gets used if bits per color is not present in EDID data (or if EDID
is not present).
v2: Use connector-base.name for connector name (Jani)
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 97922fb..e50dbbd0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10744,6 +10744,20 @@ connected_sink_compute_bpp(struct intel_connector
*connector,
connector-base.base.id,
connector-base.name);
+ /* If !bpc then see if one was specified in the static configuation */
+ if (connector-base.display_info.bpc == 0) {
+ /*
+* This is making the assumption that the static configuration
+* will use the names defined in the drm_connector_enum_list
+* array to identify the connector.
+*/
+ intel_config_get_integer(to_i915(connector-base.dev),
+ CFG_CONNECTOR,
+ connector-base.name,
+ bits_per_color,
+ connector-base.display_info.bpc);
+ }
+
/* Don't use an invalid EDID bpc value */
if (connector-base.display_info.bpc
connector-base.display_info.bpc * 3 bpp) {
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 01/10] drm/i915/config: Initial framework
This adds an init-time configuration framework that parses configuration
data from an ACPI property table. The table is assumed to have well
defined sub-device property tables that correspond to the various
driver components. Initially the following sub-device tables are
defined:
CRTC (CRTC)
The CRTC sub-device table contains additional sub-device tables
where each one corresponds to a CRTC. Each CRTC sub-device must
include a property called id whose value matches the driver's
crtc id. Additional properties for the CRTC are used to configure
the crtc.
Connector (CNCT)
The CNCT sub-device table contains additional sub-device tables
where each one corresponds to a connector. Each of the connector
sub-device tables must include a property called name whose value
matches a connector name assigned by the driver (see later patch
for output name function). Additional connector properties can
be set through these tables.
Plane (PLNS)
The PLNS sub-device table contains additional sub-device tables
where each one corresponds to a plane. [this needs additional work]
In addition, the main device property table for the device may
contain configuration information that applies to general driver
configuration.
The framework includes a couple of helper functions to access the
configuration data.
intel_config_get_integer() will look up a configuration property
and return the integer value associated with it.
intel_config_init_component_property() will look up a
configuration property and assign the value to a drm
property of the same name. These functions are used to
initialize drm property instances to specific values.
v2: Add plane/connector properties to proper lists. (Bob)
Abstract out the list cleanup (Jani)
Squash patch that abstracted list allocation (Jani)
Use module parameter for firmware file if it exist (Jani)
Use defined name to access table handle (Bob)
Remove the acpi table bind/unbind (Bob)
Make firmware struct part of the config (Bob)
Release firmware on shutdown (Bob)
Free allocated intel_config_info on shutdown (Bob)
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_dma.c | 4 +
drivers/gpu/drm/i915/i915_drv.h | 17 ++
drivers/gpu/drm/i915/i915_params.c | 6 +
drivers/gpu/drm/i915/intel_config.c | 558
drivers/gpu/drm/i915/intel_drv.h| 27 ++
6 files changed, 614 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_config.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index a69002e..2c30112 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -12,7 +12,8 @@ i915-y := i915_drv.o \
i915_suspend.o \
i915_sysfs.o \
intel_pm.o \
- intel_runtime_pm.o
+ intel_runtime_pm.o \
+ intel_config.o
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index e44116f..e18dac2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -803,6 +803,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
dev-dev_private = dev_priv;
dev_priv-dev = dev;
+ intel_config_init(dev);
+
/* Setup the write-once constant device info */
device_info = (struct intel_device_info *)dev_priv-info;
memcpy(device_info, info, sizeof(dev_priv-info));
@@ -1078,6 +1080,8 @@ int i915_driver_unload(struct drm_device *dev)
intel_fbdev_fini(dev);
+ intel_config_shutdown(dev);
+
drm_vblank_cleanup(dev);
intel_modeset_cleanup(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 79da7f3..1484439 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1557,6 +1557,21 @@ struct i915_virtual_gpu {
bool active;
};
+struct intel_config_node {
+ struct acpi_device *adev;
+ struct list_head node;
+ struct list_head list;
+};
+
+struct intel_config_info {
+ const struct firmware *fw;
+ struct intel_config_node base;
+ struct list_head crtc_list;
+ struct list_head connector_list;
+ struct list_head plane_list;
+};
+
+
struct drm_i915_private {
struct drm_device *dev;
struct kmem_cache *objects;
@@ -1800,6 +1815,7 @@ struct drm_i915_private {
u32 long_hpd_port_mask;
u32 short_hpd_port_mask;
struct work_struct dig_port_work;
+ struct intel_config_info *config_info;
/*
* if we get a HPD irq from DP and a HPD irq from non-DP
@@ -2477,6 +2493,7 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
+ char
[Intel-gfx] [RFC 06/10] drm/i915/config: Add init-time configuration of eDP PPS delays.
Allow the configuration file to overide the various panel power sequence delay values. Signed-off-by: Bob Paauwe bob.j.paa...@intel.com --- drivers/gpu/drm/i915/intel_dp.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index b05ff6d..7defb3a 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -5565,6 +5565,20 @@ intel_dp_init_connector(struct intel_digital_port *intel_dig_port, else intel_dp_init_panel_power_sequencer(dev, intel_dp); pps_unlock(intel_dp); + + /* Check for config overides for PPS delays */ +#define CONFIG_PANEL_POWER_DELAY(delay_name) \ + intel_config_get_integer(dev_priv, CFG_CONNECTOR, \ +intel_dp-attached_connector-base.name, \ +#delay_name, \ +(uint32_t *)intel_dp-pps_delays.delay_name) + + CONFIG_PANEL_POWER_DELAY(t1_t3); + CONFIG_PANEL_POWER_DELAY(t8); + CONFIG_PANEL_POWER_DELAY(t9); + CONFIG_PANEL_POWER_DELAY(t10); + CONFIG_PANEL_POWER_DELAY(t11_t12); +#undef CONFIG_PANEL_POWER_DELAY } intel_dp_aux_init(intel_dp, intel_connector); -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 10/10] drm/i915/config: An example/test ACPI property table.
This is an example of what an ACPI property table looks like.
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/i915-properties.asl | 167 +++
1 file changed, 167 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915-properties.asl
diff --git a/drivers/gpu/drm/i915/i915-properties.asl
b/drivers/gpu/drm/i915/i915-properties.asl
new file mode 100644
index 000..e97ac2e
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915-properties.asl
@@ -0,0 +1,167 @@
+DefinitionBlock (i915-properties.aml, SSDT, 5, , , 0x0001)
+{
+ External (DSEN)
+
+ Device (\_SB.PRP) {
+ Device(GFX0) {
+ Name (_ADR, 0x0002)
+ Name (_HID, PRP)
+
+ Method (_DOS, 1, NotSerialized) {
+ Store (And (Arg0, 0x07), DSEN)
+ If (LEqual (And (Arg0, 0x03), Zero)) {
+ }
+ }
+
+ Name (_DSD, Package() {
+ ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
+ Package () {
+ Package() {display_detect, 1},
+ Package() {fastboot, 1},
+ Package() {powersave, 0},
+ Package() {count, 99},
+ }
+ })
+
+ Device (CRTC) {
+ Name (_HID, PRP)
+ Name (_DSD, Package() {
+ ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
+ Package () {
+ Package() { enabled, 3 },
+ Package() { count, 3 }
+ }
+ })
+
+ Device (ID0) {
+ Name (_HID, PRP)
+ Name (_DSD, Package() {
+
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
+ Package () {
+ Package() { id, 0 },
+ Package() { canvas_color,
Package() { 0, 0, 0 } },
+ Package() { blend_equ, 0 },
+ Package() { enabled, 1 }
+ }
+ })
+ }
+
+ Device (ID1) {
+ Name (_HID, PRP)
+ Name (_DSD, Package() {
+
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
+ Package () {
+ Package() { id, 1 },
+ Package() { canvas_color,
Package() { 0, 0, 0 } },
+ Package() { blend_equ, 0 },
+ Package() { enabled, 1 }
+ }
+ })
+ }
+
+ Device (ID2) {
+ Name (_HID, PRP)
+ Name (_DSD, Package() {
+
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
+ Package () {
+ Package() { id, 2 },
+ Package() { canvas_color,
Package() { 0, 0, 0 } },
+ Package() { blend_equ, 0 },
+ Package() { enabled, 1 }
+ }
+ })
+ }
+ }
+
+ Device (PLNS) {
+ Name (_HID, PRP)
+ Name (_DSD, Package() {
+ ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
+ Package () {
+ Package() { count, 2 }
+ }
+ })
+
+ Device (PL0) {
+ Name (_HID, PRP)
+ Name (_DSD, Package() {
+
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
+ Package () {
+ Package () { gamma, 1 },
+ Package () { color-key,
0x },
+ }
+ })
+ }
+
+ Device (PL1) {
+ Name (_HID, PRP)
+
[Intel-gfx] [RFC 03/10] drm/i915/config: Add init-time configuration of general connector properties.
Set the initial value of the force audio and broadcast rgb properties
using property values found in the init-time configuration.
v2: Use drm connector name (Jani)
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/intel_modes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_modes.c
b/drivers/gpu/drm/i915/intel_modes.c
index 0e860f3..2366d86 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -96,7 +96,7 @@ intel_attach_force_audio_property(struct drm_connector
*connector)
dev_priv-force_audio_property = prop;
}
- drm_object_attach_property(connector-base, prop, 0);
+ intel_config_init_connector_property(connector, prop, 0);
}
static const struct drm_prop_enum_list broadcast_rgb_names[] = {
@@ -124,5 +124,5 @@ intel_attach_broadcast_rgb_property(struct drm_connector
*connector)
dev_priv-broadcast_rgb_property = prop;
}
- drm_object_attach_property(connector-base, prop, 0);
+ intel_config_init_connector_property(connector, prop, 0);
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 09/10] drm/i915: Add backlight max and level to debugfs output.
To allow us to verify the current backlight max and level values. Signed-off-by: Bob Paauwe bob.j.paa...@intel.com --- drivers/gpu/drm/i915/i915_debugfs.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index a9b96fd..2bac3bc 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2652,6 +2652,11 @@ static void intel_dp_info(struct seq_file *m, intel_dp-pps_delays.t10); seq_printf(m, \tpanel power cycle delay: %d\n, intel_dp-pps_delays.t11_t12); + seq_printf(m, \tpanel backlight max: %d\n, + intel_connector-panel.backlight.max); + seq_printf(m, \tpanel backlight level: %d\n, + intel_connector-panel.backlight.level); + intel_panel_info(m, intel_connector-panel); } } -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 04/10] drm/i915/config: Add init-time configuration of dp panel fitter property.
Use the init-time configuration setting for scaling_mode to set the
initial value of the scaling_mode connector property.
v2: Use drm connector name (Jani)
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 14cdd00..b6944b9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4785,6 +4785,7 @@ void
intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector
*connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
+ uint64_t fitting_mode;
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
@@ -4792,11 +4793,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
if (is_edp(intel_dp)) {
drm_mode_create_scaling_mode_property(connector-dev);
- drm_object_attach_property(
- connector-base,
+ fitting_mode = intel_config_init_connector_property(
+ connector,
connector-dev-mode_config.scaling_mode_property,
DRM_MODE_SCALE_ASPECT);
- intel_connector-panel.fitting_mode = DRM_MODE_SCALE_ASPECT;
+ intel_connector-panel.fitting_mode = (int)fitting_mode;
}
}
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 08/10] drm/i915: Add PPS delay values to debugfs.
So that we verify which values are currently in use.
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2394924..a9b96fd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2641,8 +2641,19 @@ static void intel_dp_info(struct seq_file *m,
seq_printf(m, \tDPCD rev: %x\n, intel_dp-dpcd[DP_DPCD_REV]);
seq_printf(m, \taudio support: %s\n, intel_dp-has_audio ? yes :
no);
- if (intel_encoder-type == INTEL_OUTPUT_EDP)
+ if (intel_encoder-type == INTEL_OUTPUT_EDP) {
+ seq_printf(m, \tpanel power on delay: %d\n,
+ intel_dp-pps_delays.t1_t3);
+ seq_printf(m, \tpanel backlight on delay: %d\n,
+ intel_dp-pps_delays.t8);
+ seq_printf(m, \tpanel backlight off delay: %d\n,
+ intel_dp-pps_delays.t9);
+ seq_printf(m, \tpanel power off delay: %d\n,
+ intel_dp-pps_delays.t10);
+ seq_printf(m, \tpanel power cycle delay: %d\n,
+ intel_dp-pps_delays.t11_t12);
intel_panel_info(m, intel_connector-panel);
+ }
}
static void intel_hdmi_info(struct seq_file *m,
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 07/10] drm/i915/config: Add init-time configuration of eDP backlight settings.
Allow the configuration file to overide the backlight max and level settings. Signed-off-by: Bob Paauwe bob.j.paa...@intel.com --- drivers/gpu/drm/i915/intel_panel.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index d8686ce..54c8cef 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1326,6 +1326,14 @@ int intel_panel_setup_backlight(struct drm_connector *connector, enum pipe pipe) return ret; } + /* Allow config to overide backlight settings */ + intel_config_get_integer(dev_priv, CFG_CONNECTOR, +connector-name, backlight maximum, +panel-backlight.max); + intel_config_get_integer(dev_priv, CFG_CONNECTOR, +connector-name, backlight level, +panel-backlight.level); + panel-backlight.present = true; DRM_DEBUG_KMS(Connector %s backlight initialized, %s, brightness %u/%u\n, -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 00/10] i915 init-time configuration (v2)
Background: This capability is targeted at deeply embedded appliance like devices that make use of Intel integrated graphics. There are a few use cases that are not currently supported by the i915 driver. For example, they may not be running user space code that is capable of querying and setting the various DRM properties and would like them set during the driver initialization. Also they may be using a custom firmware bootloader that does not include any graphics initialization or VBT information. This level of initialization configuration has been available in the Intel EMGD kernel driver and a similar level of configurability will be expected as designs transition to the i915 driver. This patch set provides a framework that makes use of ACPI property tables containing configuration information. It also includes some examples on how this may be applied to various aspects of the i915 driver initialization. V2 removes the support for replacing the internal workaround list and the support for overriding the VBT values. Instead there are patches to configure the specific items that the EMGD kernel driver currently allows customers to override. There are also patches to make the values of those items available via debugfs. I've also removed the code that embeds an ACPI property table into the driver as the ACPICA code doesn't really support loading and unloading a table like this and would fail after a couple of driver load/unload cycles. Series description: Patch 1 is the framework. It loads the ACPI property table and builds some lists containing the configuration found in that table. There are functions for looking up and applying the configuration. Patch 2 checks for a CRTC bits-per-color configuration and uses that if EDID does not provide the value. Patch 3 replaces the attach_property function with a call to a configuration function that can override the default property value with one from the configuration table. Patch 4 is an example of using the configuration to specify a default value for the DP panel fitter property. Patch 5 allows the configuration table to override the DP max link rate value. Patch 6 allows the configuration table to override the eDP panel power sequence delay values. Patch 7 allows the configuration table to override the eDP backlight max (inverter frequency) and level (duty cycle) values. Patch 8 adds the eDP panel power sequence values to the debugfs output (i915_display_info) Patch 9 adds the eDP backlight values to the debugfs output (i915_display_info) Patch 10 is an example ACPI property table to give some context to the above code. It can be compiled and placed in /lib/firmware/drm_i915.aml for testing the code. Bob Paauwe (10): drm/i915/config: Initial framework drm/i915/config: Add init-time configuration of bits per color. drm/i915/config: Add init-time configuration of general connector properties. drm/i915/config: Add init-time configuration of dp panel fitter property. drm/i915/config: Add init-time configuration of DP max link rate. drm/i915/config: Add init-time configuration of eDP PPS delays. drm/i915/config: Add init-time configuration of eDP backlight settings. drm/i915: Add PPS delay values to debugfs. drm/i915: Add backlight max and level to debugfs output. drm/i915/config: An example/test ACPI property table. drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915-properties.asl | 167 + drivers/gpu/drm/i915/i915_debugfs.c | 18 +- drivers/gpu/drm/i915/i915_dma.c | 4 + drivers/gpu/drm/i915/i915_drv.h | 17 + drivers/gpu/drm/i915/i915_params.c | 6 + drivers/gpu/drm/i915/intel_config.c | 558 +++ drivers/gpu/drm/i915/intel_display.c | 14 + drivers/gpu/drm/i915/intel_dp.c | 36 +- drivers/gpu/drm/i915/intel_drv.h | 27 ++ drivers/gpu/drm/i915/intel_modes.c | 4 +- drivers/gpu/drm/i915/intel_panel.c | 8 + 12 files changed, 852 insertions(+), 10 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915-properties.asl create mode 100644 drivers/gpu/drm/i915/intel_config.c -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 05/10] drm/i915/config: Add init-time configuration of DP max link rate.
If the sink does not provide a maximum link rate, then check the
connector configuration before defaulting to the lowest allowed
link rate.
Signed-off-by: Bob Paauwe bob.j.paa...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b6944b9..b05ff6d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -129,6 +129,9 @@ static int
intel_dp_max_link_bw(struct intel_dp *intel_dp)
{
int max_link_bw = intel_dp-dpcd[DP_MAX_LINK_RATE];
+ int cfg_max_link_bw = DP_LINK_BW_1_62;
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
switch (max_link_bw) {
case DP_LINK_BW_1_62:
@@ -136,9 +139,15 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp)
case DP_LINK_BW_5_4:
break;
default:
- WARN(1, invalid max DP link bw val %x, using 1.62Gbps\n,
-max_link_bw);
- max_link_bw = DP_LINK_BW_1_62;
+ intel_config_get_integer(to_i915(dev),
+CFG_CONNECTOR,
+
intel_dp-attached_connector-base.name,
+Maximum DPCD Rate,
+cfg_max_link_bw);
+
+ WARN(1, invalid max DP link bw val %x, using %x\n,
+max_link_bw, cfg_max_link_bw);
+ max_link_bw = cfg_max_link_bw;
break;
}
return max_link_bw;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/13] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
2015-04-13 11:53 GMT-03:00 Todd Previte tprev...@gmail.com:
Displayport compliance test 4.2.2.6 requires that a source device be capable
of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.
Unfortunately, the DRM EDID reading and parsing functions are actually too
good
in this case; the header is fixed before the checksum is computed and thus the
code never sees the invalid checksum. This results in a failure to pass the
compliance test.
To correct this issue, a checksum is generated when the EDID header is
detected
as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
logs the errors. In the case of a more seriously damaged header (fixup score
less than the threshold) the code does not generate the checksum but does set
the header_corrupt flag.
V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
Signed-off-by: Todd Previte tprev...@gmail.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c| 31 ++-
drivers/gpu/drm/drm_edid_load.c | 7 +--
drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 2 +-
include/drm/drm_crtc.h| 8 +++-
5 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..12e5be7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1005,7 +1005,6 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
for (i = 0; i sizeof(edid_header); i++)
if (raw_edid[i] == edid_header[i])
score++;
-
return score;
}
EXPORT_SYMBOL(drm_edid_header_is_valid);
Bad chunk...
@@ -1047,7 +1046,8 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
*
* Return: True if the block is valid, false otherwise.
*/
-bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
+bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
+ bool *header_corrupt)
Need to add the new parameter description to the documentation above.
{
u8 csum;
struct edid *edid = (struct edid *)raw_edid;
@@ -1062,9 +1062,27 @@ bool drm_edid_block_valid(u8 *raw_edid, int block,
bool print_bad_edid)
int score = drm_edid_header_is_valid(raw_edid);
if (score == 8) ;
else if (score = edid_fixup) {
+ /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
+* In order to properly generate the invalid checksum
+* required for this test, it must be generated using
+* the raw EDID data. Otherwise, the fix-up code here
+* will correct the problem, the checksum is then
correct
+* and the test fails
+*/
+ csum = drm_edid_block_checksum(raw_edid);
+ if (csum) {
+ DRM_DEBUG_DRIVER(Invalid EDID header, score
= %d\n, score);
+ DRM_DEBUG_DRIVER(Invalid EDID checksum
%d\n, csum);
No one on this file uses DRM_DEBUG_DRIVER (you use 2 calls here and one below).
Also, during normal operation we try to calculate the checksum based
on the fixed EDID header, so if we also print these messages here
we're always going to have a message complaining about invalid
checksum: either this one or the other that's already there. My
bikeshed would be to just remove the messages you added here and below
to not confuse users. Let's assume that the bad header is due to some
communication/corruption error, and the HW manufacturers did not
program an EDID with a bad header and a correct checksum based on bad
header :)
+ if (header_corrupt)
+
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable PSR by default.
Another questions, Are you using powertop --auto-tune? If so, can you please try to repdoruce X slowness issue on these 2 scenarios: 1. without doing the powertop auto-tune and psr enabled. 2. with powertop auto-tune but with PSR disabled by i915.enable_psr=0 Thanks in advance, Rodrigo. On Mon, Apr 13, 2015 at 4:09 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote: Hi Matthew, Could you please check if you can reproduce your issue using this branch: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=intel_psr Also, 1. What Platform are you using? BDW? 2. What desktop environment do you use? 3. What is your resolution? 4. Is IPS running? 5. Could you please grab dmesg with drm.debug=0xe? 6. Could you please paste a sequence of cat /sys/kernel/debug/dri/0/i915_edp_psr_status when facing the fbcon and X issues? Thanks in advance, Rodrigo. On Fri, Apr 10, 2015 at 3:05 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I'm seeing the same behaviour with this patchset. After boot, X works fine but I get a rolling display on fbcon (the contents appear to be moving horizontally very quickly around the middle of the screen). If the screen is turned off and on again, X now only updates the screen once every second or so but fbcon works. If I suspend and resume, things go back to the working state until the next screen power cycle. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ 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/skl: Support for 90/270 rotation
On Mon, Apr 13, 2015 at 01:49:22PM +0300, Ville Syrjälä wrote:
On Mon, Apr 13, 2015 at 03:53:22PM +0530, Jindal, Sonika wrote:
On 4/13/2015 3:40 PM, Ville Syrjälä wrote:
On Mon, Apr 13, 2015 at 09:36:02AM +0530, Jindal, Sonika wrote:
On 4/10/2015 8:14 PM, Ville Syrjälä wrote:
On Fri, Apr 10, 2015 at 04:17:17PM +0200, Daniel Vetter wrote:
On Fri, Apr 10, 2015 at 02:37:29PM +0530, Sonika Jindal wrote:
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding
check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_*
for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Patches are missing the Testcase: tag, please add that. Also, are all
the
igt committed or not yet? Pulled these two in meanwhile.
Things are going somewhat broken because you didn't apply my plane
state stuff. Hmm. Actually it sort of looks that it might work by luck
as long as the primary plane doesn't get clipped since this is bashing
the user state directly into the hardware registers and not the derived
state (ie. clipped coordinates).
I was hoping your changes get merged, but not sure why they are held up.
Also I see my review comment about the 90 vs. 270 rotation mixup was
ignored at least.
I never really got the to understand the need of reversing 90 and 270 :)
The last discussion was not concluded, AFAIR.
Things look correct to me and work fine with the testcase also.
Is there something completely different which I am unable to get?
BSpec gives me the impression the hw rotation is cw, whereas the drm one
is ccw.
Yes, HW rotation is cw as per bspec. In drm, where do we consider it as
anti-cw? I assume it is cw because all the macros work as expected, ie cw.
The ccw rule was inherited from XRandR. I'm not sure what macros you
mean, but drm_rect_rotate() will certainly give you wrong results if
you assume cw.
It seems like this information needs to be added to the property section
of the DRM DocBook; continuing to follow XRandR probably makes sense if
that's what's agreed on, but there's no indication of that design
philosophy in the actual DRM documentation today, so we're in danger of
having different driver authors use conflicting interpretations.
90/270 rotation is already supported by existing drivers (omap for
several years now and atmel-hlcdc just recently). I think it's too late
to try to redefine the meaning of rotation property values that are
already in active use, so we probably need to check whether omap is
using a cw or ccw scheme and follow (and document!) that.
Matt
-Sonika
-Daniel
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 24
drivers/gpu/drm/i915/intel_display.c | 88
-
drivers/gpu/drm/i915/intel_drv.h |6 ++
drivers/gpu/drm/i915/intel_sprite.c | 52 -
5 files changed, 131 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..564bbd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4854,7 +4854,9 @@ enum skl_disp_power_wells {
#define PLANE_CTL_ALPHA_HW_PREMULTIPLY ( 3 4)
#define PLANE_CTL_ROTATE_MASK0x3
#define PLANE_CTL_ROTATE_0 0x0
+#define PLANE_CTL_ROTATE_900x1
#define PLANE_CTL_ROTATE_180 0x2
+#define PLANE_CTL_ROTATE_270 0x3
#define _PLANE_STRIDE_1_A 0x70188
#define _PLANE_STRIDE_2_A 0x70288
#define _PLANE_STRIDE_3_A 0x70388
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..a27ee8c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -162,6 +162,30 @@ static int intel_plane_atomic_check(struct
drm_plane *plane,
(1 drm_plane_index(plane));
}
+ if (state-fb intel_rotation_90_or_270(state-rotation)) {
+ if (!(state-fb-modifier[0] == I915_FORMAT_MOD_Y_TILED
||
+ state-fb-modifier[0] ==
I915_FORMAT_MOD_Yf_TILED)) {
+
Re: [Intel-gfx] [PATCH 1/7] drm/i915: PSR: Remove wrong LINK_DISABLE.
On Thu, Apr 9, 2015 at 10:42 AM, Matthew Garrett mj...@srcf.ucam.org wrote: I've put this patchset on top of current Linus git. Switching to fbcon tends to result in rolling graphics, and turning the screen back on often gives me a static display or one that only updates every few seconds. This is with a Dell XPS 13 with Broadwell-U and a 3200x1800 display. Could you please boot this env with i915.enable_ips=0 and try to reproduce the issue? -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Contact] Graphics Driver for Broadwell-H CPU
Ubuntu 15.04 which will be released at the end of this month should support Broadwell-H. Ubuntu 15.04 beta still couldn’t support Broadwell-H. Several days ago, I run Kernel 3.19.3 and xf86-video-intel – 2.99.917 on BDW-H. thanks From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Heah, Jim Poh Sent: Tuesday, April 14, 2015 10:34 AM To: intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] FW: [Contact] Graphics Driver for Broadwell-H CPU Hi, I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.commailto:jim.poh.h...@intel.com From: Chacn Limn, DanielX Sent: Tuesday, April 14, 2015 1:08 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim Poh, Please contact The Linux Graphics team in this e-mail: intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org You can also reach them through IRC in: #intel-...@freenode.netirc://freenode.net/#intel-gfx. Please let us know of anything else we can help you with. Regards, Daniel. -Original Message- From: Heah, Jim Poh Sent: Monday, April 13, 2015 12:52 AM To: Chacn Limn, DanielX Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael; Heah, Jim Poh Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Yes I am using drivers from 01.org/linuxgraphics. I tested with version 1.0.8. The CPU I am testing with is not a production CPU but an engineering sample. Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.commailto:jim.poh.h...@intel.com -Original Message- From: Chacn Limn, DanielX Sent: Friday, April 10, 2015 12:52 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim, Are you using drivers from the Downloads section of this site? https://01.org/linuxgraphics/ Please provide more details on where did you get the drivers and what version are you testing. Thanks in advance, Daniel. -Original Message- From: Becerra Ruiz, Lilia Sent: Wednesday, April 8, 2015 10:45 AM To: Chacn Limn, DanielX Subject: FW: [Contact] Graphics Driver for Broadwell-H CPU Me dices si necesitas ayuda con este -Original Message- From: webmas...@01.orgmailto:webmas...@01.org [mailto:webmas...@01.org] On Behalf Of jim.poh.h...@intel.commailto:jim.poh.h...@intel.com Sent: Tuesday, April 7, 2015 9:47 PM To: Becerra Ruiz, Lilia; Fuller, Michael; Flores Perez, Jimena; Chacn Limn, DanielX Subject: [Contact] Graphics Driver for Broadwell-H CPU Jim Poh Heah (jim.poh.h...@intel.commailto:jim.poh.h...@intel.com) sent a message using the contact form at https://01.org/about/contact-us. I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Report as inappropriate: https://01.org/mollom/report/mollom_captcha/150408dcde5193daa4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Enable PSR by default.
Hi Matthew, Could you please check if you can reproduce your issue using this branch: http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=intel_psr Also, 1. What Platform are you using? BDW? 2. What desktop environment do you use? 3. What is your resolution? 4. Is IPS running? 5. Could you please grab dmesg with drm.debug=0xe? 6. Could you please paste a sequence of cat /sys/kernel/debug/dri/0/i915_edp_psr_status when facing the fbcon and X issues? Thanks in advance, Rodrigo. On Fri, Apr 10, 2015 at 3:05 PM, Matthew Garrett mj...@srcf.ucam.org wrote: I'm seeing the same behaviour with this patchset. After boot, X works fine but I get a rolling display on fbcon (the contents appear to be moving horizontally very quickly around the middle of the screen). If the screen is turned off and on again, X now only updates the screen once every second or so but fbcon works. If I suspend and resume, things go back to the working state until the next screen power cycle. -- Matthew Garrett | mj...@srcf.ucam.org ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] FW: [Contact] Graphics Driver for Broadwell-H CPU
Hi, I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | mailto:jim.poh.h...@intel.com jim.poh.h...@intel.com From: Chacn Limn, DanielX Sent: Tuesday, April 14, 2015 1:08 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim Poh, Please contact The Linux Graphics team in this e-mail: intel-gfx@lists.freedesktop.org mailto:intel-gfx@lists.freedesktop.org You can also reach them through IRC in: #intel-...@freenode.net irc://freenode.net/#intel-gfx . Please let us know of anything else we can help you with. Regards, Daniel. -Original Message- From: Heah, Jim Poh Sent: Monday, April 13, 2015 12:52 AM To: Chacn Limn, DanielX Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael; Heah, Jim Poh Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Yes I am using drivers from 01.org/linuxgraphics. I tested with version 1.0.8. The CPU I am testing with is not a production CPU but an engineering sample. Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com -Original Message- From: Chacn Limn, DanielX Sent: Friday, April 10, 2015 12:52 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim, Are you using drivers from the Downloads section of this site? https://01.org/linuxgraphics/ Please provide more details on where did you get the drivers and what version are you testing. Thanks in advance, Daniel. -Original Message- From: Becerra Ruiz, Lilia Sent: Wednesday, April 8, 2015 10:45 AM To: Chacn Limn, DanielX Subject: FW: [Contact] Graphics Driver for Broadwell-H CPU Me dices si necesitas ayuda con este -Original Message- From: webmas...@01.org mailto:webmas...@01.org [mailto:webmas...@01.org] On Behalf Of jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com Sent: Tuesday, April 7, 2015 9:47 PM To: Becerra Ruiz, Lilia; Fuller, Michael; Flores Perez, Jimena; Chacn Limn, DanielX Subject: [Contact] Graphics Driver for Broadwell-H CPU Jim Poh Heah (jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com ) sent a message using the contact form at https://01.org/about/contact-us. I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Report as inappropriate: https://01.org/mollom/report/mollom_captcha/150408dcde5193daa4 smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Contact] Graphics Driver for Broadwell-H CPU
Thanks Xiong, What about Fedora? Are there any plans for Fedora? Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | mailto:jim.poh.h...@intel.com jim.poh.h...@intel.com From: Zhang, Xiong Y Sent: Tuesday, April 14, 2015 10:57 AM To: Heah, Jim Poh; intel-gfx@lists.freedesktop.org Cc: Zhang, Xiong Y Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Ubuntu 15.04 which will be released at the end of this month should support Broadwell-H. Ubuntu 15.04 beta still couldn’t support Broadwell-H. Several days ago, I run Kernel 3.19.3 and xf86-video-intel – 2.99.917 on BDW-H. thanks From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Heah, Jim Poh Sent: Tuesday, April 14, 2015 10:34 AM To: intel-gfx@lists.freedesktop.org mailto:intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] FW: [Contact] Graphics Driver for Broadwell-H CPU Hi, I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | mailto:jim.poh.h...@intel.com jim.poh.h...@intel.com From: Chacn Limn, DanielX Sent: Tuesday, April 14, 2015 1:08 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim Poh, Please contact The Linux Graphics team in this e-mail: intel-gfx@lists.freedesktop.org mailto:intel-gfx@lists.freedesktop.org You can also reach them through IRC in: #intel-...@freenode.net irc://freenode.net/#intel-gfx . Please let us know of anything else we can help you with. Regards, Daniel. -Original Message- From: Heah, Jim Poh Sent: Monday, April 13, 2015 12:52 AM To: Chacn Limn, DanielX Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael; Heah, Jim Poh Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Yes I am using drivers from 01.org/linuxgraphics. I tested with version 1.0.8. The CPU I am testing with is not a production CPU but an engineering sample. Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com -Original Message- From: Chacn Limn, DanielX Sent: Friday, April 10, 2015 12:52 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim, Are you using drivers from the Downloads section of this site? https://01.org/linuxgraphics/ Please provide more details on where did you get the drivers and what version are you testing. Thanks in advance, Daniel. -Original Message- From: Becerra Ruiz, Lilia Sent: Wednesday, April 8, 2015 10:45 AM To: Chacn Limn, DanielX Subject: FW: [Contact] Graphics Driver for Broadwell-H CPU Me dices si necesitas ayuda con este -Original Message- From: webmas...@01.org mailto:webmas...@01.org [mailto:webmas...@01.org] On Behalf Of jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com Sent: Tuesday, April 7, 2015 9:47 PM To: Becerra Ruiz, Lilia; Fuller, Michael; Flores Perez, Jimena; Chacn Limn, DanielX Subject: [Contact] Graphics Driver for Broadwell-H CPU Jim Poh Heah (jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com ) sent a message using the contact form at https://01.org/about/contact-us. I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Report as inappropriate: https://01.org/mollom/report/mollom_captcha/150408dcde5193daa4 smime.p7s Description: S/MIME cryptographic signature ___ 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/skl: Support for 90/270 rotation
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6170 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 270/270 270/270 ILK 303/303 303/303 SNB -21 304/304 283/304 IVB 337/337 337/337 BYT -1 287/287 286/287 HSW 361/361 361/361 BDW 309/309 309/309 -Detailed- Platform Testdrm-intel-nightly Series Applied SNB igt@kms_cursor_crc@cursor-size-change NSPT(2)PASS(1) NSPT(2) SNB igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip NSPT(2)PASS(1) NSPT(2) SNB igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip NSPT(2)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@primary-rotation NSPT(2)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@sprite-rotation NSPT(2)PASS(3) NSPT(2) SNB igt@pm_rpm@cursor NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@cursor-dpms NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-mode-unset-non-lpsp NSPT(2)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-non-lpsp NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@drm-resources-equal NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@fences NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@fences-dpms NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-execbuf NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-cpu NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-gtt NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-pread NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@i2c NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp-stress-no-wait NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@pci-d3-state NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@rte NSPT(1)PASS(1) NSPT(2) *BYT igt@gem_exec_bad_domains@conflicting-write-domain PASS(2) FAIL(1)PASS(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Contact] Graphics Driver for Broadwell-H CPU
I don’t know the status of Fedora. You could compile upstream 3.19.3 / 4.0 kernel and xf86-video-intel – 2.99.917 in Fedora. thanks From: Heah, Jim Poh Sent: Tuesday, April 14, 2015 12:38 PM To: Zhang, Xiong Y; intel-gfx@lists.freedesktop.org Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Thanks Xiong, What about Fedora? Are there any plans for Fedora? Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.commailto:jim.poh.h...@intel.com From: Zhang, Xiong Y Sent: Tuesday, April 14, 2015 10:57 AM To: Heah, Jim Poh; intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org Cc: Zhang, Xiong Y Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Ubuntu 15.04 which will be released at the end of this month should support Broadwell-H. Ubuntu 15.04 beta still couldn’t support Broadwell-H. Several days ago, I run Kernel 3.19.3 and xf86-video-intel – 2.99.917 on BDW-H. thanks From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Heah, Jim Poh Sent: Tuesday, April 14, 2015 10:34 AM To: intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] FW: [Contact] Graphics Driver for Broadwell-H CPU Hi, I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.commailto:jim.poh.h...@intel.com From: Chacn Limn, DanielX Sent: Tuesday, April 14, 2015 1:08 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim Poh, Please contact The Linux Graphics team in this e-mail: intel-gfx@lists.freedesktop.orgmailto:intel-gfx@lists.freedesktop.org You can also reach them through IRC in: #intel-...@freenode.netirc://freenode.net/#intel-gfx. Please let us know of anything else we can help you with. Regards, Daniel. -Original Message- From: Heah, Jim Poh Sent: Monday, April 13, 2015 12:52 AM To: Chacn Limn, DanielX Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael; Heah, Jim Poh Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Yes I am using drivers from 01.org/linuxgraphics. I tested with version 1.0.8. The CPU I am testing with is not a production CPU but an engineering sample. Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.commailto:jim.poh.h...@intel.com -Original Message- From: Chacn Limn, DanielX Sent: Friday, April 10, 2015 12:52 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim, Are you using drivers from the Downloads section of this site? https://01.org/linuxgraphics/ Please provide more details on where did you get the drivers and what version are you testing. Thanks in advance, Daniel. -Original Message- From: Becerra Ruiz, Lilia Sent: Wednesday, April 8, 2015 10:45 AM To: Chacn Limn, DanielX Subject: FW: [Contact] Graphics Driver for Broadwell-H CPU Me dices si necesitas ayuda con este -Original Message- From: webmas...@01.orgmailto:webmas...@01.org [mailto:webmas...@01.org] On Behalf Of jim.poh.h...@intel.commailto:jim.poh.h...@intel.com Sent: Tuesday, April 7, 2015 9:47 PM To: Becerra Ruiz, Lilia; Fuller, Michael; Flores Perez, Jimena; Chacn Limn, DanielX Subject: [Contact] Graphics Driver for Broadwell-H CPU Jim Poh Heah (jim.poh.h...@intel.commailto:jim.poh.h...@intel.com) sent a message using the contact form at https://01.org/about/contact-us. I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Report as inappropriate: https://01.org/mollom/report/mollom_captcha/150408dcde5193daa4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Contact] Graphics Driver for Broadwell-H CPU
Thanks! Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | mailto:jim.poh.h...@intel.com jim.poh.h...@intel.com From: Zhang, Xiong Y Sent: Tuesday, April 14, 2015 12:45 PM To: Heah, Jim Poh; intel-gfx@lists.freedesktop.org Cc: Zhang, Xiong Y Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU I don’t know the status of Fedora. You could compile upstream 3.19.3 / 4.0 kernel and xf86-video-intel – 2.99.917 in Fedora. thanks From: Heah, Jim Poh Sent: Tuesday, April 14, 2015 12:38 PM To: Zhang, Xiong Y; intel-gfx@lists.freedesktop.org mailto:intel-gfx@lists.freedesktop.org Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Thanks Xiong, What about Fedora? Are there any plans for Fedora? Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | mailto:jim.poh.h...@intel.com jim.poh.h...@intel.com From: Zhang, Xiong Y Sent: Tuesday, April 14, 2015 10:57 AM To: Heah, Jim Poh; intel-gfx@lists.freedesktop.org mailto:intel-gfx@lists.freedesktop.org Cc: Zhang, Xiong Y Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Ubuntu 15.04 which will be released at the end of this month should support Broadwell-H. Ubuntu 15.04 beta still couldn’t support Broadwell-H. Several days ago, I run Kernel 3.19.3 and xf86-video-intel – 2.99.917 on BDW-H. thanks From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Heah, Jim Poh Sent: Tuesday, April 14, 2015 10:34 AM To: intel-gfx@lists.freedesktop.org mailto:intel-gfx@lists.freedesktop.org Subject: [Intel-gfx] FW: [Contact] Graphics Driver for Broadwell-H CPU Hi, I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | mailto:jim.poh.h...@intel.com jim.poh.h...@intel.com From: Chacn Limn, DanielX Sent: Tuesday, April 14, 2015 1:08 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim Poh, Please contact The Linux Graphics team in this e-mail: intel-gfx@lists.freedesktop.org mailto:intel-gfx@lists.freedesktop.org You can also reach them through IRC in: #intel-...@freenode.net irc://freenode.net/#intel-gfx . Please let us know of anything else we can help you with. Regards, Daniel. -Original Message- From: Heah, Jim Poh Sent: Monday, April 13, 2015 12:52 AM To: Chacn Limn, DanielX Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael; Heah, Jim Poh Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Yes I am using drivers from 01.org/linuxgraphics. I tested with version 1.0.8. The CPU I am testing with is not a production CPU but an engineering sample. Jim Poh Heah | Platform Application Engineer | IoTG Intel Penang | 604-253-7860 | jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com -Original Message- From: Chacn Limn, DanielX Sent: Friday, April 10, 2015 12:52 AM To: Heah, Jim Poh Cc: Becerra Ruiz, Lilia; Flores Perez, Jimena; Fuller, Michael Subject: RE: [Contact] Graphics Driver for Broadwell-H CPU Hi Jim, Are you using drivers from the Downloads section of this site? https://01.org/linuxgraphics/ Please provide more details on where did you get the drivers and what version are you testing. Thanks in advance, Daniel. -Original Message- From: Becerra Ruiz, Lilia Sent: Wednesday, April 8, 2015 10:45 AM To: Chacn Limn, DanielX Subject: FW: [Contact] Graphics Driver for Broadwell-H CPU Me dices si necesitas ayuda con este -Original Message- From: webmas...@01.org mailto:webmas...@01.org [mailto:webmas...@01.org] On Behalf Of jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com Sent: Tuesday, April 7, 2015 9:47 PM To: Becerra Ruiz, Lilia; Fuller, Michael; Flores Perez, Jimena; Chacn Limn, DanielX Subject: [Contact] Graphics Driver for Broadwell-H CPU Jim Poh Heah (jim.poh.h...@intel.com mailto:jim.poh.h...@intel.com ) sent a message using the contact form at https://01.org/about/contact-us. I am getting Kernel Panics when testing with Broadwell-H CPU (Intel Internal silicon) on Fedora 21 and Ubuntu 14.10. Can you let me know the schedule for testing Broadwell-H silicon? One of the messages were: drm kms helper: panic occurred Report as inappropriate: https://01.org/mollom/report/mollom_captcha/150408dcde5193daa4 smime.p7s Description: S/MIME cryptographic signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/skl: Add DC5 Trigger Sequence
On Mon, Apr 13, 2015 at 03:56:23PM +0530, Animesh Manna wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90e47a9..8d6deaa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -667,6 +667,12 @@ struct intel_uncore {
#define for_each_fw_domain(domain__, dev_priv__, i__) \
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
+enum csr_states {
+ FW_LOADED = 0,
+ FW_LOADING,
+ FW_FAILED
+};
+
struct intel_csr {
const char *fw_path;
__be32 *dmc_payload;
@@ -674,6 +680,7 @@ struct intel_csr {
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
+ enum csr_states states;
};
Usually these kind of enum and variable are singular. enum csr_state and
state.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, April 13, 2015 11:13 AM
To: Konduru, Chandra
Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander; Vetter,
Daniel
Subject: Re: [Intel-gfx] [PATCH 13/14] drm/i915: skylake primary plane scaling
using shared scalers
On Tue, Apr 07, 2015 at 03:28:46PM -0700, Chandra Konduru wrote:
This patch enables skylake primary plane scaling using shared scalers
atomic desgin.
v2:
-use single copy of scaler limits (Matt)
v3:
-move detach_scalers to crtc commit path (Matt) -use values in
plane_state-src as regular integers (me)
v4:
-changes to align with updated scaler structures (Matt, me) -keep
plane src rect in 16.16 format (Matt, Daniel)
Signed-off-by: Chandra Konduru chandra.kond...@intel.com
Ok there's a real functional conflict here now with 90/270 rotation. It's big
enough that imo we also need to add igt coverage to test
rotation+scaling together (the scaled plane setup is different from the
normal one, and we need to also make sure we scale correctly itself when
rotated).
Chandra can you please figure out with Sonika who can do this rebasing/igt
extension?
To give some context, this was one of the reasons I gave heads up to Sonika
to rebase 90/270 on top of scalers but looks they weren't.
Agree that we need igt for rotation+scaling too. In current kms_plane_scaling
didn't planned to cover 90/270 for the same reason that igt for 90/270 taking
care of that.
Sure, will sync up offline with Sonika and get back on the last two patches and
igt too.
Thanks, Daniel
---
drivers/gpu/drm/i915/intel_atomic.c |5 +-
drivers/gpu/drm/i915/intel_display.c | 96
--
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_sprite.c |9
4 files changed, 105 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 2fc04ec..8f759c6 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -167,7 +167,7 @@ int intel_atomic_commit(struct drm_device *dev,
plane-state-state = NULL;
}
- /* swap crtc_state */
+ /* swap crtc_scaler_state */
for (i = 0; i dev-mode_config.num_crtc; i++) {
struct drm_crtc *crtc = state-crtcs[i];
if (!crtc) {
@@ -176,6 +176,9 @@ int intel_atomic_commit(struct drm_device *dev,
to_intel_crtc(crtc)-config-scaler_state =
to_intel_crtc_state(state-crtc_states[i])-scaler_state;
+
+ if (INTEL_INFO(dev)-gen = 9)
+ skl_detach_scalers(to_intel_crtc(crtc));
}
drm_atomic_helper_commit_planes(dev, state); diff --git
a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index aa4da1f..c7ee232 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2978,6 +2978,14 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
int pipe = intel_crtc-pipe;
u32 plane_ctl, stride_div;
unsigned long surf_addr;
+ struct intel_crtc_state *crtc_state = intel_crtc-config;
+ struct intel_plane_state *plane_state;
+ int src_x = 0, src_y = 0, src_w = 0, src_h = 0;
+ int dst_x = 0, dst_y = 0, dst_w = 0, dst_h = 0;
+ int scaler_id = -1;
+
+ plane_state = crtc-primary ?
+ to_intel_plane_state(crtc-primary-state) : NULL;
if (!intel_crtc-primary_enabled) {
I915_WRITE(PLANE_CTL(pipe, 0), 0);
@@ -3046,12 +3054,40 @@ static void skylake_update_primary_plane(struct
drm_crtc *crtc,
fb-pixel_format);
surf_addr = intel_plane_obj_offset(to_intel_plane(crtc-primary),
obj);
+ if (plane_state) {
+ scaler_id = plane_state-scaler_id;
+ src_x = plane_state-src.x1 16;
+ src_y = plane_state-src.y1 16;
+ src_w = drm_rect_width(plane_state-src) 16;
+ src_h = drm_rect_height(plane_state-src) 16;
+ dst_x = plane_state-dst.x1;
+ dst_y = plane_state-dst.y1;
+ dst_w = drm_rect_width(plane_state-dst);
+ dst_h = drm_rect_height(plane_state-dst);
+ }
+
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_POS(pipe, 0), 0);
+
+ if (src_w src_h dst_w dst_h scaler_id = 0) {
+ uint32_t ps_ctrl = 0;
+
+ WARN_ON(x != src_x || y != src_y);
+ ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(0) |
+ crtc_state-scaler_state.scalers[scaler_id].mode;
+ I915_WRITE(SKL_PS_CTRL(pipe, scaler_id), ps_ctrl);
+ I915_WRITE(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
+ I915_WRITE(SKL_PS_WIN_POS(pipe, scaler_id),
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Mon, 2015-04-13 at 18:02 +0100, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 07:52:54PM +0300, Imre Deak wrote: On Mon, 2015-04-13 at 17:34 +0100, Damien Lespiau wrote: On Mon, Apr 13, 2015 at 03:54:02PM +0530, Animesh Manna wrote: diff --git a/drivers/gpu/drm/i915/intel_csr.h b/drivers/gpu/drm/i915/intel_csr.h new file mode 100644 index 000..c2a5a53 --- /dev/null +++ b/drivers/gpu/drm/i915/intel_csr.h + [...] +#define I915_CSR_SKL i915/dmc_gen9.bin I'm guessing the BXT DMC firwmare will be different from SKL's? Remember that one of the requirements is to be able to have the same OS image boot on both SKL and BXT. That means the firmware names have to be different for SKL and BXT. We probably should have skl in the name here. Also, we need to be able to be able to support Interface versions. Ie. if the firmware interface changes in such a way a different loading code is needed, we need to be able to have both firmware on the disk so both an old kernel and a new kernel can work with the same user space. Right now, the naming scheme of the firmware does have a version on it, hopefully that's this Interface version. Thoughts? Yes, the above file name looks incorrect. dmc_gen9.bin was the name for the firmware image with the old layout. This patchset adds support for the new firmware layout starting from ver 1, while the old layout doesn't need to be supported. In an earlier version of this patch the filename was changed to i915/skl_dmc_ver1.bin not sure why that change got dropped. I think we could just use this latter name. First public firmware is already v4 [1], no idea is the version bumps are actual API/interface changes. Ok, I haven't seen that. One question is if we need to support multiple interface versions or just the latest one. I would say only the latest one (for each platform) and so I915_CSR_SKL should be this latest firmware image filename, in this case i915/skl_dmc_ver4.bin. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On Mon, Apr 13, 2015 at 08:15:29PM +0300, Imre Deak wrote: Ok, I haven't seen that. One question is if we need to support multiple interface versions or just the latest one. I would say only the latest one (for each platform) and so I915_CSR_SKL should be this latest firmware image filename, in this case i915/skl_dmc_ver4.bin. Yup, I think just supporting the latest one in the driver is what we want. The filename versioning is there so different kernel versions, supporting different interfaces, can all boot with the same userspace, each kernel loading the appropriate firmware. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm/i915: Add automated testing support for Displayport compliance testing
2015-04-10 13:12 GMT-03:00 Todd Previte tprev...@gmail.com:
Add the skeleton framework for supporting automation for Displayport
compliance
testing. This patch adds the necessary framework for the source device to
appropriately respond to test automation requests from a sink device.
V2:
- Addressed previous mailing list feedback
- Fixed compilation issue (struct members declared in a later patch)
- Updated debug messages to be more accurate
- Added status checks for the DPCD read/write calls
- Removed excess comments and debug messages
- Fixed debug message compilation warnings
- Fixed compilation issue with missing variables
- Updated link training autotest to ACK
V3:
- Fixed the checks on the DPCD return code to be = 0
rather than != 0
- Removed extraneous assignment of a NAK return code in the
DPCD read failure case
- Changed the return in the DPCD read failure case to a goto
to the exit point where the status code is written to the sink
- Removed FAUX test case since it's deprecated now
- Removed the compliance flag assignment in handle_test_request
V4:
- Moved declaration of type_type here
- Removed declaration of test_data (moved to a later patch)
- Added reset to 0 for compliance test variables
V5:
- Moved test_active variable declaration and initialization out of
this patch and into the patch where it's used
- Changed variable name compliance_testing_active to
compliance_test_active to unify the naming convention
- Added initialization for compliance_test_type variable
Signed-off-by: Todd Previte tprev...@gmail.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 75
+---
drivers/gpu/drm/i915/intel_drv.h | 3 ++
2 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index eea9e36..ae0fb98 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3746,11 +3746,78 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp,
u8 *sink_irq_vector)
return true;
}
-static void
-intel_dp_handle_test_request(struct intel_dp *intel_dp)
+static uint8_t intel_dp_autotest_link_training(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_ACK;
+ return test_result;
+}
+
+static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ return test_result;
+}
+
+static uint8_t intel_dp_autotest_edid(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ return test_result;
+}
+
+static uint8_t intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
+{
+ uint8_t test_result = DP_TEST_NAK;
+ return test_result;
+}
+
+static void intel_dp_handle_test_request(struct intel_dp *intel_dp)
{
- /* NAK by default */
- drm_dp_dpcd_writeb(intel_dp-aux, DP_TEST_RESPONSE, DP_TEST_NAK);
+ uint8_t response = DP_TEST_NAK;
+ uint8_t rxdata = 0;
+ int status = 0;
+
+ intel_dp-compliance_test_type = 0;
+ intel_dp-aux.i2c_nack_count = 0;
+ intel_dp-aux.i2c_defer_count = 0;
+
+ status = drm_dp_dpcd_read(intel_dp-aux, DP_TEST_REQUEST, rxdata,
1);
+ if (status = 0) {
+ DRM_DEBUG_KMS(Could not read test request from sink\n);
+ goto update_status;
+ }
+
+ switch (rxdata) {
+ case DP_TEST_LINK_TRAINING:
+ DRM_DEBUG_KMS(LINK_TRAINING test requested\n);
+ intel_dp-compliance_test_type = DP_TEST_LINK_TRAINING;
+ response = intel_dp_autotest_link_training(intel_dp);
+ break;
+ case DP_TEST_LINK_VIDEO_PATTERN:
+ DRM_DEBUG_KMS(TEST_PATTERN test requested\n);
+ intel_dp-compliance_test_type = DP_TEST_LINK_VIDEO_PATTERN;
+ response = intel_dp_autotest_video_pattern(intel_dp);
+ break;
+ case DP_TEST_LINK_EDID_READ:
+ DRM_DEBUG_KMS(EDID test requested\n);
+ intel_dp-compliance_test_type = DP_TEST_LINK_EDID_READ;
+ response = intel_dp_autotest_edid(intel_dp);
+ break;
+ case DP_TEST_LINK_PHY_TEST_PATTERN:
+ DRM_DEBUG_KMS(PHY_PATTERN test requested\n);
+ intel_dp-compliance_test_type =
DP_TEST_LINK_PHY_TEST_PATTERN;
+ response = intel_dp_autotest_phy_pattern(intel_dp);
+ break;
+ default:
+ DRM_DEBUG_KMS(Invalid test request '%02x'\n, rxdata);
+ break;
+ }
+
+update_status:
+ status = drm_dp_dpcd_write(intel_dp-aux,
+ DP_TEST_RESPONSE,
+ response, 1);
+ if (status = 0)
+ DRM_DEBUG_KMS(Could not write test response to sink\n);
}
[Intel-gfx] [PATCH] drm/i915: make drm_crtc_helper_funcs const data
Because they can be.
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 a0be6ab7ba7b..bc079d5016e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10420,7 +10420,7 @@ out_hang:
return ret;
}
-static struct drm_crtc_helper_funcs intel_helper_funcs = {
+static const struct drm_crtc_helper_funcs intel_helper_funcs = {
.mode_set_base_atomic = intel_pipe_set_base_atomic,
.load_lut = intel_crtc_load_lut,
.atomic_begin = intel_begin_crtc_commit,
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Allocate connector state together with the connectors
On Sat, Apr 11, 2015 at 08:23:06AM +0200, Nicolas Kalkhof wrote: Hello, it seems I got kicked off Cc. Anyway I can confirm that the supplied patch works an I can hotplug to my docking station and switch between DP/eDP without Oops. :) Thanks for the test feedback, patch applied. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 v2 1/1] drm/i915: Disable Render power gating
On Sun, Apr 12, 2015 at 11:28:14AM +0530, sagar.a.kam...@intel.com wrote: From: Sagar Kamble sagar.a.kam...@intel.com When RC6 along with Render power gating is enabled, GPU hang happens due to lack of synchronization between GTI and Render power gating. v2: Updated commit message and WA name (Damien) Change-Id: If1614206341eb52a21eadae8c5ebb2655029b50c Reviewed-by: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Sagar Kamble sagar.a.kam...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 4/9] drivers/pwm: Add helper to configure pwm using clock divisor and duty percent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2015 01:59 PM, Thierry Reding wrote: On Wed, Apr 01, 2015 at 11:58:50AM +0530, Shobhit Kumar wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/24/2015 01:53 PM, Thierry Reding wrote: On Fri, Mar 13, 2015 at 07:28:02PM +0530, Shobhit Kumar wrote: Some chips instead of using period_ns and duty_ns can be configured using the clock divisor and duty percent. Adds an alternative configuration method for such chips I don't see a need to introduce this alternative configuration mechanism. Most, of not all, of the other drivers program a clock divisor and some percentage of the duty cycle as well and it should be easy to convert to that internally from the period and duty_cycle parameters that you get in -config(). Perhaps. Probably I misunderstood but as per Documentation/pwm.txt, it is suggested that rather than calculating in the driver, we can add additional helpers. So I tried doing just that. And it also means that the consumer(which is directly aware of the percent it wants) has to do the calculation and pass as ns values and we internally again convert back to percentage ? Yes. The interface assumes that you'll pass in absolute values for the period and duty cycle. Existing drivers, such as pwm-backlight, already convert a percentage or other internal representation to these absolute values. If your driver internally works with percent you can easily convert to that from the absolute values. The documentation only makes a suggestion. I think it'd be fine if you kept this conversion internal to the driver. We can turn it into a more generic helper if a second driver appears that needs the same conversion. Okay, will change driver implementation and avoid this patch Adding an alternative means of configuring the PWM also means that every user driver now potentially needs to support both the traditional and the alternative way because PWM providers may not implement both. I just assumed either or implementation should suffice. Even in my implementation the error checks assumes either of the two should be available else to fail the pwmchip_add Your implementation requires that users call either pwm_config() or pwm_config_alternate(). PWM drivers may only have to implement either callback, but users will be required to support both (or otherwise only work with a subset of PWM drivers). Yeah, I overlooked this. Will push a new patch for the driver. Regards Shobhit Thierry -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVK3gXAAoJEHuQFv2//5KqRhIIAMKvvSuJ3yyiPrBULOk6PyZg AyNpICHg/pwhnjdns45eui1YnWb6Hrasbs5+UZRxlUAubs/+CDa1ZvGvtAZZQCO0 g8YO0EiafdGUg8KMif2qblJZf0oJFWs1j8sUQaarA7Uh2/1m4elvijQ39J30yzCt +4N2JQ3Nazx2KWS5P8Wo9i2Km733vz7p8nY5lqXlstHer1x4QoaCz6utNPMgcUE+ N5wCUpOzEzqM4Lle63R2UO/uCfC+169Q+bZ2r9a1UxSeLhA+fhkZWgusaUeqi1UL kIy4YSyelTNYIBa8dufp+IQL1w2cSbZ9JoPj7Zc7agTYqbhOuLhbM1wC9DWMWW0= =1wV2 -END PGP SIGNATURE- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 35/49] drm/i915/bxt: fix panel fitter setup in crtc disable/enable
On Sun, Apr 12, 2015 at 03:49:34PM +0530, sagar.a.kam...@intel.com wrote: For updated patch that is coming up per http://lists.freedesktop.org/archives/intel-gfx/2015-March/062315.html Reviewed-by: Sagar Kamble sagar.a.kamble at intel.com Please don't reply to mails by linking to their archive link because that completely rips apart the discussion. Also the mailman archive isn't fully stable, much better to link to gman using the Message-Id if there is a need for that. But review/discussions really should be direct replies. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in i915_driver_load(), so removed it. (Animesh) Issue: VIZ-2569 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Animesh Manna animesh.ma...@intel.com Signed-off-by: Imre Deak imre.d...@intel.com --- drivers/gpu/drm/i915/Makefile| 3 +- drivers/gpu/drm/i915/i915_dma.c | 11 +-
[Intel-gfx] [PATCH] vt: Don't check KD_GRAPHICS when binding/unbinding
This was introduced in
commit 6db4063c5b72b46e9793b0f141a7a3984ac6facf
Author: Antonino A. Daplas adap...@gmail.com
Date: Mon Jun 26 00:27:12 2006 -0700
[PATCH] VT binding: Add sysfs control to the VT layer
with the justification
In addition, if any of the consoles are in KD_GRAPHICS mode, binding and
unbinding will not succeed. KD_GRAPHICS mode usually indicates that the
underlying console hardware is used for other purposes other than displaying
text (ie X). This feature should prevent binding/unbinding from interfering
with a graphics application using the VT.
I think we should lift this artificial restriction though:
- KD_GRAPHICS doesn't get cleaned up automatically, which means it's
easy to have terminals stuck in KD_GRAPHICS when hacking around on
X.
- X doesn't really care, especially with drm where kms already blocks
fbdev (and hence fbcon) when there's an active compositor.
- This is a root-only interface with a separate .config option and
it's possible to hang your machine already anyway if you
unload/reload drivers and don't know what you're doing.
With this patch i915.ko module reloading works again reliably,
something in the recent fedora upgrades broke things.
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Antonino A. Daplas adap...@gmail.com
Cc: David Herrmann dh.herrm...@gmail.com
Cc: Peter Hurley pe...@hurleysoftware.com
Cc: Imre Deak imre.d...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/tty/vt/vt.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 6e00572cbeb9..b84f7d80c8b4 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -3185,22 +3185,6 @@ err:
#ifdef CONFIG_VT_HW_CONSOLE_BINDING
-static int con_is_graphics(const struct consw *csw, int first, int last)
-{
- int i, retval = 0;
-
- for (i = first; i = last; i++) {
- struct vc_data *vc = vc_cons[i].d;
-
- if (vc vc-vc_mode == KD_GRAPHICS) {
- retval = 1;
- break;
- }
- }
-
- return retval;
-}
-
/* unlocked version of unbind_con_driver() */
int do_unbind_con_driver(const struct consw *csw, int first, int last, int
deflt)
{
@@ -3286,8 +3270,7 @@ static int vt_bind(struct con_driver *con)
const struct consw *defcsw = NULL, *csw = NULL;
int i, more = 1, first = -1, last = -1, deflt = 0;
- if (!con-con || !(con-flag CON_DRIVER_FLAG_MODULE) ||
- con_is_graphics(con-con, con-first, con-last))
+ if (!con-con || !(con-flag CON_DRIVER_FLAG_MODULE))
goto err;
csw = con-con;
@@ -3338,8 +3321,7 @@ static int vt_unbind(struct con_driver *con)
int i, more = 1, first = -1, last = -1, deflt = 0;
int ret;
- if (!con-con || !(con-flag CON_DRIVER_FLAG_MODULE) ||
- con_is_graphics(con-con, con-first, con-last))
+ if (!con-con || !(con-flag CON_DRIVER_FLAG_MODULE))
goto err;
csw = con-con;
--
2.1.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 3/8] drm/i915/skl: Add DC5 Trigger Sequence
From: Suketu Shah suketu.j.s...@intel.com
Add triggers as per expectations mentioned in gen9_enable_dc5
and gen9_disable_dc5 patch.
Also call POSTING_READ for every write to a register to ensure that
its written immediately.
v1: Remove POSTING_READ calls as they've already been added in previous patches.
v2: Rebase to move all runtime pm specific changes to intel_runtime_pm.c file.
Modified as per review comments from Imre:
1] Change variable name 'dc5_allowed' to 'dc5_enabled' to correspond to relevant
functions.
2] Move the check dc5_enabled in skl_set_power_well() to disable DC5 into
gen9_disable_DC5 which is a more appropriate place.
3] Convert checks for 'pm.dc5_enabled' and 'pm.suspended' in
skl_set_power_well()
to warnings. However, removing them for now as they'll be included in a
future patch
asserting DC-state entry/exit criteria.
4] Enable DC5, only when CSR firmware is verified to be loaded. Create new
structure
to track 'enabled' and 'deferred' status of DC5.
5] Ensure runtime PM reference is obtained, if CSR is not loaded, to avoid
entering
runtime-suspend and release it when it's loaded.
6] Protect necessary CSR-related code with locks.
7] Move CSR-loading call to runtime PM initialization, as power domains needed
to be
accessed during deferred DC5-enabling, are not initialized earlier.
v3: Rebase to latest.
Modified as per review comments from Imre:
1] Use blocking wait for CSR-loading to finish to enable DC5 for simplicity,
instead of
deferring enabling DC5 until CSR is loaded.
2] Obtain runtime PM reference during CSR-loading initialization itself as
deferred DC5-
enabling is removed and release it at the end of CSR-loading functionality.
3] Revert calling CSR-loading functionality to the beginning of i915 driver-load
functionality to avoid any delay in loading.
4] Define another variable to track whether CSR-loading failed and use it to
avoid enabling
DC5 if it's true.
5] Define CSR-load-status accessor functions for use later.
v4:
1] Disable DC5 before enabling PG2 instead of after it.
2] DC5 was being mistaken enabled even when CSR-loading timed-out. Fix that.
3] Enable DC5-related functionality using a macro.
4] Remove dc5_enabled tracking variable and its use as it's not needed now.
v5:
1] Mark CSR failed to load where necessary in finish_csr_load function.
2] Use mutex-protected accessor function to check if CSR loaded instead of
directly
accessing the variable.
3] Prefix csr_load_status_get/set function names with intel_.
v6: rebase to latest.
v7: Rebase on top of nightly (Damien)
v8: Squashed the patch from Imre - added csr helper pointers to simplify the
code. (Imre)
v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
v10: Added a enum for different csr states, suggested by Imre. (Animesh)
Issue: VIZ-2819
Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Suketu Shah suketu.j.s...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/intel_csr.c| 51 +++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 29 +++
4 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90e47a9..8d6deaa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -667,6 +667,12 @@ struct intel_uncore {
#define for_each_fw_domain(domain__, dev_priv__, i__) \
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
+enum csr_states {
+ FW_LOADED = 0,
+ FW_LOADING,
+ FW_FAILED
+};
+
struct intel_csr {
const char *fw_path;
__be32 *dmc_payload;
@@ -674,6 +680,7 @@ struct intel_csr {
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
+ enum csr_states states;
};
#define DEV_INFO_FOR_EACH_FLAG(func, sep) \
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index ab9b16b..6d08a41 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -49,6 +49,25 @@ static char intel_get_substepping(struct drm_device *dev)
else
return -ENODATA;
}
+
+bool intel_csr_load_status_get(struct drm_i915_private *dev_priv)
+{
+ bool val = false;
+
+ mutex_lock(dev_priv-csr_lock);
+ val = dev_priv-csr.states;
+ mutex_unlock(dev_priv-csr_lock);
+
+ return val;
+}
+
+void intel_csr_load_status_set(struct drm_i915_private *dev_priv, bool val)
+{
+ mutex_lock(dev_priv-csr_lock);
+ dev_priv-csr.states = val;
+ mutex_unlock(dev_priv-csr_lock);
+}
+
void intel_csr_load_program(struct drm_device *dev)
{
struct
Re: [Intel-gfx] [PATCH i-g-t v3 1/2] tests/gem_mmap_gtt: clarify BO domain setting functions
These two patches still have something to work on, or could they be
committed?
On ke, 2015-04-08 at 15:55 +0300, Joonas Lahtinen wrote:
Add suffix and complementary function for CPU domain.
v2:
- Change function signatures to be consistent with the rest
Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
tests/gem_mmap_gtt.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index 55c66a2..115e398 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -43,11 +43,18 @@
static int OBJECT_SIZE = 16*1024*1024;
-static void set_domain(int fd, uint32_t handle)
+static void
+set_domain_gtt(int fd, uint32_t handle)
{
gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
}
+static void
+set_domain_cpu(int fd, uint32_t handle)
+{
+ gem_set_domain(fd, handle, I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
+}
+
static void *
mmap_bo(int fd, uint32_t handle)
{
@@ -245,7 +252,7 @@ test_write_gtt(int fd)
/* prefault object into gtt */
dst_gtt = mmap_bo(fd, dst);
- set_domain(fd, dst);
+ set_domain_gtt(fd, dst);
memset(dst_gtt, 0, OBJECT_SIZE);
munmap(dst_gtt, OBJECT_SIZE);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers
On Thu, Apr 09, 2015 at 10:14:36PM +, Konduru, Chandra wrote: -Original Message- From: Roper, Matthew D Sent: Thursday, April 09, 2015 2:52 PM To: Konduru, Chandra Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel; Conselvan De Oliveira, Ander Subject: Re: [PATCH 13/14] drm/i915: skylake primary plane scaling using shared scalers On Tue, Apr 07, 2015 at 03:28:46PM -0700, Chandra Konduru wrote: This patch enables skylake primary plane scaling using shared scalers atomic desgin. v2: -use single copy of scaler limits (Matt) v3: -move detach_scalers to crtc commit path (Matt) -use values in plane_state-src as regular integers (me) v4: -changes to align with updated scaler structures (Matt, me) -keep plane src rect in 16.16 format (Matt, Daniel) See comments on patch #6 that relate to this. If you want to take the approach here (perform the unshift in skl_update_plane) then you also need to do the same for all other platforms (ivb, ilk, vlv, etc.). But my suggestion on the other patch (do the unshifting in commit_plane and leave skl_update_plane alone) might be a bit simpler. Above v4: comment is saying that the change done in v3 was undone to keep primary_plane src rect in 16.16 format. As I responded to your patch #6 comment, moving unshift hunk (which is for sprite plane) from #14 to #6 will avoid any potential bisect issue that you mentioned. For other than skylake, primary planes platform level update functions doesn't use src_rect instead operate based on passed parameters which are in regular ints. Only for skylake primary plane update function, src rect is used for windowing, scaling purposes. I merged up to patch 12, but this one here doesn't apply any more and I'm not sure whether there's any changes still needed to it (it sounds like not, but chasing that unshifting business is tricky). Chandra, can you please resend rebased patches (with Matt's r-b added)? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 32/49] drm/i915/bxt: Implement enable/disable for Display C9 state
On Mon, 2015-04-13 at 13:09 +0300, Imre Deak wrote: On su, 2015-04-12 at 16:02 +0530, sagar.a.kam...@intel.com wrote: These are review comments for 1) http://lists.freedesktop.org/archives/intel-gfx/2015-March/062167.html 2) http://lists.freedesktop.org/archives/intel-gfx/2015-March/062168.html It'd be better to have inlined review comments responding to the original email. Yes. Sorry for the inconvenience. My ML subscription was in digest mode. So replied using only message-id knowing from Deepak. Now I have switched to individual mails. Couple of comments: 1) Defines for DC_STATE_EN* are coming up as part of http://lists.freedesktop.org/archives/intel-gfx/2015-April/063640.html. Need to rebase this patch on top of it then or vice-versa. Yes, I can rebase this once Animesh's patchset gets merged. It's also a trivial conflict that can be easily resolved while merging, so it's not an issue imo. 2) DC5 has to enabled back after disabling DC9 if PW2 is power gated. BXT DC5/runtime PM support will be added only later. At that point the enabling of DC5 should be done from bxt_resume_prepare() if the the DMC firmware is loaded. For now I'd just add the missing TODO comment about this to bxt_resume_prepare() as you suggested elsewhere. Thanks. Reviewed-by: Sagar Kamble sagar.a.kamble at intel.com --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Simplify and fix object to display tracking
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Purpose of this tracking is to know when to flush the cache between
the CPU and the non-coherent display engine. Prior to:
commit 121920faf2ccce9aa66a7e2588415c9647b66104
Author: Tvrtko Ursulin tvrtko.ursu...@intel.com
Date: Mon Mar 23 11:10:37 2015 +
drm/i915/skl: Query display address through a wrapper
This worked by a mix of direct flag manipulation and checking for
existence of a pinned GGTT VMA.
With the introduction of rotated display mappings this approach is
no longer correct.
New simpler approach is to just keep this count over calls which pin
and unpin objects to and from display, at the slight cost of extra
space in every bo.
(Inspired and extracted code from a larger rework by Chris Wilson.)
v2: Remove the limit since it is not well defined. (Chris Wilson, Ville Syrjälä)
v3: Commit message corrections. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem.c | 30 ++
2 files changed, 8 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4ef320c..37abd58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1969,7 +1969,6 @@ struct drm_i915_gem_object {
*/
unsigned int fault_mappable:1;
unsigned int pin_mappable:1;
- unsigned int pin_display:1;
/*
* Is the object to be mapped as read-only to the GPU
@@ -1983,6 +1982,8 @@ struct drm_i915_gem_object {
unsigned int frontbuffer_bits:INTEL_FRONTBUFFER_BITS;
+ unsigned int pin_display;
+
struct sg_table *pages;
int pages_pin_count;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3a91365..8b75dab 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3849,24 +3849,6 @@ unlock:
return ret;
}
-static bool is_pin_display(struct drm_i915_gem_object *obj)
-{
- struct i915_vma *vma;
-
- vma = i915_gem_obj_to_ggtt(obj);
- if (!vma)
- return false;
-
- /* There are 2 sources that pin objects:
-* 1. The display engine (scanouts, sprites, cursors);
-* 2. Reservations for execbuffer;
-*
-* We can ignore reservations as we hold the struct_mutex and
-* are only called outside of the reservation path.
-*/
- return vma-pin_count;
-}
-
/*
* Prepare buffer for display plane (scanout, cursors, etc).
* Can be called from an uninterruptible phase (modesetting) and allows
@@ -3879,7 +3861,6 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
const struct i915_ggtt_view *view)
{
u32 old_read_domains, old_write_domain;
- bool was_pin_display;
int ret;
if (pipelined != i915_gem_request_get_ring(obj-last_read_req)) {
@@ -3891,8 +3872,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
/* Mark the pin_display early so that we account for the
* display coherency whilst setting up the cache domains.
*/
- was_pin_display = obj-pin_display;
- obj-pin_display = true;
+ obj-pin_display++;
/* The display engine is not coherent with the LLC cache on gen6. As
* a result, we make sure that the pinning that is about to occur is
@@ -3936,8 +3916,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
return 0;
err_unpin_display:
- WARN_ON(was_pin_display != is_pin_display(obj));
- obj-pin_display = was_pin_display;
+ obj-pin_display--;
return ret;
}
@@ -3945,9 +3924,12 @@ void
i915_gem_object_unpin_from_display_plane(struct drm_i915_gem_object *obj,
const struct i915_ggtt_view *view)
{
+ if (WARN_ON(obj-pin_display == 0))
+ return;
+
i915_gem_object_ggtt_unpin_view(obj, view);
- obj-pin_display = is_pin_display(obj);
+ obj-pin_display--;
}
int
--
2.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: make drm_crtc_helper_funcs const data
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6184 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 301/301 301/301 SNB 316/316 316/316 IVB -1 328/328 327/328 BYT 285/285 285/285 HSW 394/394 394/394 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied IVB igt@gem_pwrite_pread@uncached-copy-performance DMESG_WARN(1)PASS(5) DMESG_WARN(2) (dmesg patch applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...blitter_ring_idle@Hangcheck timer elapsed... blitter ring idle Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/70] drm/i915: Optimistically spin for the request completion
Hi, On 04/07/2015 04:20 PM, Chris Wilson wrote: This provides a nice boost to mesa in swap bound scenarios (as mesa throttles itself to the previous frame and given the scenario that will complete shortly). It will also provide a good boost to systems running with semaphores disabled and so frequently waiting on the GPU as it switches rings. In the most favourable of microbenchmarks, this can increase performance by around 15% - though in practice improvements will be marginal and rarely noticeable. v2: Account for user timeouts v3: Limit the spinning to a single jiffie (~1us) at most. On an otherwise idle system, there is no scheduler contention and so without a limit we would spin until the GPU is ready. v4: Drop forcewake - the lazy coherent access doesn't require it, and we have no reason to believe that the forcewake itself improves seqno coherency - it only adds delay. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com Cc: Eero Tamminen eero.t.tammi...@intel.com Cc: Rantala, Valtteri valtteri.rant...@intel.com I already said that I already gave my r-b for this one. :) Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/skl: Add DC5 Trigger Sequence
On ma, 2015-04-13 at 15:56 +0530, Animesh Manna wrote:
From: Suketu Shah suketu.j.s...@intel.com
Add triggers as per expectations mentioned in gen9_enable_dc5
and gen9_disable_dc5 patch.
Also call POSTING_READ for every write to a register to ensure that
its written immediately.
v1: Remove POSTING_READ calls as they've already been added in previous
patches.
v2: Rebase to move all runtime pm specific changes to intel_runtime_pm.c file.
Modified as per review comments from Imre:
1] Change variable name 'dc5_allowed' to 'dc5_enabled' to correspond to
relevant
functions.
2] Move the check dc5_enabled in skl_set_power_well() to disable DC5 into
gen9_disable_DC5 which is a more appropriate place.
3] Convert checks for 'pm.dc5_enabled' and 'pm.suspended' in
skl_set_power_well()
to warnings. However, removing them for now as they'll be included in a
future patch
asserting DC-state entry/exit criteria.
4] Enable DC5, only when CSR firmware is verified to be loaded. Create new
structure
to track 'enabled' and 'deferred' status of DC5.
5] Ensure runtime PM reference is obtained, if CSR is not loaded, to avoid
entering
runtime-suspend and release it when it's loaded.
6] Protect necessary CSR-related code with locks.
7] Move CSR-loading call to runtime PM initialization, as power domains
needed to be
accessed during deferred DC5-enabling, are not initialized earlier.
v3: Rebase to latest.
Modified as per review comments from Imre:
1] Use blocking wait for CSR-loading to finish to enable DC5 for simplicity,
instead of
deferring enabling DC5 until CSR is loaded.
2] Obtain runtime PM reference during CSR-loading initialization itself as
deferred DC5-
enabling is removed and release it at the end of CSR-loading functionality.
3] Revert calling CSR-loading functionality to the beginning of i915
driver-load
functionality to avoid any delay in loading.
4] Define another variable to track whether CSR-loading failed and use it to
avoid enabling
DC5 if it's true.
5] Define CSR-load-status accessor functions for use later.
v4:
1] Disable DC5 before enabling PG2 instead of after it.
2] DC5 was being mistaken enabled even when CSR-loading timed-out. Fix that.
3] Enable DC5-related functionality using a macro.
4] Remove dc5_enabled tracking variable and its use as it's not needed now.
v5:
1] Mark CSR failed to load where necessary in finish_csr_load function.
2] Use mutex-protected accessor function to check if CSR loaded instead of
directly
accessing the variable.
3] Prefix csr_load_status_get/set function names with intel_.
v6: rebase to latest.
v7: Rebase on top of nightly (Damien)
v8: Squashed the patch from Imre - added csr helper pointers to simplify the
code. (Imre)
v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
v10: Added a enum for different csr states, suggested by Imre. (Animesh)
Issue: VIZ-2819
Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Suketu Shah suketu.j.s...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 7 +
drivers/gpu/drm/i915/intel_csr.c| 51
+++--
drivers/gpu/drm/i915/intel_drv.h| 2 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 29 +++
4 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90e47a9..8d6deaa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -667,6 +667,12 @@ struct intel_uncore {
#define for_each_fw_domain(domain__, dev_priv__, i__) \
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
+enum csr_states {
Nitpick: just csr_state.
+ FW_LOADED = 0,
+ FW_LOADING,
+ FW_FAILED
+};
I'd rather have FW_LOADING = 0, as that's what the uninitialized state
really is. You could also rename it to FW_UNINITIALIZED accordingly.
+
struct intel_csr {
const char *fw_path;
__be32 *dmc_payload;
@@ -674,6 +680,7 @@ struct intel_csr {
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
+ enum csr_states states;
};
#define DEV_INFO_FOR_EACH_FLAG(func, sep) \
diff --git a/drivers/gpu/drm/i915/intel_csr.c
b/drivers/gpu/drm/i915/intel_csr.c
index ab9b16b..6d08a41 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -49,6 +49,25 @@ static char intel_get_substepping(struct drm_device *dev)
else
return -ENODATA;
}
+
+bool intel_csr_load_status_get(struct drm_i915_private *dev_priv)
+{
+ bool val = false;
+
+ mutex_lock(dev_priv-csr_lock);
+ val = dev_priv-csr.states;
+
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_mmap_gtt: add huge BO test
Hi,
On 04/07/2015 01:23 PM, Joonas Lahtinen wrote:
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by CPU directly and through GTT in sequence.
Currently it is expected for the GTT access to gracefully fail as
all objects are attempted to get pinned to GTT completely for mmap
access. Once the partial view support is merged to kernel, the test
should pass for all parts.
Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
tests/gem_mmap_gtt.c | 68
1 file changed, 68 insertions(+)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index 55c66a2..bf3627c 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -41,6 +41,10 @@
#include drmtest.h
#include igt_debugfs.h
+#ifndef PAGE_SIZE
+#define PAGE_SIZE 4096
+#endif
+
static int OBJECT_SIZE = 16*1024*1024;
static void set_domain(int fd, uint32_t handle)
@@ -258,6 +262,68 @@ test_write_gtt(int fd)
}
static void
+test_huge_bo(int fd)
+{
+ uint32_t bo;
+ char *ptr_cpu;
+ char *ptr_gtt;
+ char *cpu_pattern;
+ uint64_t mappable_aperture_pages = gem_mappable_aperture_size() /
+ PAGE_SIZE;
+ uint64_t huge_object_size = (mappable_aperture_pages + 1) * PAGE_SIZE;
+ uint64_t last_offset = huge_object_size - PAGE_SIZE;
+
+ cpu_pattern = malloc(PAGE_SIZE);
+ igt_assert(cpu_pattern);
I'd be tempted to use 4k from the stack for simplicity.
+ memset(cpu_pattern, 0xaa, PAGE_SIZE);
+
+ bo = gem_create(fd, huge_object_size);
+
+ ptr_cpu = gem_mmap__cpu(fd, bo, 0, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_cpu) {
+ igt_warn(Not enough free memory for huge BO test!\n);
+ goto out;
Free address space or free memory?
Also, igt_require so test skips in that case?
+ }
+
+ /* Test read/write to first/last page with CPU. */
+ memcpy(ptr_cpu, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu, cpu_pattern, PAGE_SIZE) == 0);
+
+ memcpy(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ igt_assert(memcmp(ptr_cpu, ptr_cpu + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_cpu, huge_object_size);
+ ptr_cpu = NULL;
+
+ ptr_gtt = gem_mmap__gtt(fd, bo, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_gtt) {
+ igt_debug(Huge BO GTT mapping not supported!\n);
+ goto out;
igt_require as above? Hm, although ideally test would be able to detect
the feature (once it is added to the kernel) so it could assert here.
+ }
+
+ /* Test read/write to first/last page through GTT. */
+ set_domain(fd, bo);
+
+ igt_assert(memcmp(ptr_gtt, cpu_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt + last_offset, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt, ptr_gtt + last_offset, PAGE_SIZE) == 0);
Comments for the above would be nice just to explain what is being
tested and how.
Won't the last test has side effects with partial views since it is
accessing beginning and end of the object? Would it be better to memcmp
against a pattern on stack or in heap like cpu_pattern?
Will you support two simultaneous partial views or the last memcmp will
cause a lot of partial view creation/destruction?
+
+ munmap(ptr_gtt, huge_object_size);
+out:
+ gem_close(fd, bo);
+ free(cpu_pattern);
+}
+
+static void
test_read(int fd)
{
void *dst;
@@ -395,6 +461,8 @@ igt_main
run_without_prefault(fd, test_write_gtt);
igt_subtest(write-cpu-read-gtt)
test_write_cpu_read_gtt(fd);
+ igt_subtest(huge-bo)
+ test_huge_bo(fd);
igt_fixture
close(fd);
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover
On Thu, 26 Mar 2015, Tvrtko Ursulin tvrtko.ursu...@linux.intel.com wrote:
On 03/26/2015 01:30 PM, Ville Syrjälä wrote:
On Thu, Mar 26, 2015 at 12:39:40PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must be held without that lock.
This is a simplified version of the identically named patch by Chris Wilson.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89166
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cb50854..0788507 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14020,11 +14020,21 @@ void intel_modeset_gem_init(struct drm_device
*dev)
c-primary-fb,
c-primary-state,
NULL)) {
+ /*
+* We must drop struct_mutex when calling
+* drm_framebuffer_unreference and it is safe to do so
+* because it is not needed at this point anyway.
+* At this stage the driver is still single-threaded and
+* we are taking it only to silence a warning in
+* intel_pin_and_fence_fb_obj.
+*/
+ mutex_unlock(dev-struct_mutex);
DRM_ERROR(failed to pin boot fb on pipe %d\n,
to_intel_crtc(c)-pipe);
drm_framebuffer_unreference(c-primary-fb);
c-primary-fb = NULL;
update_state_fb(c-primary);
+ mutex_lock(dev-struct_mutex);
}
}
mutex_unlock(dev-struct_mutex);
Just grab the mutex around the pin_and_fence inside the loop. It doesn't
protect anything else.
Well the comment says so, but this way it only grabs and releases it
once if there are multiple active crtcs and nothing fails. So I was
hoping the comment was enough to explain the reality, even though the
other option would be more obvious code strictly speaking.
Tvrtko Ville, can you reach a solution on this one? Or is there a
new patch that I may have missed?
BR,
Jani.
Regards,
Tvrtko
___
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 2/2] drm/i915/skl: Support for 90/270 rotation
On Mon, Apr 13, 2015 at 09:36:02AM +0530, Jindal, Sonika wrote:
On 4/10/2015 8:14 PM, Ville Syrjälä wrote:
On Fri, Apr 10, 2015 at 04:17:17PM +0200, Daniel Vetter wrote:
On Fri, Apr 10, 2015 at 02:37:29PM +0530, Sonika Jindal wrote:
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check
for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_* for
offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Patches are missing the Testcase: tag, please add that. Also, are all the
igt committed or not yet? Pulled these two in meanwhile.
Things are going somewhat broken because you didn't apply my plane
state stuff. Hmm. Actually it sort of looks that it might work by luck
as long as the primary plane doesn't get clipped since this is bashing
the user state directly into the hardware registers and not the derived
state (ie. clipped coordinates).
I was hoping your changes get merged, but not sure why they are held up.
Also I see my review comment about the 90 vs. 270 rotation mixup was
ignored at least.
I never really got the to understand the need of reversing 90 and 270 :)
The last discussion was not concluded, AFAIR.
Things look correct to me and work fine with the testcase also.
Is there something completely different which I am unable to get?
BSpec gives me the impression the hw rotation is cw, whereas the drm one
is ccw.
-Sonika
-Daniel
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 24
drivers/gpu/drm/i915/intel_display.c | 88
-
drivers/gpu/drm/i915/intel_drv.h |6 ++
drivers/gpu/drm/i915/intel_sprite.c | 52 -
5 files changed, 131 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..564bbd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4854,7 +4854,9 @@ enum skl_disp_power_wells {
#define PLANE_CTL_ALPHA_HW_PREMULTIPLY( 3 4)
#define PLANE_CTL_ROTATE_MASK 0x3
#define PLANE_CTL_ROTATE_00x0
+#define PLANE_CTL_ROTATE_900x1
#define PLANE_CTL_ROTATE_180 0x2
+#define PLANE_CTL_ROTATE_270 0x3
#define _PLANE_STRIDE_1_A 0x70188
#define _PLANE_STRIDE_2_A 0x70288
#define _PLANE_STRIDE_3_A 0x70388
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..a27ee8c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -162,6 +162,30 @@ static int intel_plane_atomic_check(struct drm_plane
*plane,
(1 drm_plane_index(plane));
}
+ if (state-fb intel_rotation_90_or_270(state-rotation)) {
+ if (!(state-fb-modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+ state-fb-modifier[0] == I915_FORMAT_MOD_Yf_TILED)) {
+ DRM_DEBUG_KMS(Y/Yf tiling required for 90/270!\n);
+ return -EINVAL;
+ }
+
+ /*
+ * 90/270 is not allowed with RGB64 16:16:16:16,
+ * RGB 16-bit 5:6:5, and Indexed 8-bit.
+ * TBD: Add RGB64 case once its added in supported format list.
+ */
+ switch (state-fb-pixel_format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ DRM_DEBUG_KMS(Unsupported pixel format %s for
90/270!\n,
+
drm_get_format_name(state-fb-pixel_format));
+ return -EINVAL;
+
+ default:
+ break;
+ }
+ }
+
return intel_plane-check_plane(plane, intel_state);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0bbc22..4de544c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2311,13 +2311,6 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view
*view, struct drm_framebuffer *fb,
info-pitch = fb-pitches[0];
info-fb_modifier = fb-modifier[0];
- if (!(info-fb_modifier == I915_FORMAT_MOD_Y_TILED ||
- info-fb_modifier ==
Re: [Intel-gfx] [PATCH 32/49] drm/i915/bxt: Implement enable/disable for Display C9 state
On su, 2015-04-12 at 16:02 +0530, sagar.a.kam...@intel.com wrote: These are review comments for 1) http://lists.freedesktop.org/archives/intel-gfx/2015-March/062167.html 2) http://lists.freedesktop.org/archives/intel-gfx/2015-March/062168.html It'd be better to have inlined review comments responding to the original email. Couple of comments: 1) Defines for DC_STATE_EN* are coming up as part of http://lists.freedesktop.org/archives/intel-gfx/2015-April/063640.html. Need to rebase this patch on top of it then or vice-versa. Yes, I can rebase this once Animesh's patchset gets merged. It's also a trivial conflict that can be easily resolved while merging, so it's not an issue imo. 2) DC5 has to enabled back after disabling DC9 if PW2 is power gated. BXT DC5/runtime PM support will be added only later. At that point the enabling of DC5 should be done from bxt_resume_prepare() if the the DMC firmware is loaded. For now I'd just add the missing TODO comment about this to bxt_resume_prepare() as you suggested elsewhere. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/19] drm/i915: HSW cdclk support
On Mon, Apr 13, 2015 at 12:43:14PM +0300, Mika Kahola wrote:
On Fri, 2015-04-10 at 16:10 +0200, Takashi Iwai wrote:
At Fri, 10 Apr 2015 16:27:39 +0300,
Mika Kahola wrote:
On Thu, 2015-04-09 at 17:17 +0200, Takashi Iwai wrote:
At Thu, 9 Apr 2015 15:51:27 +0200,
Daniel Vetter wrote:
On Thu, Apr 09, 2015 at 04:41:26PM +0300, Mika Kahola wrote:
On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
I did some testing on audio part with HDMI-HDMI and DP-HDMI
cables
connected to my Haswell box. Before applying the patch I tested
as a
reference with the latest -nightly (04-08-2015), 4.0-rc7.
Unfortunately,
I failed to get any audio over HDMI cable. For a reference I
tested with
the very same setup the vanillla kernel from Linus tree 4.0-rc7
and with
that kernel the audio worked ok. Then I did some GIT bisecting
and it
turned out that the first commit that I failed to get audio
working was
aa2fee4286e43b4784982b17669b02cc99c1ae55.
I rerun the bisecting and this time the result was
commit 0a599838737a2527c35e4d94f794aefe59df1781
Merge: 2d846c7 a59d719
Author: Takashi Iwai ti...@suse.de
Date: Wed Apr 8 11:29:56 2015 +0200
Merge branch 'for-linus' into for-next
Back merge HD-audio quirks to for-next branch, so that we can
apply
a couple of more quirks.
Signed-off-by: Takashi Iwai ti...@suse.de
Adding Takashi and intel audio folks.
The bisecting looks odd. The commit you pointed is a back-merge from
4.0-rc to next branch, so this merge itself shouldn't bring so many
stuff -- at least about the sound part.
The diff in sound/* is found below. As you can see, the only change
relevant with HDMI is the chunk in sound/pci/hda/hda_intel.c for
HD-audio controller, but it's specific to Skylake, thus this must be
irrelevant with your hardware.
Please double-check.
I double-checked the bisecting and I ended up with the same result. You're
right, it does seems odd why audio on my Haswell box stopped working.
Any ideas how to proceed from here?
Try to check whether the reverting the diff of sound/* manually fixes
the problem. (i.e. apply diff -R for the diff I showed in the
previous mail.)
If it doesn't fix but still reverting the whole commit does fix, it
means that something else got broken by the merge.
Takashi
I reverted the diff but unfortunately there were no difference.
For curiosity, I tested the audio with the latest -nightly and I got
the audio working again. I wonder what has changed but it seems that
the problem is now solved.
BTW we now have a WARN triggering on BSW due to hda trying to query
the current cdclk frequency.
https://bugs.freedesktop.org/show_bug.cgi?id=90012
I'm not sure if hda really needs to know the cdclk freq on BSW or not.
But in either case I think we should just kill the HAS_DDI check. Once
these patches land the code will anyway work on all platforms. Mika,
can you add that to your list of things to do on top of these patches?
-Mika-
Cheers,
Mika
thanks,
Takashi
===
% git diff
0a599838737a2527c35e4d94f794aefe59df1781^..0a599838737a2527c35e4d94f794aefe59df1781
sound
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 9bcc5457a83e..e1c210515581 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1967,7 +1967,7 @@ static const struct pci_device_id azx_ids[] = {
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Sunrise Point */
{ PCI_DEVICE(0x8086, 0xa170),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
/* Sunrise Point-LP */
{ PCI_DEVICE(0x8086, 0x9d70),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
diff --git a/sound/pci/hda/patch_realtek.c
b/sound/pci/hda/patch_realtek.c
index e0c06f9a0e80..7f46d063af57 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -396,7 +396,7 @@ static void alc_auto_setup_eapd(struct hda_codec
*codec, bool on)
{
/* We currently only handle front, HP */
static hda_nid_t pins[] = {
- 0x0f, 0x10, 0x14, 0x15, 0
+ 0x0f, 0x10, 0x14, 0x15, 0x17, 0
};
hda_nid_t *p;
for (p = pins; *p; p++)
@@ -2870,6 +2870,8 @@ static void alc283_init(struct hda_codec *codec)
if (!hp_pin)
return;
+
+
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Support for 90/270 rotation
On Mon, Apr 13, 2015 at 03:53:22PM +0530, Jindal, Sonika wrote:
On 4/13/2015 3:40 PM, Ville Syrjälä wrote:
On Mon, Apr 13, 2015 at 09:36:02AM +0530, Jindal, Sonika wrote:
On 4/10/2015 8:14 PM, Ville Syrjälä wrote:
On Fri, Apr 10, 2015 at 04:17:17PM +0200, Daniel Vetter wrote:
On Fri, Apr 10, 2015 at 02:37:29PM +0530, Sonika Jindal wrote:
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check
for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_*
for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Patches are missing the Testcase: tag, please add that. Also, are all the
igt committed or not yet? Pulled these two in meanwhile.
Things are going somewhat broken because you didn't apply my plane
state stuff. Hmm. Actually it sort of looks that it might work by luck
as long as the primary plane doesn't get clipped since this is bashing
the user state directly into the hardware registers and not the derived
state (ie. clipped coordinates).
I was hoping your changes get merged, but not sure why they are held up.
Also I see my review comment about the 90 vs. 270 rotation mixup was
ignored at least.
I never really got the to understand the need of reversing 90 and 270 :)
The last discussion was not concluded, AFAIR.
Things look correct to me and work fine with the testcase also.
Is there something completely different which I am unable to get?
BSpec gives me the impression the hw rotation is cw, whereas the drm one
is ccw.
Yes, HW rotation is cw as per bspec. In drm, where do we consider it as
anti-cw? I assume it is cw because all the macros work as expected, ie cw.
The ccw rule was inherited from XRandR. I'm not sure what macros you
mean, but drm_rect_rotate() will certainly give you wrong results if
you assume cw.
-Sonika
-Daniel
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 24
drivers/gpu/drm/i915/intel_display.c | 88
-
drivers/gpu/drm/i915/intel_drv.h |6 ++
drivers/gpu/drm/i915/intel_sprite.c | 52 -
5 files changed, 131 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..564bbd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4854,7 +4854,9 @@ enum skl_disp_power_wells {
#define PLANE_CTL_ALPHA_HW_PREMULTIPLY ( 3 4)
#define PLANE_CTL_ROTATE_MASK 0x3
#define PLANE_CTL_ROTATE_0 0x0
+#define PLANE_CTL_ROTATE_90 0x1
#define PLANE_CTL_ROTATE_180 0x2
+#define PLANE_CTL_ROTATE_270 0x3
#define _PLANE_STRIDE_1_A0x70188
#define _PLANE_STRIDE_2_A0x70288
#define _PLANE_STRIDE_3_A0x70388
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..a27ee8c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -162,6 +162,30 @@ static int intel_plane_atomic_check(struct
drm_plane *plane,
(1 drm_plane_index(plane));
}
+ if (state-fb intel_rotation_90_or_270(state-rotation)) {
+ if (!(state-fb-modifier[0] == I915_FORMAT_MOD_Y_TILED
||
+ state-fb-modifier[0] ==
I915_FORMAT_MOD_Yf_TILED)) {
+ DRM_DEBUG_KMS(Y/Yf tiling required for
90/270!\n);
+ return -EINVAL;
+ }
+
+ /*
+* 90/270 is not allowed with RGB64 16:16:16:16,
+* RGB 16-bit 5:6:5, and Indexed 8-bit.
+* TBD: Add RGB64 case once its added in supported
format list.
+*/
+ switch (state-fb-pixel_format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ DRM_DEBUG_KMS(Unsupported pixel format %s for
90/270!\n,
+
drm_get_format_name(state-fb-pixel_format));
+ return -EINVAL;
+
+ default:
+ break;
+ }
+ }
+
Re: [Intel-gfx] [PATCH 03/11] drm/i915: Reset changed flags when duplicating crtc state
On Fri, 10 Apr 2015, Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com wrote:
Otherwise, once we start doing atomic updates, the values from a
previous update might be used, leading to unnecessary changes.
Signed-off-by: Ander Conselvan de Oliveira
ander.conselvan.de.olive...@intel.com
---
drivers/gpu/drm/i915/intel_atomic.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 3903b90..f951782 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -222,8 +222,12 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state = kmemdup(intel_crtc-config,
sizeof(*intel_crtc-config), GFP_KERNEL);
- if (crtc_state)
+ if (crtc_state) {
crtc_state-base.crtc = crtc;
+ crtc_state-base.mode_changed = 0;
+ crtc_state-base.active_changed = 0;
+ crtc_state-base.planes_changed = 0;
They are bools, please use false not 0.
BR,
Jani.
+ }
return crtc_state-base;
}
--
2.1.0
___
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 2/2] drm/i915/skl: Support for 90/270 rotation
On Mon, Apr 13, 2015 at 03:53:22PM +0530, Jindal, Sonika wrote: I never really got the to understand the need of reversing 90 and 270 :) The last discussion was not concluded, AFAIR. Things look correct to me and work fine with the testcase also. Is there something completely different which I am unable to get? BSpec gives me the impression the hw rotation is cw, whereas the drm one is ccw. Yes, HW rotation is cw as per bspec. In drm, where do we consider it as anti-cw? I assume it is cw because all the macros work as expected, ie cw. The DRM is quite a direct implementation of the X semantics: http://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt In Randr, the coordinate system is rotated in a counter-clockwise direction relative to the normal orientation This matches the usual orientation of the trigonometric circle. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 66/70] drm/i915: Remove obj-pin_mappable
On 04/07/2015 05:28 PM, Chris Wilson wrote:
The obj-pin_mappable flag only exists for debug purposes and is a
hindrance that is mistreated with rotated GGTT views. For debug
purposes, it suffices to mark objects with pin_display as being of note.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 6 +-
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2e851c6a310c..6508eec3cf60 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -166,9 +166,9 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object
*obj)
}
if (obj-stolen)
seq_printf(m, (stolen: %08llx), obj-stolen-start);
- if (obj-pin_mappable || obj-fault_mappable) {
+ if (obj-pin_display || obj-fault_mappable) {
char s[3], *t = s;
- if (obj-pin_mappable)
+ if (obj-pin_display)
*t++ = 'p';
if (obj-fault_mappable)
*t++ = 'f';
@@ -464,7 +464,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
data)
size += i915_gem_obj_ggtt_size(obj);
++count;
}
- if (obj-pin_mappable) {
+ if (obj-pin_display) {
mappable_size += i915_gem_obj_ggtt_size(obj);
++mappable_count;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eeffefa10612..2c72ee0214b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1980,7 +1980,6 @@ struct drm_i915_gem_object {
* accurate mappable working set.
*/
unsigned int fault_mappable:1;
- unsigned int pin_mappable:1;
unsigned int pin_display:1;
/*
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bd60bb552920..3d4463930267 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4445,9 +4445,6 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
WARN_ON(flags PIN_MAPPABLE !obj-map_and_fenceable);
vma-pin_count++;
- if (flags PIN_MAPPABLE)
- obj-pin_mappable |= true;
-
return 0;
}
@@ -4487,8 +4484,7 @@ i915_gem_object_ggtt_unpin_view(struct
drm_i915_gem_object *obj,
WARN_ON(vma-pin_count == 0);
WARN_ON(!i915_gem_obj_ggtt_bound_view(obj, view));
- if (--vma-pin_count == 0 view-type == I915_GGTT_VIEW_NORMAL)
- obj-pin_mappable = false;
+ --vma-pin_count;
}
bool
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Disable WaGsvRC0ResidencyMethod for vlv
On Thu, 19 Mar 2015, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote: On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote: On Thursday 19 March 2015 05:14 PM, David Weinehall wrote: On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote: From: Deepak S deepa...@linux.intel.com Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some of the baytrail systems :(. Switching back to legacy mode rps. Is there any way to identify either what systems it's OK to use on, or to identif what Baytrail systems it isn't OK to use on? Just reverting this completely seems overly broad if it's possible to tell the difference between working and non-working systems. Restricting the changes to few system will be the right way to go. How do we get details of now working system? That depends. Who reported the non-working Baytrail-systems? And just as importantly, do we have Baytrail systems where this is confirmed to work? If we can identify the respective revisions of the systems we might be able to discern the pattern and continue from there. My experience with random crashes with rps on snb/ivb is that there's no solid systems, just systems where no one has bothered to be really evil yet. I'd be really cautious with whitelisting since it tends to not really solve the underlying bug (if there is one), usually blows up really fast in size and is long-term unmaintainable. We've been there a few times with other hacks and issues :( Plenty of talk but no final verdict on the patch either way, and the bug is still open too. :( Deepak, is this patch still needed? BR, Jani. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ 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 v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On ma, 2015-04-13 at 15:54 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in i915_driver_load(), so removed it. (Animesh) Issue: VIZ-2569 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Animesh Manna
Re: [Intel-gfx] [PATCH] drm/i915: Remove wait for for punit to updates freq.
On Mon, Apr 13, 2015 at 02:55:12PM +0300, Jani Nikula wrote:
On Thu, 05 Mar 2015, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
Deepak, these patches seem to have fallen through the cracks. Are they
still valid? Please rebase and repost if they are.
Ville, your opinion also appreciated.
I don't I have any VLVs old enough to hit this, so can't really confirm
one way or the other.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_pm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index e710b43..2e1ed07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3894,7 +3894,7 @@ static void valleyview_set_rps(struct drm_device
*dev, u8 val)
* * If Gfx is Idle, then
* 1. Mask Turbo interrupts
* 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
+ * 3. Request the freq to Rpn.
* 4. Clear the Force GFX CLK ON bit so that Gfx can down
* 5. Unmask Turbo interrupts
*/
@@ -3902,8 +3902,8 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv-dev;
- /* CHV and latest VLV don't need to force the gfx clock */
- if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+ /* CHV don't need to force the gfx clock */
+ if (IS_CHERRYVIEW(dev)) {
Why was the stepping check removed?
valleyview_set_rps(dev_priv-dev,
dev_priv-rps.min_freq_softlimit);
return;
}
@@ -3920,20 +3920,8 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
gen6_sanitize_rps_pm_mask(dev_priv, ~0));
vlv_force_gfx_clock(dev_priv, true);
-
- dev_priv-rps.cur_freq = dev_priv-rps.min_freq_softlimit;
-
- vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
- dev_priv-rps.min_freq_softlimit);
-
- if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
-GENFREQSTATUS) == 0, 100))
- DRM_ERROR(timed out waiting for Punit\n);
-
+ valleyview_set_rps(dev_priv-dev, dev_priv-rps.min_freq_softlimit);
vlv_force_gfx_clock(dev_priv, false);
-
- I915_WRITE(GEN6_PMINTRMSK,
- gen6_rps_pm_mask(dev_priv, dev_priv-rps.cur_freq));
}
void gen6_rps_idle(struct drm_i915_private *dev_priv)
--
1.9.1
___
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
--
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 15/19] drm/i915: HSW cdclk support
On Fri, 2015-04-10 at 16:10 +0200, Takashi Iwai wrote:
At Fri, 10 Apr 2015 16:27:39 +0300,
Mika Kahola wrote:
On Thu, 2015-04-09 at 17:17 +0200, Takashi Iwai wrote:
At Thu, 9 Apr 2015 15:51:27 +0200,
Daniel Vetter wrote:
On Thu, Apr 09, 2015 at 04:41:26PM +0300, Mika Kahola wrote:
On Thu, 2015-04-09 at 11:32 +0200, Daniel Vetter wrote:
On Thu, Apr 09, 2015 at 10:24:24AM +0300, Mika Kahola wrote:
I did some testing on audio part with HDMI-HDMI and DP-HDMI cables
connected to my Haswell box. Before applying the patch I tested
as a
reference with the latest -nightly (04-08-2015), 4.0-rc7.
Unfortunately,
I failed to get any audio over HDMI cable. For a reference I
tested with
the very same setup the vanillla kernel from Linus tree 4.0-rc7
and with
that kernel the audio worked ok. Then I did some GIT bisecting
and it
turned out that the first commit that I failed to get audio
working was
aa2fee4286e43b4784982b17669b02cc99c1ae55.
I rerun the bisecting and this time the result was
commit 0a599838737a2527c35e4d94f794aefe59df1781
Merge: 2d846c7 a59d719
Author: Takashi Iwai ti...@suse.de
Date: Wed Apr 8 11:29:56 2015 +0200
Merge branch 'for-linus' into for-next
Back merge HD-audio quirks to for-next branch, so that we can
apply
a couple of more quirks.
Signed-off-by: Takashi Iwai ti...@suse.de
Adding Takashi and intel audio folks.
The bisecting looks odd. The commit you pointed is a back-merge from
4.0-rc to next branch, so this merge itself shouldn't bring so many
stuff -- at least about the sound part.
The diff in sound/* is found below. As you can see, the only change
relevant with HDMI is the chunk in sound/pci/hda/hda_intel.c for
HD-audio controller, but it's specific to Skylake, thus this must be
irrelevant with your hardware.
Please double-check.
I double-checked the bisecting and I ended up with the same result. You're
right, it does seems odd why audio on my Haswell box stopped working.
Any ideas how to proceed from here?
Try to check whether the reverting the diff of sound/* manually fixes
the problem. (i.e. apply diff -R for the diff I showed in the
previous mail.)
If it doesn't fix but still reverting the whole commit does fix, it
means that something else got broken by the merge.
Takashi
I reverted the diff but unfortunately there were no difference.
For curiosity, I tested the audio with the latest -nightly and I got
the audio working again. I wonder what has changed but it seems that
the problem is now solved.
-Mika-
Cheers,
Mika
thanks,
Takashi
===
% git diff
0a599838737a2527c35e4d94f794aefe59df1781^..0a599838737a2527c35e4d94f794aefe59df1781
sound
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 9bcc5457a83e..e1c210515581 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1967,7 +1967,7 @@ static const struct pci_device_id azx_ids[] = {
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
/* Sunrise Point */
{ PCI_DEVICE(0x8086, 0xa170),
- .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH },
+ .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
/* Sunrise Point-LP */
{ PCI_DEVICE(0x8086, 0x9d70),
.driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE },
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index e0c06f9a0e80..7f46d063af57 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -396,7 +396,7 @@ static void alc_auto_setup_eapd(struct hda_codec
*codec, bool on)
{
/* We currently only handle front, HP */
static hda_nid_t pins[] = {
- 0x0f, 0x10, 0x14, 0x15, 0
+ 0x0f, 0x10, 0x14, 0x15, 0x17, 0
};
hda_nid_t *p;
for (p = pins; *p; p++)
@@ -2870,6 +2870,8 @@ static void alc283_init(struct hda_codec *codec)
if (!hp_pin)
return;
+
+ msleep(30);
hp_pin_sense = snd_hda_jack_detect(codec, hp_pin);
/* Index 0x43 Direct Drive HP AMP LPM Control 1 */
@@ -3564,6 +3566,7 @@ static void alc_headset_mode_unplugged(struct
hda_codec *codec)
switch (codec-core.vendor_id) {
case 0x10ec0255:
+ case 0x10ec0256:
alc_process_coef_fw(codec, coef0255);
break;
case 0x10ec0233:
@@ -3619,6 +3622,7 @@ static void alc_headset_mode_mic_in(struct
hda_codec *codec, hda_nid_t hp_pin,
switch (codec-core.vendor_id) {
case 0x10ec0255:
+ case 0x10ec0256:
alc_write_coef_idx(codec, 0x45, 0xc489);
snd_hda_set_pin_ctl_cache(codec, hp_pin, 0);
alc_process_coef_fw(codec,
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Support for 90/270 rotation
On 4/13/2015 3:40 PM, Ville Syrjälä wrote:
On Mon, Apr 13, 2015 at 09:36:02AM +0530, Jindal, Sonika wrote:
On 4/10/2015 8:14 PM, Ville Syrjälä wrote:
On Fri, Apr 10, 2015 at 04:17:17PM +0200, Daniel Vetter wrote:
On Fri, Apr 10, 2015 at 02:37:29PM +0530, Sonika Jindal wrote:
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_* for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)
Signed-off-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Matt Roper matthew.d.ro...@intel.com
Patches are missing the Testcase: tag, please add that. Also, are all the
igt committed or not yet? Pulled these two in meanwhile.
Things are going somewhat broken because you didn't apply my plane
state stuff. Hmm. Actually it sort of looks that it might work by luck
as long as the primary plane doesn't get clipped since this is bashing
the user state directly into the hardware registers and not the derived
state (ie. clipped coordinates).
I was hoping your changes get merged, but not sure why they are held up.
Also I see my review comment about the 90 vs. 270 rotation mixup was
ignored at least.
I never really got the to understand the need of reversing 90 and 270 :)
The last discussion was not concluded, AFAIR.
Things look correct to me and work fine with the testcase also.
Is there something completely different which I am unable to get?
BSpec gives me the impression the hw rotation is cw, whereas the drm one
is ccw.
Yes, HW rotation is cw as per bspec. In drm, where do we consider it as
anti-cw? I assume it is cw because all the macros work as expected, ie cw.
-Sonika
-Daniel
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 24
drivers/gpu/drm/i915/intel_display.c | 88
-
drivers/gpu/drm/i915/intel_drv.h |6 ++
drivers/gpu/drm/i915/intel_sprite.c | 52 -
5 files changed, 131 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b522eb6..564bbd5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4854,7 +4854,9 @@ enum skl_disp_power_wells {
#define PLANE_CTL_ALPHA_HW_PREMULTIPLY ( 3 4)
#define PLANE_CTL_ROTATE_MASK 0x3
#define PLANE_CTL_ROTATE_0 0x0
+#define PLANE_CTL_ROTATE_90 0x1
#define PLANE_CTL_ROTATE_180 0x2
+#define PLANE_CTL_ROTATE_270 0x3
#define _PLANE_STRIDE_1_A0x70188
#define _PLANE_STRIDE_2_A0x70288
#define _PLANE_STRIDE_3_A0x70388
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 976b891..a27ee8c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -162,6 +162,30 @@ static int intel_plane_atomic_check(struct drm_plane
*plane,
(1 drm_plane_index(plane));
}
+ if (state-fb intel_rotation_90_or_270(state-rotation)) {
+ if (!(state-fb-modifier[0] == I915_FORMAT_MOD_Y_TILED ||
+ state-fb-modifier[0] == I915_FORMAT_MOD_Yf_TILED)) {
+ DRM_DEBUG_KMS(Y/Yf tiling required for 90/270!\n);
+ return -EINVAL;
+ }
+
+ /*
+* 90/270 is not allowed with RGB64 16:16:16:16,
+* RGB 16-bit 5:6:5, and Indexed 8-bit.
+* TBD: Add RGB64 case once its added in supported format list.
+*/
+ switch (state-fb-pixel_format) {
+ case DRM_FORMAT_C8:
+ case DRM_FORMAT_RGB565:
+ DRM_DEBUG_KMS(Unsupported pixel format %s for
90/270!\n,
+
drm_get_format_name(state-fb-pixel_format));
+ return -EINVAL;
+
+ default:
+ break;
+ }
+ }
+
return intel_plane-check_plane(plane, intel_state);
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f0bbc22..4de544c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2311,13 +2311,6 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
info-pitch = fb-pitches[0];
info-fb_modifier =
[Intel-gfx] [PATCH] lib: Implement gem_sync() using WAIT
When synchronising to rendering, we only want to wait for it to complete
and avoid the cache-domain side-effects of SET_DOMAIN if possible. This
has the advantage of speeding up a few tests (and thereby making the
actual test more explicit in terms of kernel operations). Of course some
tests may be reliant on the side-effects...
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
lib/ioctl_wrappers.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index dec45f1..000d394 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -371,12 +371,22 @@ void gem_set_domain(int fd, uint32_t handle,
* @fd: open i915 drm file descriptor
* @handle: gem buffer object handle
*
- * This is a wrapper around gem_set_domain() which simply blocks for any
- * outstanding rendering to complete.
+ * This functions waits for outstanding rendering to complete.
*/
void gem_sync(int fd, uint32_t handle)
{
- gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+ struct drm_i915_gem_wait wait;
+
+ memset(wait, 0, sizeof(wait));
+ wait.bo_handle = handle;
+ wait.timeout_ns =-1;
+ if (drmIoctl(fd, DRM_IOCTL_I915_GEM_WAIT, wait) == 0) {
+ errno = 0;
+ return;
+ }
+
+ gem_set_domain(fd, handle,
+ I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
}
uint32_t __gem_create(int fd, int size)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/chv: Remove DPIO force latency causing interpair skew issue
On Sat, 11 Apr 2015, shuang...@intel.com wrote: Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6167 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 302/302 302/302 SNB -31 313/313 282/313 The patch does not touch SNB code paths, what gives? BR, Jani. IVB 337/337 337/337 BYT 286/286 286/286 HSW 395/395 395/395 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied SNB igt@kms_flip@bo-too-big-interruptible DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip_event_leak DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip@flip-vs-dpms-off-vs-modeset DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip@flip-vs-dpms-off-vs-modeset-interruptible DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip@nonexisting-fb DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip@nonexisting-fb-interruptible DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip@single-buffer-flip-vs-dpms-off-vs-modeset-interruptible DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_flip_tiling@flip-changes-tiling DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting SNB igt@kms_rotation_crc@primary-rotation DMESG_WARN(5)PASS(3) DMESG_WARN(2) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train
Re: [Intel-gfx] [PATCH] drm/i915: Allow userptr backchannel for passing aroung GTT mappings
On 04/02/2015 05:27 PM, Chris Wilson wrote:
On Thu, Apr 02, 2015 at 05:11:58PM +0100, Tvrtko Ursulin wrote:
+static struct drm_i915_gem_object *
+find_object_from_vma(struct drm_device *dev,
+struct drm_i915_gem_userptr *args)
+{
+ struct drm_i915_gem_object *obj = NULL;
+ struct vm_area_struct *vma;
+
+ down_read(current-mm-mmap_sem);
+ vma = find_vma(current-mm, args-user_ptr);
+ if (vma == NULL)
+ goto out;
+
+ if (vma-vm_ops != dev-driver-gem_vm_ops)
+ goto out;
+
+ if (vma-vm_start != args-user_ptr ||
+ vma-vm_end != args-user_ptr + args-user_size) {
+ obj = ERR_PTR(-EINVAL);
+ goto out;
+ }
+
+ obj = to_intel_bo(vma-vm_private_data);
+ drm_gem_object_reference(obj);
Hm, can't this race with last unreference in general, and with
cleanup worker with userptr objects?
The vma holds a reference to the object and that reference is dropped
whilst holding down_write(current-mm-mmap_sem), hence I think the
down_read(current-mm-mmap_sem) is sufficient locking to acquire a
reference for ourselves.
Yes, I completely forgot about this little detail. :)
+out:ret = drm_gem_handle_create(file, obj-base, handle);
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(obj-base);
Thing I don't like is how the user of this has no idea what kind of
object it imported. Maybe it doesn't matter, hm. Need to think
about it more.
Indeed. But since the userptr is a strict subset of the general bo, if
they follow the rules for userptr bo then they won't notice a
difference. read/writes into the memory block are coherent (since the
pointer is wc) so as far the caller is concerned I think it just ends up
being slower cpu side, faster gpu side than a system memory snooped
userptr bo.
Is access to non-userptr bo's interesting to users of this - could we
reject that and not lose out?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove wait for for punit to updates freq.
On Thu, 05 Mar 2015, deepa...@linux.intel.com wrote:
From: Deepak S deepa...@linux.intel.com
When GPU is idle on VLV, Request freq to punit should be good enough to
get the voltage back to VNN. Also, make sure gfx clock force applies
before requesting the freq fot vlv.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75244
suggested-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Deepak S deepa...@linux.intel.com
Deepak, these patches seem to have fallen through the cracks. Are they
still valid? Please rebase and repost if they are.
Ville, your opinion also appreciated.
BR,
Jani.
---
drivers/gpu/drm/i915/intel_pm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e710b43..2e1ed07 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3894,7 +3894,7 @@ static void valleyview_set_rps(struct drm_device *dev,
u8 val)
* * If Gfx is Idle, then
* 1. Mask Turbo interrupts
* 2. Bring up Gfx clock
- * 3. Change the freq to Rpn and wait till P-Unit updates freq
+ * 3. Request the freq to Rpn.
* 4. Clear the Force GFX CLK ON bit so that Gfx can down
* 5. Unmask Turbo interrupts
*/
@@ -3902,8 +3902,8 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
{
struct drm_device *dev = dev_priv-dev;
- /* CHV and latest VLV don't need to force the gfx clock */
- if (IS_CHERRYVIEW(dev) || dev-pdev-revision = 0xd) {
+ /* CHV don't need to force the gfx clock */
+ if (IS_CHERRYVIEW(dev)) {
valleyview_set_rps(dev_priv-dev,
dev_priv-rps.min_freq_softlimit);
return;
}
@@ -3920,20 +3920,8 @@ static void vlv_set_rps_idle(struct drm_i915_private
*dev_priv)
gen6_sanitize_rps_pm_mask(dev_priv, ~0));
vlv_force_gfx_clock(dev_priv, true);
-
- dev_priv-rps.cur_freq = dev_priv-rps.min_freq_softlimit;
-
- vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ,
- dev_priv-rps.min_freq_softlimit);
-
- if (wait_for(((vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS))
- GENFREQSTATUS) == 0, 100))
- DRM_ERROR(timed out waiting for Punit\n);
-
+ valleyview_set_rps(dev_priv-dev, dev_priv-rps.min_freq_softlimit);
vlv_force_gfx_clock(dev_priv, false);
-
- I915_WRITE(GEN6_PMINTRMSK,
-gen6_rps_pm_mask(dev_priv, dev_priv-rps.cur_freq));
}
void gen6_rps_idle(struct drm_i915_private *dev_priv)
--
1.9.1
___
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 v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On 04/13/2015 04:33 PM, Imre Deak wrote: On ma, 2015-04-13 at 15:54 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in i915_driver_load(), so removed it. (Animesh) Issue: VIZ-2569 Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com Signed-off-by: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Animesh Manna animesh.ma...@intel.com Signed-off-by: Imre Deak imre.d...@intel.com ---
[Intel-gfx] [PATCH] Remove illogical/bogus Automatic mode from Broadcast RGB property
https://bugzilla.kernel.org/show_bug.cgi?id=94921
As mentioned in the above bug report, switching output color range
Automatically according to current mode does not make sense in computer use
case.
---
drivers/gpu/drm/i915/i915_drv.h| 5 ++---
drivers/gpu/drm/i915/intel_dp.c| 23 ++-
drivers/gpu/drm/i915/intel_hdmi.c | 20 ++--
drivers/gpu/drm/i915/intel_modes.c | 1 -
drivers/gpu/drm/i915/intel_sdvo.c | 29 +
5 files changed, 11 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8727086..2385732 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3287,9 +3287,8 @@ int intel_freq_opcode(struct drm_i915_private *dev_priv,
int val);
#define POSTING_READ16(reg)(void)I915_READ16_NOTRACE(reg)
/* Broadcast RGB property */
-#define INTEL_BROADCAST_RGB_AUTO 0
-#define INTEL_BROADCAST_RGB_FULL 1
-#define INTEL_BROADCAST_RGB_LIMITED 2
+#define INTEL_BROADCAST_RGB_FULL 0
+#define INTEL_BROADCAST_RGB_LIMITED 1
static inline uint32_t i915_vgacntrl_reg(struct drm_device *dev)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a74aaf9..a9ed631 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1238,18 +1238,6 @@ intel_dp_compute_config(struct intel_encoder *encoder,
return false;
found:
- if (intel_dp-color_range_auto) {
- /*
-* See:
-* CEA-861-E - 5.1 Default Encoding Parameters
-* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
-*/
- if (bpp != 18 drm_match_cea_mode(adjusted_mode) 1)
- intel_dp-color_range = DP_COLOR_RANGE_16_235;
- else
- intel_dp-color_range = 0;
- }
-
if (intel_dp-color_range)
pipe_config-limited_color_range = true;
@@ -4220,27 +4208,20 @@ intel_dp_set_property(struct drm_connector *connector,
}
if (property == dev_priv-broadcast_rgb_property) {
- bool old_auto = intel_dp-color_range_auto;
uint32_t old_range = intel_dp-color_range;
switch (val) {
- case INTEL_BROADCAST_RGB_AUTO:
- intel_dp-color_range_auto = true;
- break;
case INTEL_BROADCAST_RGB_FULL:
- intel_dp-color_range_auto = false;
intel_dp-color_range = 0;
break;
case INTEL_BROADCAST_RGB_LIMITED:
- intel_dp-color_range_auto = false;
intel_dp-color_range = DP_COLOR_RANGE_16_235;
break;
default:
return -EINVAL;
}
- if (old_auto == intel_dp-color_range_auto
- old_range == intel_dp-color_range)
+ if (old_range == intel_dp-color_range)
return 0;
goto done;
@@ -4548,7 +4529,7 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
- intel_dp-color_range_auto = true;
+ intel_dp-color_range = 0;
if (is_edp(intel_dp)) {
drm_mode_create_scaling_mode_property(connector-dev);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 995c5b2..4fff5c6 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -990,15 +990,6 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
if (pipe_config-has_hdmi_sink)
pipe_config-has_infoframe = true;
- if (intel_hdmi-color_range_auto) {
- /* See CEA-861-E - 5.1 Default Encoding Parameters */
- if (pipe_config-has_hdmi_sink
- drm_match_cea_mode(adjusted_mode) 1)
- intel_hdmi-color_range = HDMI_COLOR_RANGE_16_235;
- else
- intel_hdmi-color_range = 0;
- }
-
if (adjusted_mode-flags DRM_MODE_FLAG_DBLCLK) {
pipe_config-pixel_multiplier = 2;
}
@@ -1196,27 +1187,20 @@ intel_hdmi_set_property(struct drm_connector *connector,
}
if (property == dev_priv-broadcast_rgb_property) {
- bool old_auto = intel_hdmi-color_range_auto;
uint32_t old_range = intel_hdmi-color_range;
switch (val) {
- case INTEL_BROADCAST_RGB_AUTO:
- intel_hdmi-color_range_auto = true;
- break;
case INTEL_BROADCAST_RGB_FULL:
- intel_hdmi-color_range_auto = false;
[Intel-gfx] [PATCH] drm/i915: Fix screen flickering on X
A bisect showed that commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68
introduced the issue.
The issue starts as soon as X takes control of the screen, even if just
a plain X doing nothing, so based on the code touched by the commit I
thought it had to be related to the so called hardware cursor. I
confirmed it when hiding the cursor made the flickering go away.
The aforementioned commit removed some suspicious code, and the
Programmer's Reference Manual confirmed my suspicion:
Incorrectly programmed watermark values can result in screen corruption.
The watermarks should be calculated and programmed when any of the
watermark calculation inputs change. This includes planes enabling or
disabling, plane source format or size changing, etc.
So I'm re-adding the few lines that update the watermarks after a cursor
size change.
Signed-off-by: Ismael Luceno ism...@iodev.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f75173c..e23f062 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12258,6 +12258,7 @@ intel_commit_cursor_plane(struct drm_plane *plane,
struct intel_crtc *intel_crtc;
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_i915_gem_object *obj = intel_fb_obj(state-base.fb);
+ unsigned old_width;
uint32_t addr;
crtc = crtc ? crtc : plane-crtc;
@@ -12282,11 +12283,15 @@ intel_commit_cursor_plane(struct drm_plane *plane,
intel_crtc-cursor_addr = addr;
intel_crtc-cursor_bo = obj;
update:
+ old_width = intel_crtc-cursor_width;
intel_crtc-cursor_width = state-base.crtc_w;
intel_crtc-cursor_height = state-base.crtc_h;
- if (intel_crtc-active)
+ if (intel_crtc-active) {
+ if (old_width != intel_crtc-cursor_width)
+ intel_update_watermarks(crtc);
intel_crtc_update_cursor(crtc, state-visible);
+ }
}
static struct drm_plane *intel_cursor_plane_create(struct drm_device *dev,
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add missing MacBook Pro models with dual channel LVDS
All 17 models with i915 graphics had a resolution of 1920x1200,
necessitating dual channel LVDS. The 15 pre-retina models had
up to 1680x1050, hence used dual channel LVDS as well.
Reference for MacBookPro9,1 (also tested by myself):
http://ubuntuforums.org/showthread.php?t=2224567
Reference for MacBookPro8,2 / 8,3:
https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011)
Reference for MacBookPro6,2:
https://bbs.archlinux.org/viewtopic.php?id=185770
Signed-off-by: Lukas Wunner lu...@wunner.de
---
drivers/gpu/drm/i915/intel_lvds.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 071b96d..ee1000f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -812,12 +812,44 @@ static int intel_dual_link_lvds_callback(const struct
dmi_system_id *id)
static const struct dmi_system_id intel_dual_link_lvds[] = {
{
.callback = intel_dual_link_lvds_callback,
- .ident = Apple MacBook Pro (Core i5/i7 Series),
+ .ident = Apple MacBook Pro 17\ (2010),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro6,1),
+ },
+ },
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 15\ (2010),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro6,2),
+ },
+ },
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 15\ (2011),
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro8,2),
},
},
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 17\ (2011),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro8,3),
+ },
+ },
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 15\ (2012),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro9,1),
+ },
+ },
{ } /* terminating entry */
};
--
1.8.5.2 (Apple Git-48)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Remove illogical/bogus Automatic mode from Broadcast RGB property
On Wed, Apr 08, 2015 at 07:18:06PM +0800, Tom Yan wrote: https://bugzilla.kernel.org/show_bug.cgi?id=94921 As mentioned in the above bug report, switching output color range Automatically according to current mode does not make sense in computer use case. Current code seems correct to me after re-reading CEA-861-E again. However can we do better? Maybe! From the spec: The QS (AVI Q support) bit of byte 3 allows a display to declare that it supports the reception of either type of quantization range for any video format, under the direction of InfoFrame Q data (see Section 6.4 for information concerning bits Q1 and Q0). This allows a source to override the default quantization range for any video format. If the sink declares a selectable RGB Quantization Range (QS=1) then it shall expect limited range pixel values if it receives Q=1 and it shall expect full range pixel values if it receives Q=2 (see section 6.4). For other values of Q, the sink shall expect pixel values with the default range for the transmitted video format. So, for sinks that support it, we could default to sending the full range picture and overriding the quantization bit in the AVI infoframe. You could you try to run edid-decode [1] on your sink EDID to check if it supports overriding the quantization level (I added decoding the VCDB a while back). Ville, what do you think? -- Damien [1] http://cgit.freedesktop.org/xorg/app/edid-decode ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 2/2] tests/gem_mmap_gtt: add huge BO test
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by CPU directly and through GTT in sequence.
Currently it is expected for the GTT access to gracefully fail as
all objects are attempted to get pinned to GTT completely for mmap
access. Once the partial view support is merged to kernel, the test
should pass for all parts.
v2:
- Corrected BO domain handling (Chris Wilson)
- Check again after GTT access for added paranoia (Chris Wilson)
v3:
- Avoid flush by using pread (Chris Wilson)
- Free gtt_pattern buffer too.
v4:
- Add more comments (Tvrtko Ursulin)
- Use igt_require (Tvrtko Ursulin)
Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
tests/gem_mmap_gtt.c | 106 +++
1 file changed, 106 insertions(+)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index 115e398..5888c7d 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -41,6 +41,10 @@
#include drmtest.h
#include igt_debugfs.h
+#ifndef PAGE_SIZE
+#define PAGE_SIZE 4096
+#endif
+
static int OBJECT_SIZE = 16*1024*1024;
static void
@@ -55,6 +59,20 @@ set_domain_cpu(int fd, uint32_t handle)
gem_set_domain(fd, handle, I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
}
+static void
+pread_bo(int fd, int handle, void *buf, int offset, int size)
+{
+ struct drm_i915_gem_pread gem_pread;
+
+ memset(gem_pread, 0, sizeof(gem_pread));
+ gem_pread.handle = handle;
+ gem_pread.data_ptr = (uintptr_t)buf;
+ gem_pread.size = size;
+ gem_pread.offset = offset;
+
+ igt_assert(ioctl(fd, DRM_IOCTL_I915_GEM_PREAD, gem_pread) == 0);
+}
+
static void *
mmap_bo(int fd, uint32_t handle)
{
@@ -265,6 +283,92 @@ test_write_gtt(int fd)
}
static void
+test_huge_bo(int fd)
+{
+ uint32_t bo;
+ char *ptr_cpu;
+ char *ptr_gtt;
+ char *cpu_pattern;
+ char *gtt_pattern;
+ uint64_t mappable_aperture_pages = gem_mappable_aperture_size() /
+ PAGE_SIZE;
+ uint64_t huge_object_size = (mappable_aperture_pages + 1) * PAGE_SIZE;
+ uint64_t last_offset = huge_object_size - PAGE_SIZE;
+
+ cpu_pattern = malloc(PAGE_SIZE);
+ gtt_pattern = malloc(PAGE_SIZE);
+ igt_assert(cpu_pattern gtt_pattern);
+ memset(cpu_pattern, 0xaa, PAGE_SIZE);
+ memset(gtt_pattern, ~0xaa, PAGE_SIZE);
+
+ bo = gem_create(fd, huge_object_size);
+
+ /* Obtain CPU mapping for the object. */
+ ptr_cpu = gem_mmap__cpu(fd, bo, 0, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ igt_require_f(ptr_cpu, Can not allocate memory for test.\n);
+
+ set_domain_cpu(fd, bo);
+
+ /* Write first page through the mapping and assert reading it back
+* works. */
+ memcpy(ptr_cpu, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu, cpu_pattern, PAGE_SIZE) == 0);
+
+ /* Write last page through the mapping and assert reading it back
+* works. */
+ memcpy(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ /* Cross check that accessing two simultaneous pages works. */
+ igt_assert(memcmp(ptr_cpu, ptr_cpu + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_cpu, huge_object_size);
+ ptr_cpu = NULL;
+
+ /* Obtain mapping for the object through GTT. */
+ ptr_gtt = gem_mmap__gtt(fd, bo, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ igt_require_f(ptr_gtt, Huge BO GTT mapping not supported.\n);
+
+ set_domain_gtt(fd, bo);
+
+ /* Access through GTT should still provide the CPU written values. */
+ igt_assert(memcmp(ptr_gtt , cpu_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ /* Try replacing first page through GTT mapping and make sure other page
+* stays intact. */
+ memcpy(ptr_gtt, gtt_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt , gtt_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ /* And make sure that after writing, both pages contain what they
+* should.*/
+ memcpy(ptr_gtt + last_offset, gtt_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt , gtt_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, gtt_pattern, PAGE_SIZE) == 0);
+
+ munmap(ptr_gtt, huge_object_size);
+ ptr_gtt = NULL;
+
+ /* Verify the page contents after GTT writes by reading without mapping.
+* Mapping to CPU domain is avoided not to cause a huge flush.
+*/
+ pread_bo(fd, bo, cpu_pattern, 0,
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_mmap_gtt: add huge BO test
On ma, 2015-04-13 at 12:32 +0100, Tvrtko Ursulin wrote:
Hi,
On 04/07/2015 01:23 PM, Joonas Lahtinen wrote:
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by CPU directly and through GTT in sequence.
Currently it is expected for the GTT access to gracefully fail as
all objects are attempted to get pinned to GTT completely for mmap
access. Once the partial view support is merged to kernel, the test
should pass for all parts.
Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
tests/gem_mmap_gtt.c | 68
1 file changed, 68 insertions(+)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index 55c66a2..bf3627c 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -41,6 +41,10 @@
#include drmtest.h
#include igt_debugfs.h
+#ifndef PAGE_SIZE
+#define PAGE_SIZE 4096
+#endif
+
static int OBJECT_SIZE = 16*1024*1024;
static void set_domain(int fd, uint32_t handle)
@@ -258,6 +262,68 @@ test_write_gtt(int fd)
}
static void
+test_huge_bo(int fd)
+{
+ uint32_t bo;
+ char *ptr_cpu;
+ char *ptr_gtt;
+ char *cpu_pattern;
+ uint64_t mappable_aperture_pages = gem_mappable_aperture_size() /
+ PAGE_SIZE;
+ uint64_t huge_object_size = (mappable_aperture_pages + 1) * PAGE_SIZE;
+ uint64_t last_offset = huge_object_size - PAGE_SIZE;
+
+ cpu_pattern = malloc(PAGE_SIZE);
+ igt_assert(cpu_pattern);
I'd be tempted to use 4k from the stack for simplicity.
It's not a nice thing to allocate two 4k objects from stack. So lets
just not.
+ memset(cpu_pattern, 0xaa, PAGE_SIZE);
+
+ bo = gem_create(fd, huge_object_size);
+
+ ptr_cpu = gem_mmap__cpu(fd, bo, 0, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_cpu) {
+ igt_warn(Not enough free memory for huge BO test!\n);
+ goto out;
Free address space or free memory?
It is not really relevant to the test which condition caused it. But
yeah, correcting the error message into 'Can not allocate memory'.
Also, igt_require so test skips in that case?
Ack using igt_require_f. Because the condition is bit unclear without
the text.
+ }
+
+ /* Test read/write to first/last page with CPU. */
+ memcpy(ptr_cpu, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu, cpu_pattern, PAGE_SIZE) == 0);
+
+ memcpy(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ igt_assert(memcmp(ptr_cpu, ptr_cpu + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_cpu, huge_object_size);
+ ptr_cpu = NULL;
+
+ ptr_gtt = gem_mmap__gtt(fd, bo, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_gtt) {
+ igt_debug(Huge BO GTT mapping not supported!\n);
+ goto out;
igt_require as above? Hm, although ideally test would be able to detect
the feature (once it is added to the kernel) so it could assert here.
I think the point is somewhat that UMP should not need to know/care
about it. Before introducing the feature the above will always fail, and
after introducing it, it will always succeed (unless there is less than
1MB aperture space available). So I think it should be good as it is.
+ }
+
+ /* Test read/write to first/last page through GTT. */
+ set_domain(fd, bo);
+
+ igt_assert(memcmp(ptr_gtt, cpu_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt + last_offset, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt, ptr_gtt + last_offset, PAGE_SIZE) == 0);
Comments for the above would be nice just to explain what is being
tested and how.
The level of commenting was higher already than I noticed to be in other
tests, but I'll add a few more.
Won't the last test has side effects with partial views since it is
accessing beginning and end of the object? Would it be better to memcmp
against a pattern on stack or in heap like cpu_pattern?
Will you support two simultaneous partial views or the last memcmp will
cause a lot of partial view creation/destruction?
Yes, there will be multiple partial views, but it's all internal to the
kernel implementation. Above access pattern should be supported.
Regards, Joonas
+
+ munmap(ptr_gtt, huge_object_size);
+out:
+ gem_close(fd, bo);
+ free(cpu_pattern);
+}
+
+static void
test_read(int fd)
{
void *dst;
@@ -395,6 +461,8 @@ igt_main
run_without_prefault(fd, test_write_gtt);
[Intel-gfx] [PATCH 06/13] drm: Add supporting structure for Displayport Link CTS test 4.2.2.6
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the checksum and
compare it to the value stored in the last byte of the block data.
Unfortunately, the DRM EDID reading and parsing functions are actually too good
in this case; the header is fixed before the checksum is computed and thus the
code never sees the invalid checksum. This results in a failure to pass the
compliance test.
To correct this issue, a checksum is generated when the EDID header is detected
as corrupted. If the checksum is invalid, it sets the header_corrupt flag and
logs the errors. In the case of a more seriously damaged header (fixup score
less than the threshold) the code does not generate the checksum but does set
the header_corrupt flag.
V2:
- Removed the static bool global
- Added a bool to the drm_connector struct to reaplce the static one for
holding the status of raw edid header corruption detection
- Modified the function signature of the is_valid function to take an
additional parameter to store the corruption detected value
- Fixed the other callers of the above is_valid function
V3:
- Updated the commit message to be more clear about what and why this
patch does what it does.
- Added comment in code to clarify the operations there
- Removed compliance variable and check_link_status update; those
have been moved to a later patch
- Removed variable assignment from the bottom of the test handler
V4:
- Removed i915 tag from subject line as the patch is not i915-specific
V5:
- Moved code causing a compilation error to this patch where the variable
is actually declared
Signed-off-by: Todd Previte tprev...@gmail.com
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/drm_edid.c| 31 ++-
drivers/gpu/drm/drm_edid_load.c | 7 +--
drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++--
drivers/gpu/drm/i915/intel_dp.c | 2 +-
include/drm/drm_crtc.h| 8 +++-
5 files changed, 41 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 53bc7a6..12e5be7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1005,7 +1005,6 @@ int drm_edid_header_is_valid(const u8 *raw_edid)
for (i = 0; i sizeof(edid_header); i++)
if (raw_edid[i] == edid_header[i])
score++;
-
return score;
}
EXPORT_SYMBOL(drm_edid_header_is_valid);
@@ -1047,7 +1046,8 @@ static bool drm_edid_is_zero(const u8 *in_edid, int
length)
*
* Return: True if the block is valid, false otherwise.
*/
-bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid)
+bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
+ bool *header_corrupt)
{
u8 csum;
struct edid *edid = (struct edid *)raw_edid;
@@ -1062,9 +1062,27 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool
print_bad_edid)
int score = drm_edid_header_is_valid(raw_edid);
if (score == 8) ;
else if (score = edid_fixup) {
+ /* Displayport Link CTS Core 1.2 rev1.1 test 4.2.2.6
+* In order to properly generate the invalid checksum
+* required for this test, it must be generated using
+* the raw EDID data. Otherwise, the fix-up code here
+* will correct the problem, the checksum is then
correct
+* and the test fails
+*/
+ csum = drm_edid_block_checksum(raw_edid);
+ if (csum) {
+ DRM_DEBUG_DRIVER(Invalid EDID header, score =
%d\n, score);
+ DRM_DEBUG_DRIVER(Invalid EDID checksum %d\n,
csum);
+ if (header_corrupt)
+ *header_corrupt = 1;
+ }
DRM_DEBUG(Fixing EDID header, your hardware may be
failing\n);
memcpy(raw_edid, edid_header, sizeof(edid_header));
} else {
+ if (header_corrupt) {
+ DRM_DEBUG_DRIVER(Invalid EDID header\n);
+ *header_corrupt = 1;
+ }
goto bad;
}
}
@@ -1129,7 +1147,7 @@ bool drm_edid_is_valid(struct edid *edid)
return false;
for (i = 0; i = edid-extensions; i++)
- if (!drm_edid_block_valid(raw + i * EDID_LENGTH, i, true))
+ if (!drm_edid_block_valid(raw + i * EDID_LENGTH, i, true, NULL))
return false;
Re: [Intel-gfx] [PATCH 34/49] drm/i915/bxt: Restrict PORT_CLK_SEL programming below gen9
On ma, 2015-04-13 at 14:21 +0100, Damien Lespiau wrote: On Sun, Apr 12, 2015 at 03:52:12PM +0530, sagar.a.kam...@intel.com wrote: For patch at http://lists.freedesktop.org/archives/intel-gfx/2015-March/062169.html Reviewed-by: Sagar Kamble sagar.a.kamble at intel.com Usually reviews are done as a reply to the patch, but maybe you didn't receive the earlier mail? - I915_WRITE(PORT_CLK_SEL(port), -intel_crtc-config-ddi_pll_sel); + /* FIXME: add support for SKL */ + if (!INTEL_INFO(dev)-gen 9) + I915_WRITE(PORT_CLK_SEL(port), +intel_crtc-config-ddi_pll_sel); This '!' looks fishy to me. Yes, that's a typo from me. Will fix it, thanks for catching it. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 27/49] drm/i915/bxt: Enable GMBUS IRQ
On Fri, 10 Apr 2015, Imre Deak imre.d...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
GMBUS interrupt has been moved to CPU side in BXT.
What this patch does is:
1. Enable GMBUS IRQ in de_post_install function
2. Handle this interrupt as a port interrupt in display irq
handler
v2: Rebase on top of the for_each_pipe() change adding dev_priv as
first argument (Damien).
v3: read BXT_DE_PORT_GMBUS IIR flag only on BXT on other platforms
it's reserved (imre)
v4: (jani)
- remove redundant 'BXT GMBUS' comment
- fix formatting of BXT_DE_PORT_GMBUS definition
Reviewed-by: Satheeshakrishna M satheeshakrishn...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Shashank Sharma shashank.sha...@intel.com (v1)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Jani Nikula jani.nik...@intel.com
Yup. ^
---
drivers/gpu/drm/i915/i915_irq.c | 14 +++---
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a185f44..5417d5a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2244,6 +2244,11 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
found = true;
}
+ if (IS_BROXTON(dev) (tmp BXT_DE_PORT_GMBUS)) {
+ gmbus_irq_handler(dev);
+ found = true;
+ }
+
if (!found)
DRM_ERROR(Unexpected DE Port interrupt\n);
}
@@ -3518,13 +3523,16 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
uint32_t de_pipe_masked = GEN8_PIPE_CDCLK_CRC_DONE;
uint32_t de_pipe_enables;
int pipe;
- u32 aux_en = GEN8_AUX_CHANNEL_A;
+ u32 de_port_en = GEN8_AUX_CHANNEL_A;
if (IS_GEN9(dev_priv)) {
de_pipe_masked |= GEN9_PIPE_PLANE1_FLIP_DONE |
GEN9_DE_PIPE_IRQ_FAULT_ERRORS;
- aux_en |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
+ de_port_en |= GEN9_AUX_CHANNEL_B | GEN9_AUX_CHANNEL_C |
GEN9_AUX_CHANNEL_D;
+
+ if (IS_BROXTON(dev_priv))
+ de_port_en |= BXT_DE_PORT_GMBUS;
} else
de_pipe_masked |= GEN8_PIPE_PRIMARY_FLIP_DONE |
GEN8_DE_PIPE_IRQ_FAULT_ERRORS;
@@ -3543,7 +3551,7 @@ static void gen8_de_irq_postinstall(struct
drm_i915_private *dev_priv)
dev_priv-de_irq_mask[pipe],
de_pipe_enables);
- GEN5_IRQ_INIT(GEN8_DE_PORT_, ~aux_en, aux_en);
+ GEN5_IRQ_INIT(GEN8_DE_PORT_, ~de_port_en, de_port_en);
}
static int gen8_irq_postinstall(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 670a9d4..4950aa4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5266,6 +5266,7 @@ enum skl_disp_power_wells {
BXT_DE_PORT_HP_DDIB | \
BXT_DE_PORT_HP_DDIC)
#define GEN8_PORT_DP_A_HOTPLUG (1 3)
+#define BXT_DE_PORT_GMBUS (1 1)
#define GEN8_AUX_CHANNEL_A (1 0)
#define GEN8_DE_MISC_ISR 0x44460
--
1.9.1
--
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 2/8] drm/i915/skl: Implement enable/disable for Display C5 sttate.
On ma, 2015-04-13 at 14:17 +0100, Damien Lespiau wrote: On Thu, Apr 02, 2015 at 06:58:22PM +0300, Imre Deak wrote: On ke, 2015-04-01 at 16:22 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com This patch just implements the basic enable and disable functions of DC5 state which is needed for both SKL and BXT. Reviewed-by: Imre Deak imre.d...@intel.com For the record, this patch generates compilation warnings when applied on its own: drivers/gpu/drm/i915/intel_runtime_pm.c:368:13: warning: ‘gen9_enable_dc5’ defined but not used [-Wunused-function] static void gen9_enable_dc5(struct drm_i915_private *dev_priv) ^ drivers/gpu/drm/i915/intel_runtime_pm.c:386:13: warning: ‘gen9_disable_dc5’ defined but not used [-Wunused-function] static void gen9_disable_dc5(struct drm_i915_private *dev_priv) ^ Generally speaking, in a series, each step should compile without warning and result in a working driver (for bisectability). Yes, agreed. Splitting the changes into patches could've been done in better a way. I also commented on a related topic of adding something in the patchset and removing it later. We'll try to pay more attention to this in the future. Animesh, if you resend this patchset anyway I think you could switch the order of 2/8 and 3/8 and add the calls to the above functions in this patch to get rid of the warnings. Also please make sure that things compile without a warning after each patch as Damien suggested. --Imre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/11] drm/i915: Add EDID read in intel_dp_check_link_status() for Link CTS 4.2.2.1
2015-04-10 13:12 GMT-03:00 Todd Previte tprev...@gmail.com:
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in the
Displayport Link CTS Core 1.2 rev1.1. This test requires an EDID read for
all HPD plug events. To reduce the amount of code, this EDID read is also
used for Link CTS tests 4.2.2.3, 4.2.2.4, 4.2.2.5 and 4.2.2.6. Actual
support for these tests is implemented in later patches in this series.
Signed-off-by: Todd Previte tprev...@gmail.com
drivers/gpu/drm/i915/intel_dp.c: In function ‘intel_dp_check_link_status’:
drivers/gpu/drm/i915/intel_dp.c:4140:36: error: ‘struct drm_connector’
has no member named ‘edid_header_corrupt’
if (!edid_read || connector-edid_header_corrupt == 1) {
scripts/Makefile.build:258: recipe for target
'drivers/gpu/drm/i915/intel_dp.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_dp.o] Error 1
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 23184b0..a5dfaff 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3890,6 +3890,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
+ struct drm_connector *connector = intel_dp-attached_connector-base;
+ struct i2c_adapter *adapter = intel_dp-aux.ddc;
+ struct edid *edid_read = NULL;
u8 sink_irq_vector;
u8 link_status[DP_LINK_STATUS_SIZE];
@@ -3906,6 +3909,14 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
+ /* Displayport Link CTS Core 1.2 rev1.1 EDID testing
+* 4.2.2.1 - EDID read required for all HPD events
+ */
+edid_read = drm_get_edid(connector, adapter);
+if (!edid_read || connector-edid_header_corrupt == 1) {
+DRM_DEBUG_DRIVER(Invalid EDID detected\n);
+}
+
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11
intel_dp_get_sink_irq(intel_dp, sink_irq_vector)) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Remove illogical/bogus Automatic mode from Broadcast RGB property
On Mon, Apr 13, 2015 at 03:13:12PM +0100, Damien Lespiau wrote: On Wed, Apr 08, 2015 at 07:18:06PM +0800, Tom Yan wrote: https://bugzilla.kernel.org/show_bug.cgi?id=94921 As mentioned in the above bug report, switching output color range Automatically according to current mode does not make sense in computer use case. Current code seems correct to me after re-reading CEA-861-E again. However can we do better? Maybe! From the spec: The QS (AVI Q support) bit of byte 3 allows a display to declare that it supports the reception of either type of quantization range for any video format, under the direction of InfoFrame Q data (see Section 6.4 for information concerning bits Q1 and Q0). This allows a source to override the default quantization range for any video format. If the sink declares a selectable RGB Quantization Range (QS=1) then it shall expect limited range pixel values if it receives Q=1 and it shall expect full range pixel values if it receives Q=2 (see section 6.4). For other values of Q, the sink shall expect pixel values with the default range for the transmitted video format. So, for sinks that support it, we could default to sending the full range picture and overriding the quantization bit in the AVI infoframe. You could you try to run edid-decode [1] on your sink EDID to check if it supports overriding the quantization level (I added decoding the VCDB a while back). Ville, what do you think? Sure, if you can actually find a display that supports the Q bit. I've not seen one yet :( They should have just made it mandatory, otherwise I fear it's never going to catch on. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 26/49] drm/i915/bxt: Add BXT support in gen8_irq functions
From: Shashank Sharma shashank.sha...@intel.com
This patch adds conditional checks in gen8_irq functions
to support BXT. Most of the checks just look for PCH split
availability, and block the call to PCH interrupt functions if
not available.
v2: (jani)
- drop redundant TODO comment about PCH IRQ flags on BXT
- check HAS_PCH_SPLIT instead of IS_BROXTON when handling PCH specific
IRQ events in gen8_irq_handler()
- check HAS_PCH_SPLIT before calling the function instead of a
corresponding early return within the called function for
ibx_irq_reset(), ibx_irq_pre_postinstall(), ibx_irq_postinstall()
v3: (jani)
- in ironlake_irq_postinstall() and ironlake_irq_reset() HAS_PCH_SPLIT
is always true, so drop the check for it
Reviewed-by: Satheeshakrishna Msatheeshakrishn...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Shashank Sharma ppashank.sha...@intel.com (v1)
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b06364f..b0cd7a9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2297,7 +2297,8 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
DRM_ERROR(The master control interrupt lied (DE
PIPE)!\n);
}
- if (!HAS_PCH_NOP(dev) master_ctl GEN8_DE_PCH_IRQ) {
+ if (HAS_PCH_SPLIT(dev) !HAS_PCH_NOP(dev)
+ master_ctl GEN8_DE_PCH_IRQ) {
/*
* FIXME(BDW): Assume for now that the new interrupt handling
* scheme also closed the SDE interrupt handling race we've seen
@@ -3133,7 +3134,8 @@ static void gen8_irq_reset(struct drm_device *dev)
GEN5_IRQ_RESET(GEN8_DE_MISC_);
GEN5_IRQ_RESET(GEN8_PCU_);
- ibx_irq_reset(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_reset(dev);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3545,12 +3547,14 @@ static int gen8_irq_postinstall(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- ibx_irq_pre_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_pre_postinstall(dev);
gen8_gt_irq_postinstall(dev_priv);
gen8_de_irq_postinstall(dev_priv);
- ibx_irq_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_postinstall(dev);
I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
POSTING_READ(GEN8_MASTER_IRQ);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_mmap_gtt: add huge BO test
On 04/13/2015 03:22 PM, Joonas Lahtinen wrote:
On ma, 2015-04-13 at 12:32 +0100, Tvrtko Ursulin wrote:
Hi,
On 04/07/2015 01:23 PM, Joonas Lahtinen wrote:
Add a straightforward test that allocates a BO that is bigger than
(by 1 page currently) the mappable aperture, tests mmap access to it
by CPU directly and through GTT in sequence.
Currently it is expected for the GTT access to gracefully fail as
all objects are attempted to get pinned to GTT completely for mmap
access. Once the partial view support is merged to kernel, the test
should pass for all parts.
Signed-off-by: Joonas Lahtinen joonas.lahti...@linux.intel.com
---
tests/gem_mmap_gtt.c | 68
1 file changed, 68 insertions(+)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index 55c66a2..bf3627c 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -41,6 +41,10 @@
#include drmtest.h
#include igt_debugfs.h
+#ifndef PAGE_SIZE
+#define PAGE_SIZE 4096
+#endif
+
static int OBJECT_SIZE = 16*1024*1024;
static void set_domain(int fd, uint32_t handle)
@@ -258,6 +262,68 @@ test_write_gtt(int fd)
}
static void
+test_huge_bo(int fd)
+{
+ uint32_t bo;
+ char *ptr_cpu;
+ char *ptr_gtt;
+ char *cpu_pattern;
+ uint64_t mappable_aperture_pages = gem_mappable_aperture_size() /
+ PAGE_SIZE;
+ uint64_t huge_object_size = (mappable_aperture_pages + 1) * PAGE_SIZE;
+ uint64_t last_offset = huge_object_size - PAGE_SIZE;
+
+ cpu_pattern = malloc(PAGE_SIZE);
+ igt_assert(cpu_pattern);
I'd be tempted to use 4k from the stack for simplicity.
It's not a nice thing to allocate two 4k objects from stack. So lets
just not.
Why not? It's not kernel stack but 8MiB default for a simple IGT... and
changelog to v3 says otherwise. ;) But ok..
+ memset(cpu_pattern, 0xaa, PAGE_SIZE);
+
+ bo = gem_create(fd, huge_object_size);
+
+ ptr_cpu = gem_mmap__cpu(fd, bo, 0, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_cpu) {
+ igt_warn(Not enough free memory for huge BO test!\n);
+ goto out;
Free address space or free memory?
It is not really relevant to the test which condition caused it. But
yeah, correcting the error message into 'Can not allocate memory'.
Is it really memory and not address space?
Also, igt_require so test skips in that case?
Ack using igt_require_f. Because the condition is bit unclear without
the text.
+ }
+
+ /* Test read/write to first/last page with CPU. */
+ memcpy(ptr_cpu, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu, cpu_pattern, PAGE_SIZE) == 0);
+
+ memcpy(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE);
+ igt_assert(memcmp(ptr_cpu + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ igt_assert(memcmp(ptr_cpu, ptr_cpu + last_offset, PAGE_SIZE) == 0);
+
+ munmap(ptr_cpu, huge_object_size);
+ ptr_cpu = NULL;
+
+ ptr_gtt = gem_mmap__gtt(fd, bo, huge_object_size,
+ PROT_READ | PROT_WRITE);
+ if (!ptr_gtt) {
+ igt_debug(Huge BO GTT mapping not supported!\n);
+ goto out;
igt_require as above? Hm, although ideally test would be able to detect
the feature (once it is added to the kernel) so it could assert here.
I think the point is somewhat that UMP should not need to know/care
about it. Before introducing the feature the above will always fail, and
after introducing it, it will always succeed (unless there is less than
1MB aperture space available). So I think it should be good as it is.
I suppose there isn't really a way to be smarter in this case.
+ }
+
+ /* Test read/write to first/last page through GTT. */
+ set_domain(fd, bo);
+
+ igt_assert(memcmp(ptr_gtt, cpu_pattern, PAGE_SIZE) == 0);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt + last_offset, cpu_pattern, PAGE_SIZE) == 0);
+
+ memset(ptr_gtt + last_offset, 0x55, PAGE_SIZE);
+ igt_assert(memcmp(ptr_gtt, ptr_gtt + last_offset, PAGE_SIZE) == 0);
Comments for the above would be nice just to explain what is being
tested and how.
The level of commenting was higher already than I noticed to be in other
tests, but I'll add a few more.
Thanks, it's best to lead by example!
Won't the last test has side effects with partial views since it is
accessing beginning and end of the object? Would it be better to memcmp
against a pattern on stack or in heap like cpu_pattern?
Will you support two simultaneous partial views or the last memcmp will
cause a lot of partial view creation/destruction?
Yes, there will be multiple partial views, but it's all internal to the
kernel implementation. Above access pattern should be
[Intel-gfx] [PATCH 04/13] drm/i915: Add EDID read in intel_dp_check_link_status() for Link CTS 4.2.2.1
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in the
Displayport Link CTS Core 1.2 rev1.1. This test requires an EDID read for
all HPD plug events. To reduce the amount of code, this EDID read is also
used for Link CTS tests 4.2.2.3, 4.2.2.4, 4.2.2.5 and 4.2.2.6. Actual
support for these tests is implemented in later patches in this series.
V2:
- Fixed compilation error introduced during rework
Signed-off-by: Todd Previte tprev...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 23184b0..75df3e2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3890,6 +3890,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
+ struct drm_connector *connector = intel_dp-attached_connector-base;
+ struct i2c_adapter *adapter = intel_dp-aux.ddc;
+ struct edid *edid_read = NULL;
u8 sink_irq_vector;
u8 link_status[DP_LINK_STATUS_SIZE];
@@ -3906,6 +3909,14 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
+ /* Displayport Link CTS Core 1.2 rev1.1 EDID testing
+* 4.2.2.1 - EDID read required for all HPD events
+ */
+edid_read = drm_get_edid(connector, adapter);
+if (!edid_read) {
+DRM_DEBUG_DRIVER(Invalid EDID detected\n);
+}
+
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11
intel_dp_get_sink_irq(intel_dp, sink_irq_vector)) {
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 66/70] drm/i915: Remove obj-pin_mappable
On Mon, Apr 13, 2015 at 12:35:53PM +0100, Tvrtko Ursulin wrote:
On 04/07/2015 05:28 PM, Chris Wilson wrote:
The obj-pin_mappable flag only exists for debug purposes and is a
hindrance that is mistreated with rotated GGTT views. For debug
purposes, it suffices to mark objects with pin_display as being of note.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +++---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem.c | 6 +-
3 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2e851c6a310c..6508eec3cf60 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -166,9 +166,9 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
}
if (obj-stolen)
seq_printf(m, (stolen: %08llx), obj-stolen-start);
-if (obj-pin_mappable || obj-fault_mappable) {
+if (obj-pin_display || obj-fault_mappable) {
char s[3], *t = s;
-if (obj-pin_mappable)
+if (obj-pin_display)
*t++ = 'p';
if (obj-fault_mappable)
*t++ = 'f';
@@ -464,7 +464,7 @@ static int i915_gem_object_info(struct seq_file *m,
void* data)
size += i915_gem_obj_ggtt_size(obj);
++count;
}
-if (obj-pin_mappable) {
+if (obj-pin_display) {
mappable_size += i915_gem_obj_ggtt_size(obj);
++mappable_count;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index eeffefa10612..2c72ee0214b5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1980,7 +1980,6 @@ struct drm_i915_gem_object {
* accurate mappable working set.
*/
unsigned int fault_mappable:1;
-unsigned int pin_mappable:1;
unsigned int pin_display:1;
/*
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index bd60bb552920..3d4463930267 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4445,9 +4445,6 @@ i915_gem_object_do_pin(struct drm_i915_gem_object *obj,
WARN_ON(flags PIN_MAPPABLE !obj-map_and_fenceable);
vma-pin_count++;
-if (flags PIN_MAPPABLE)
-obj-pin_mappable |= true;
-
return 0;
}
@@ -4487,8 +4484,7 @@ i915_gem_object_ggtt_unpin_view(struct
drm_i915_gem_object *obj,
WARN_ON(vma-pin_count == 0);
WARN_ON(!i915_gem_obj_ggtt_bound_view(obj, view));
-if (--vma-pin_count == 0 view-type == I915_GGTT_VIEW_NORMAL)
-obj-pin_mappable = false;
+--vma-pin_count;
}
bool
Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
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 v7 24/49] drm/i915/bxt: DDI Hotplug interrupt setup
On Fri, 10 Apr 2015, Imre Deak imre.d...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
In BXT, DDI hotplug control has been moved to CPU from PCH.
This patch adds a new IRQ setup function for BXT which:
1. Checks which HPD ports are requested to be enabled by encoders.
2. Enables those ports in the hot plug control register.
3. Un-masks these port interrupts in the IMR register.
4. Enables these port interrupts in the IER register.
V3: Kept the default HPD filter count to default (500 us) as per
satheesh's comment
v4: Remove unused HPD filter defines (Damien)
v5: warn if trying to setup HPD on port A (imre)
v6: fix order of definitions for register bitfields (Daniel)
v7: (jani)
- define the size of the hpd_bxt array explicitly for bound checking
- use for_each_intel_encoder instead of open coding it
- fix format/order of definitions for BXT_HOTPLUG_CTL reg bitfields
Reviewed-by: Satheeshakrishna M satheeshakrishn...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Shashank Sharma shashank.sha...@intel.com (v4)
Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 47
-
drivers/gpu/drm/i915/i915_reg.h | 23 +++-
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 46bcbff..631484d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,6 +88,12 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = { /* i915
and valleyview are th
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
+/* BXT hpd list */
+static const u32 hpd_bxt[HPD_NUM_PINS] = {
+ [HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
+ [HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
+};
+
/* IIR can theoretically queue up two events. Be paranoid. */
#define GEN8_IRQ_RESET_NDX(type, which) do { \
I915_WRITE(GEN8_##type##_IMR(which), 0x); \
@@ -3159,6 +3165,42 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
}
+static void bxt_hpd_irq_setup(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_encoder *intel_encoder;
+ u32 hotplug_port = 0;
+ u32 hotplug_ctrl;
+
+ /* Now, enable HPD */
+ for_each_intel_encoder(dev, intel_encoder) {
+ if (dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark
+ == HPD_ENABLED)
+ hotplug_port |= hpd_bxt[intel_encoder-hpd_pin];
+ }
+
+ /* Mask all HPD control bits */
+ hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL) ~BXT_HOTPLUG_CTL_MASK;
+
+ /* Enable requested port in hotplug control */
+ /* TODO: implement (short) HPD support on port A */
+ WARN_ON_ONCE(hotplug_port BXT_DE_PORT_HP_DDIA);
+ if (hotplug_port BXT_DE_PORT_HP_DDIB)
+ hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
+ if (hotplug_port BXT_DE_PORT_HP_DDIC)
+ hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
+ I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
+
+ /* Unmask DDI hotplug in IMR */
+ hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR) ~hotplug_port;
+ I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
+
+ /* Enable DDI hotplug in IER */
+ hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
+ I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
+ POSTING_READ(GEN8_DE_PORT_IER);
+}
+
static void ibx_irq_postinstall(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4279,7 +4321,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev-driver-irq_uninstall = gen8_irq_uninstall;
dev-driver-enable_vblank = gen8_enable_vblank;
dev-driver-disable_vblank = gen8_disable_vblank;
- dev_priv-display.hpd_irq_setup = ibx_hpd_irq_setup;
+ if (HAS_PCH_SPLIT(dev))
+ dev_priv-display.hpd_irq_setup = ibx_hpd_irq_setup;
+ else
+ dev_priv-display.hpd_irq_setup = bxt_hpd_irq_setup;
} else if (HAS_PCH_SPLIT(dev)) {
dev-driver-irq_handler = ironlake_irq_handler;
dev-driver-irq_preinstall = ironlake_irq_reset;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7d51aec..670a9d4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5256,10 +5256,16 @@ enum skl_disp_power_wells {
#define GEN8_DE_PORT_IMR 0x4
#define GEN8_DE_PORT_IIR 0x8
#define GEN8_DE_PORT_IER 0xc
-#define GEN8_PORT_DP_A_HOTPLUG (1 3)
#define GEN9_AUX_CHANNEL_D (1 27)
#define GEN9_AUX_CHANNEL_C (1 26)
#define GEN9_AUX_CHANNEL_B (1 25)
+#define
Re: [Intel-gfx] [PATCH] drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover
On Mon, Apr 13, 2015 at 02:37:41PM +0100, Tvrtko Ursulin wrote:
On 04/13/2015 01:09 PM, Jani Nikula wrote:
On Thu, 26 Mar 2015, Tvrtko Ursulin tvrtko.ursu...@linux.intel.com wrote:
On 03/26/2015 01:30 PM, Ville Syrjälä wrote:
On Thu, Mar 26, 2015 at 12:39:40PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must be held without that lock.
This is a simplified version of the identically named patch by Chris
Wilson.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89166
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cb50854..0788507 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14020,11 +14020,21 @@ void intel_modeset_gem_init(struct drm_device
*dev)
c-primary-fb,
c-primary-state,
NULL)) {
+/*
+ * We must drop struct_mutex when calling
+ * drm_framebuffer_unreference and it is safe
to do so
+ * because it is not needed at this point
anyway.
+ * At this stage the driver is still
single-threaded and
+ * we are taking it only to silence a warning in
+ * intel_pin_and_fence_fb_obj.
+ */
+mutex_unlock(dev-struct_mutex);
DRM_ERROR(failed to pin boot fb on pipe %d\n,
to_intel_crtc(c)-pipe);
drm_framebuffer_unreference(c-primary-fb);
c-primary-fb = NULL;
update_state_fb(c-primary);
+mutex_lock(dev-struct_mutex);
}
}
mutex_unlock(dev-struct_mutex);
Just grab the mutex around the pin_and_fence inside the loop. It doesn't
protect anything else.
Well the comment says so, but this way it only grabs and releases it
once if there are multiple active crtcs and nothing fails. So I was
hoping the comment was enough to explain the reality, even though the
other option would be more obvious code strictly speaking.
Tvrtko Ville, can you reach a solution on this one? Or is there a
new patch that I may have missed?
It was pretty much bike shedding - I am happy with this version since it
has a single lock/unlock on the normal path, compared to one pair per
active display with what Ville wanted.
Either approach makes for unclear code so needs a big comment anyway.
Which leaves only the exact placement of mutex_lock/unlock under discussion.
I don't see what's unclear about locking only around the call that needs
the lock.
If we want to spend this much time on this that is.
Regards,
Tvrtko
--
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 v2 26/49] drm/i915/bxt: Add BXT support in gen8_irq functions
On ma, 2015-04-13 at 16:51 +0300, Jani Nikula wrote:
On Fri, 10 Apr 2015, Imre Deak imre.d...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch adds conditional checks in gen8_irq functions
to support BXT. Most of the checks just look for PCH split
availability, and block the call to PCH interrupt functions if
not available.
v2: (jani)
- drop redundant TODO comment about PCH IRQ flags on BXT
- check HAS_PCH_SPLIT instead of IS_BROXTON when handling PCH specific
IRQ events in gen8_irq_handler()
- check HAS_PCH_SPLIT before calling the function instead of a
corresponding early return within the called function for
ibx_irq_reset(), ibx_irq_pre_postinstall(), ibx_irq_postinstall()
Reviewed-by: Satheeshakrishna Msatheeshakrishn...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Shashank Sharma ppashank.sha...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index b06364f..a185f44 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2297,7 +2297,8 @@ static irqreturn_t gen8_irq_handler(int irq, void
*arg)
DRM_ERROR(The master control interrupt lied (DE
PIPE)!\n);
}
- if (!HAS_PCH_NOP(dev) master_ctl GEN8_DE_PCH_IRQ) {
+ if (HAS_PCH_SPLIT(dev) !HAS_PCH_NOP(dev)
+ master_ctl GEN8_DE_PCH_IRQ) {
/*
* FIXME(BDW): Assume for now that the new interrupt handling
* scheme also closed the SDE interrupt handling race we've seen
@@ -3073,7 +3074,8 @@ static void ironlake_irq_reset(struct drm_device *dev)
gen5_gt_irq_reset(dev);
- ibx_irq_reset(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_reset(dev);
}
static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
@@ -3133,7 +3135,8 @@ static void gen8_irq_reset(struct drm_device *dev)
GEN5_IRQ_RESET(GEN8_DE_MISC_);
GEN5_IRQ_RESET(GEN8_PCU_);
- ibx_irq_reset(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_reset(dev);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3323,13 +3326,15 @@ static int ironlake_irq_postinstall(struct
drm_device *dev)
I915_WRITE(HWSTAM, 0xeffe);
- ibx_irq_pre_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_pre_postinstall(dev);
GEN5_IRQ_INIT(DE, dev_priv-irq_mask, display_mask | extra_mask);
gen5_gt_irq_postinstall(dev);
- ibx_irq_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_postinstall(dev);
/me scratches head, we shouldn't ever call ironlake_irq_postinstall on
bxt, should we? Did I miss something?
Nope, I just added the check blindly to all call sites. But here
HAS_PCH_SPLIT happens to be true of course, so yea it's not needed.
With this hunk dropped, I think the patch looks good.
BR,
Jani.
if (IS_IRONLAKE_M(dev)) {
/* Enable PCU event interrupts
@@ -3545,12 +3550,14 @@ static int gen8_irq_postinstall(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- ibx_irq_pre_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_pre_postinstall(dev);
gen8_gt_irq_postinstall(dev_priv);
gen8_de_irq_postinstall(dev_priv);
- ibx_irq_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_postinstall(dev);
I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
POSTING_READ(GEN8_MASTER_IRQ);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/chv: Remove DPIO force latency causing interpair skew issue
On Mon, Apr 13, 2015 at 02:04:27PM +0300, Jani Nikula wrote: On Sat, 11 Apr 2015, shuang...@intel.com wrote: Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6167 -Summary- Platform Delta drm-intel-nightly Series Applied PNV 276/276 276/276 ILK 302/302 302/302 SNB -31 313/313 282/313 The patch does not touch SNB code paths, what gives? In the past few days dp link retraining sprung up all over the place in PRTS results. I dunno what exactly is happening. I think He Shuang is still investigating. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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 v2 4/8] drm/i915/skl: Assert the requirements to enter or exit DC5.
On pe, 2015-04-10 at 20:41 +0530, Animesh Manna wrote:
From: Suketu Shah suketu.j.s...@intel.com
Warn if the conditions to enter or exit DC5 are not satisfied such
as support for runtime PM, state of power well, CSR loading etc.
v2: Removed camelcase in functions and variables.
v3: Do some minimal check to assert if CSR program is not loaded.
v4:
1] Used an appropriate function lookup_power_well() to identify power well,
instead of using a magic number which can change in future.
2] Split the conditions further in assert_can_enable_DC5() and added more
checks.
3] Removed all WARNs from assert_can_disable_DC5 as they were unnecessary and
added two
new ones.
4] Changed variable names as updated in earlier patches.
v5:
1] Change lookup_power_well function to take an int power well id.
2] Define a new intel_display_power_well_is_enabled helper function to check
whether a
particular power well is enabled.
3] Use CSR-related mutex in assert_csr_loaded function.
v6: Remove use of dc5_enabled variable as it's no longer needed.
v7:
1] Rebase to latest.
2] Move all DC5-related functions from intel_display.c to intel_runtime_pm.c.
v8: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
v9: Modified below chnages based on review comments from Imre.
- Moved intel_display_power_well_is_enabled() to intel_runtime_pm.c.
- Removed mutex lock from assert_csr_loaded(). (Animesh)
Issue: VIZ-2819
Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Suketu Shah suketu.j.s...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 61
++---
1 file changed, 56 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 0750191..db25eb7 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -31,6 +31,7 @@
#include i915_drv.h
#include intel_drv.h
+#include intel_csr.h
/**
* DOC: runtime pm
@@ -64,6 +65,9 @@
i--)\
if ((power_well)-domains (domain_mask))
+bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
+ int power_well_id);
+
/*
* We should only use the power well if we explicitly asked the hardware to
* enable it, so check if it's enabled and also check if we've requested it
to
@@ -335,12 +339,48 @@ static void gen9_set_dc_state_debugmask_memory_up(
}
}
-static void gen9_enable_dc5(struct drm_i915_private *dev_priv)
+static void assert_csr_loaded(struct drm_i915_private *dev_priv)
+{
+ WARN(!dev_priv-csr.states, CSR is not loaded.\n);
This is now the wrong condition, should be something like
intel_csr_state(dev_priv) != FW_LOADED.
+ WARN(!I915_READ(CSR_PROGRAM_BASE),
+ CSR program storage start is NULL\n);
+ WARN(!I915_READ(CSR_SSP_BASE), CSR SSP Base Not fine\n);
+ WARN(!I915_READ(CSR_HTP_SKL), CSR HTP Not fine\n);
+}
+
+static void assert_can_enable_dc5(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv-dev;
+ bool pg2_enabled = intel_display_power_well_is_enabled(dev_priv,
+ SKL_DISP_PW_2);
+
+ WARN(!IS_SKYLAKE(dev), Platform doesn't support DC5.\n);
+ WARN(!HAS_RUNTIME_PM(dev), Runtime PM not enabled.\n);
+ WARN(pg2_enabled, PG2 not disabled to enable DC5.\n);
+
+ WARN((I915_READ(DC_STATE_EN) DC_STATE_EN_UPTO_DC5),
+ DC5 already programmed to be enabled.\n);
+ WARN(dev_priv-pm.suspended,
+ DC5 cannot be enabled, if platform is runtime-suspended.\n);
+
+ assert_csr_loaded(dev_priv);
+}
+
+static void assert_can_disable_dc5(struct drm_i915_private *dev_priv)
+{
+ bool pg2_enabled = intel_display_power_well_is_enabled(dev_priv,
+ SKL_DISP_PW_2);
+
+ WARN(!pg2_enabled, PG2 not enabled to disable DC5.\n);
+ WARN(dev_priv-pm.suspended,
+ Disabling of DC5 while platform is runtime-suspended should
never happen.\n);
+}
+
+static void gen9_enable_dc5(struct drm_i915_private *dev_priv)
+{
uint32_t val;
- WARN_ON(!IS_GEN9(dev));
+ assert_can_enable_dc5(dev_priv);
DRM_DEBUG_KMS(Enabling DC5\n);
@@ -355,10 +395,9 @@ static void gen9_enable_dc5(struct drm_i915_private
*dev_priv)
static void gen9_disable_dc5(struct drm_i915_private *dev_priv)
{
- struct drm_device *dev = dev_priv-dev;
uint32_t val;
- WARN_ON(!IS_GEN9(dev));
+ assert_can_disable_dc5(dev_priv);
DRM_DEBUG_KMS(Disabling DC5\n);
@@ -1324,7 +1363,7 @@ static struct i915_power_well
Re: [Intel-gfx] [PATCH] lib: Implement gem_sync() using WAIT
On Mon, Apr 13, 2015 at 12:01:34PM +0100, Chris Wilson wrote:
When synchronising to rendering, we only want to wait for it to complete
and avoid the cache-domain side-effects of SET_DOMAIN if possible. This
has the advantage of speeding up a few tests (and thereby making the
actual test more explicit in terms of kernel operations). Of course some
tests may be reliant on the side-effects...
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Yeah makes tons of sense. I looked a bit through existing tests and didn't
spot any existing bad usage of gem_sync.
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
---
lib/ioctl_wrappers.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index dec45f1..000d394 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -371,12 +371,22 @@ void gem_set_domain(int fd, uint32_t handle,
* @fd: open i915 drm file descriptor
* @handle: gem buffer object handle
*
- * This is a wrapper around gem_set_domain() which simply blocks for any
- * outstanding rendering to complete.
+ * This functions waits for outstanding rendering to complete.
*/
void gem_sync(int fd, uint32_t handle)
{
- gem_set_domain(fd, handle, I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
+ struct drm_i915_gem_wait wait;
+
+ memset(wait, 0, sizeof(wait));
+ wait.bo_handle = handle;
+ wait.timeout_ns =-1;
+ if (drmIoctl(fd, DRM_IOCTL_I915_GEM_WAIT, wait) == 0) {
+ errno = 0;
+ return;
+ }
+
+ gem_set_domain(fd, handle,
+I915_GEM_DOMAIN_GTT, I915_GEM_DOMAIN_GTT);
}
uint32_t __gem_create(int fd, int size)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
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 v3 1/8] drm/i915/skl: Add support to load SKL CSR firmware
On ma, 2015-04-13 at 18:37 +0530, Animesh Manna wrote: On 04/13/2015 04:33 PM, Imre Deak wrote: On ma, 2015-04-13 at 15:54 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com Display Context Save and Restore support is needed for various SKL Display C states like DC5, DC6. This implementation is added based on first version of DMC CSR program that we received from h/w team. Here we are using request_firmware based design. Finally this firmware should end up in linux-firmware tree. For SKL platform its mandatory to ensure that we load this csr program before enabling DC states like DC5/DC6. As CSR program gets reset on various conditions, we should ensure to load it during boot and in future change to be added to load this system resume sequence too. v1: Initial relese as RFC patch v2: Design change as per Daniel, Damien and Shobit's review comments request firmware method followed. v3: Some optimization and functional changes. Pulled register defines into drivers/gpu/drm/i915/i915_reg.h Used kmemdup to allocate and duplicate firmware content. Ensured to free allocated buffer. v4: Modified as per review comments from Satheesh and Daniel Removed temporary buffer. Optimized number of writes by replacing I915_WRITE with I915_WRITE64. v5: Modified as per review comemnts from Damien. - Changed name for functions and firmware. - Introduced HAS_CSR. - Reverted back previous change and used csr_buf with u8 size. - Using cpu_to_be64 for endianness change. Modified as per review comments from Imre. - Modified registers and macro names to be a bit closer to bspec terminology and the existing register naming in the driver. - Early return for non SKL platforms in intel_load_csr_program function. - Added locking around CSR program load function as it may be called concurrently during system/runtime resume. - Releasing the fw before loading the program for consistency - Handled error path during f/w load. v6: Modified as per review comments from Imre. - Corrected out_freecsr sequence. v7: Modified as per review comments from Imre. Fail loading fw if fw-size%8!=0. v8: Rebase to latest. v9: Rebase on top of -nightly (Damien) v10: Enabled support for dmc firmware ver 1.0. According to ver 1.0 in a single binary package all the firmware's that are required for different stepping's of the product will be stored. The package contains the css header, followed by the package header and the actual dmc firmwares. Package header contains the firmware/stepping mapping table and the corresponding firmware offsets to the individual binaries, within the package. Each individual program binary contains the header and the payload sections whose size is specified in the header section. This changes are done to extract the specific firmaware from the package. (Animesh) v11: Modified as per review comemnts from Imre. - Added code comment from bpec for header structure elements. - Added __packed to avoid structure padding. - Added helper functions for stepping and substepping info. - Added code comment for CSR_MAX_FW_SIZE. - Disabled BXT firmware loading, will be enabled with dmc 1.0 support. - Changed skl_stepping_info based on bspec, earlier used from config DB. - Removed duplicate call of cpu_to_be* from intel_csr_load_program function. - Used cpu_to_be32 instead of cpu_to_be64 as firmware binary in dword aligned. - Added sanity check for header length. - Added sanity check for mmio address got from firmware binary. - kmalloc done separately for dmc header and dmc firmware. (Animesh) v12: Modified as per review comemnts from Imre. - Corrected the typo error in skl stepping info structure. - Added out-of-bound access for skl_stepping_info. - Sanity check for mmio address modified. - Sanity check added for stepping and substeppig. - Modified the intel_dmc_info structure, cache only the required header info. (Animesh) v13: clarify firmware load error message. The reason for a firmware loading failure can be obscure if the driver is built-in. Provide an explanation to the user about the likely reason for the failure and how to resolve it. (Imre) v14: Suggested by Jani. - fix s/I915/CONFIG_DRM_I915/ typo - add fw_path to the firmware object instead of using a static ptr (Jani) v15: 1) Changed the firmware name as dmc_gen9.bin, everytime for a new firmware version a symbolic link with same name will help not to build kernel again. 2) Changes done as per review comments from Imre. - Error check removed for intel_csr_ucode_init. - Moved csr-specific data structure to intel_csr.h and optimization done on structure definition. - fw-data used directly for parsing the header info memory allocation only done separately for payload. (Animesh) v16: No need for out_regs label in
Re: [Intel-gfx] [PATCH 2/8] drm/i915/skl: Implement enable/disable for Display C5 sttate.
On Thu, Apr 02, 2015 at 06:58:22PM +0300, Imre Deak wrote: On ke, 2015-04-01 at 16:22 +0530, Animesh Manna wrote: From: A.Sunil Kamath sunil.kam...@intel.com This patch just implements the basic enable and disable functions of DC5 state which is needed for both SKL and BXT. Reviewed-by: Imre Deak imre.d...@intel.com For the record, this patch generates compilation warnings when applied on its own: drivers/gpu/drm/i915/intel_runtime_pm.c:368:13: warning: ‘gen9_enable_dc5’ defined but not used [-Wunused-function] static void gen9_enable_dc5(struct drm_i915_private *dev_priv) ^ drivers/gpu/drm/i915/intel_runtime_pm.c:386:13: warning: ‘gen9_disable_dc5’ defined but not used [-Wunused-function] static void gen9_disable_dc5(struct drm_i915_private *dev_priv) ^ Generally speaking, in a series, each step should compile without warning and result in a working driver (for bisectability). -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 34/49] drm/i915/bxt: Restrict PORT_CLK_SEL programming below gen9
On Sun, Apr 12, 2015 at 03:52:12PM +0530, sagar.a.kam...@intel.com wrote: For patch at http://lists.freedesktop.org/archives/intel-gfx/2015-March/062169.html Reviewed-by: Sagar Kamble sagar.a.kamble at intel.com Usually reviews are done as a reply to the patch, but maybe you didn't receive the earlier mail? - I915_WRITE(PORT_CLK_SEL(port), - intel_crtc-config-ddi_pll_sel); + /* FIXME: add support for SKL */ + if (!INTEL_INFO(dev)-gen 9) + I915_WRITE(PORT_CLK_SEL(port), + intel_crtc-config-ddi_pll_sel); This '!' looks fishy to me. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add missing MacBook Pro models with dual channel LVDS
[dunno what the distribution was originally; adding intel-gfx]
On Sun, 12 Apr 2015, Lukas Wunner lu...@wunner.de wrote:
All 17 models with i915 graphics had a resolution of 1920x1200,
necessitating dual channel LVDS. The 15 pre-retina models had
up to 1680x1050, hence used dual channel LVDS as well.
I think this begs the question, why don't we assume dual link lvds when
we know the native mode of the panel necessitates it?
Reference for MacBookPro9,1 (also tested by myself):
http://ubuntuforums.org/showthread.php?t=2224567
Reference for MacBookPro8,2 / 8,3:
https://wiki.archlinux.org/index.php/MacBookPro8,1/8,2/8,3_(2011)
Reference for MacBookPro6,2:
https://bbs.archlinux.org/viewtopic.php?id=185770
I really wish the references were more conclusive on the dual channel
parameter, or that we had Tested-by on the patch with the module
parameter dropped. We don't have much chances for testing this, but if
the patch is valid, it's definitely cc: stable material.
As is, applying this gives me an uneasy feeling. :(
BR,
Jani.
Signed-off-by: Lukas Wunner lu...@wunner.de
---
drivers/gpu/drm/i915/intel_lvds.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 071b96d..ee1000f 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -812,12 +812,44 @@ static int intel_dual_link_lvds_callback(const struct
dmi_system_id *id)
static const struct dmi_system_id intel_dual_link_lvds[] = {
{
.callback = intel_dual_link_lvds_callback,
- .ident = Apple MacBook Pro (Core i5/i7 Series),
+ .ident = Apple MacBook Pro 17\ (2010),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro6,1),
+ },
+ },
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 15\ (2010),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro6,2),
+ },
+ },
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 15\ (2011),
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro8,2),
},
},
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 17\ (2011),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro8,3),
+ },
+ },
+ {
+ .callback = intel_dual_link_lvds_callback,
+ .ident = Apple MacBook Pro 15\ (2012),
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Apple Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookPro9,1),
+ },
+ },
{ } /* terminating entry */
};
--
1.8.5.2 (Apple Git-48)
___
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] vt: Don't check KD_GRAPHICS when binding/unbinding
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6185 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -4 276/276 272/276 ILK 301/301 301/301 SNB -21 316/316 295/316 IVB -1 328/328 327/328 BYT 285/285 285/285 HSW 394/394 394/394 BDW 321/321 321/321 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt@gen3_render_linear_blits FAIL(4)PASS(6) FAIL(2) PNV igt@gen3_render_mixed_blits FAIL(5)PASS(5) FAIL(1)PASS(1) PNV igt@gen3_render_tiledx_blits FAIL(5)PASS(6) FAIL(1)PASS(1) PNV igt@gen3_render_tiledy_blits FAIL(4)PASS(6) FAIL(1)PASS(1) SNB igt@kms_flip@modeset-vs-vblank-race DMESG_WARN(1)PASS(5) DMESG_WARN(1)PASS(1) (dmesg patch applied)drm:intel_dp_start_link_train[i915]]*ERROR*too_many_voltage_retries,give_up@too many voltage .* give up drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_train_DP,aborting@failed to train .* aborting drm:intel_dp_start_link_train[i915]]*ERROR*failed_to_enable_link_training@failed to enable link training drm:intel_dp_complete_link_train[i915]]*ERROR*failed_to_start_channel_equalization@failed to start channel equalization SNB igt@kms_mmio_vs_cs_flip@setcrtc_vs_cs_flip NSPT(1)PASS(1) NSPT(2) SNB igt@kms_mmio_vs_cs_flip@setplane_vs_cs_flip NSPT(1)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@primary-rotation NSPT(1)PASS(1) NSPT(2) SNB igt@kms_rotation_crc@sprite-rotation NSPT(1)PASS(3) NSPT(2) SNB igt@pm_rpm@cursor NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@cursor-dpms NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-mode-unset-non-lpsp NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@dpms-non-lpsp NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@drm-resources-equal NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@fences NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@fences-dpms NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-execbuf NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-cpu NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-mmap-gtt NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@gem-pread NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@i2c NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@modeset-non-lpsp-stress-no-wait NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@pci-d3-state NSPT(1)PASS(1) NSPT(2) SNB igt@pm_rpm@rte NSPT(1)PASS(1) NSPT(2) IVB igt@gem_pwrite_pread@uncached-copy-performance DMESG_WARN(1)PASS(6) DMESG_WARN(2) (dmesg patch applied)drm:i915_hangcheck_elapsed[i915]]*ERROR*Hangcheck_timer_elapsed...blitter_ring_idle@Hangcheck timer elapsed... blitter ring idle Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 26/49] drm/i915/bxt: Add BXT support in gen8_irq functions
On Fri, 10 Apr 2015, Imre Deak imre.d...@intel.com wrote:
From: Shashank Sharma shashank.sha...@intel.com
This patch adds conditional checks in gen8_irq functions
to support BXT. Most of the checks just look for PCH split
availability, and block the call to PCH interrupt functions if
not available.
v2: (jani)
- drop redundant TODO comment about PCH IRQ flags on BXT
- check HAS_PCH_SPLIT instead of IS_BROXTON when handling PCH specific
IRQ events in gen8_irq_handler()
- check HAS_PCH_SPLIT before calling the function instead of a
corresponding early return within the called function for
ibx_irq_reset(), ibx_irq_pre_postinstall(), ibx_irq_postinstall()
Reviewed-by: Satheeshakrishna Msatheeshakrishn...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Shashank Sharma ppashank.sha...@intel.com
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b06364f..a185f44 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2297,7 +2297,8 @@ static irqreturn_t gen8_irq_handler(int irq, void *arg)
DRM_ERROR(The master control interrupt lied (DE
PIPE)!\n);
}
- if (!HAS_PCH_NOP(dev) master_ctl GEN8_DE_PCH_IRQ) {
+ if (HAS_PCH_SPLIT(dev) !HAS_PCH_NOP(dev)
+ master_ctl GEN8_DE_PCH_IRQ) {
/*
* FIXME(BDW): Assume for now that the new interrupt handling
* scheme also closed the SDE interrupt handling race we've seen
@@ -3073,7 +3074,8 @@ static void ironlake_irq_reset(struct drm_device *dev)
gen5_gt_irq_reset(dev);
- ibx_irq_reset(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_reset(dev);
}
static void vlv_display_irq_reset(struct drm_i915_private *dev_priv)
@@ -3133,7 +3135,8 @@ static void gen8_irq_reset(struct drm_device *dev)
GEN5_IRQ_RESET(GEN8_DE_MISC_);
GEN5_IRQ_RESET(GEN8_PCU_);
- ibx_irq_reset(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_reset(dev);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3323,13 +3326,15 @@ static int ironlake_irq_postinstall(struct drm_device
*dev)
I915_WRITE(HWSTAM, 0xeffe);
- ibx_irq_pre_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_pre_postinstall(dev);
GEN5_IRQ_INIT(DE, dev_priv-irq_mask, display_mask | extra_mask);
gen5_gt_irq_postinstall(dev);
- ibx_irq_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_postinstall(dev);
/me scratches head, we shouldn't ever call ironlake_irq_postinstall on
bxt, should we? Did I miss something?
With this hunk dropped, I think the patch looks good.
BR,
Jani.
if (IS_IRONLAKE_M(dev)) {
/* Enable PCU event interrupts
@@ -3545,12 +3550,14 @@ static int gen8_irq_postinstall(struct drm_device
*dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- ibx_irq_pre_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_pre_postinstall(dev);
gen8_gt_irq_postinstall(dev_priv);
gen8_de_irq_postinstall(dev_priv);
- ibx_irq_postinstall(dev);
+ if (HAS_PCH_SPLIT(dev))
+ ibx_irq_postinstall(dev);
I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
POSTING_READ(GEN8_MASTER_IRQ);
--
1.9.1
--
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 17/70] drm/i915: Optimistically spin for the request completion
On Mon, Apr 13, 2015 at 12:34:19PM +0100, Tvrtko Ursulin wrote: Hi, On 04/07/2015 04:20 PM, Chris Wilson wrote: This provides a nice boost to mesa in swap bound scenarios (as mesa throttles itself to the previous frame and given the scenario that will complete shortly). It will also provide a good boost to systems running with semaphores disabled and so frequently waiting on the GPU as it switches rings. In the most favourable of microbenchmarks, this can increase performance by around 15% - though in practice improvements will be marginal and rarely noticeable. v2: Account for user timeouts v3: Limit the spinning to a single jiffie (~1us) at most. On an otherwise idle system, there is no scheduler contention and so without a limit we would spin until the GPU is ready. v4: Drop forcewake - the lazy coherent access doesn't require it, and we have no reason to believe that the forcewake itself improves seqno coherency - it only adds delay. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Daniel Vetter daniel.vet...@ffwll.ch Cc: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com Cc: Eero Tamminen eero.t.tammi...@intel.com Cc: Rantala, Valtteri valtteri.rant...@intel.com I already said that I already gave my r-b for this one. :) Reviewed-by: Tvrtko Ursulin tvrtko.ursu...@intel.com Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation 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] drm/i915: Fix screen flickering on X
On Sat, 2015-04-11 at 19:17 -0300, Ismael Luceno wrote:
A bisect showed that commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68
introduced the issue.
The issue starts as soon as X takes control of the screen, even if just
a plain X doing nothing, so based on the code touched by the commit I
thought it had to be related to the so called hardware cursor. I
confirmed it when hiding the cursor made the flickering go away.
The aforementioned commit removed some suspicious code, and the
Programmer's Reference Manual confirmed my suspicion:
Incorrectly programmed watermark values can result in screen corruption.
The watermarks should be calculated and programmed when any of the
watermark calculation inputs change. This includes planes enabling or
disabling, plane source format or size changing, etc.
So I'm re-adding the few lines that update the watermarks after a cursor
size change.
Signed-off-by: Ismael Luceno ism...@iodev.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f75173c..e23f062 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12258,6 +12258,7 @@ intel_commit_cursor_plane(struct drm_plane *plane,
struct intel_crtc *intel_crtc;
struct intel_plane *intel_plane = to_intel_plane(plane);
struct drm_i915_gem_object *obj = intel_fb_obj(state-base.fb);
+ unsigned old_width;
uint32_t addr;
crtc = crtc ? crtc : plane-crtc;
@@ -12282,11 +12283,15 @@ intel_commit_cursor_plane(struct drm_plane *plane,
intel_crtc-cursor_addr = addr;
intel_crtc-cursor_bo = obj;
update:
+ old_width = intel_crtc-cursor_width;
intel_crtc-cursor_width = state-base.crtc_w;
intel_crtc-cursor_height = state-base.crtc_h;
- if (intel_crtc-active)
+ if (intel_crtc-active) {
+ if (old_width != intel_crtc-cursor_width)
+ intel_update_watermarks(crtc);
intel_crtc_update_cursor(crtc, state-visible);
+ }
We can't call intel_update_watermarks() from here because we commit
under vblank evasion (with interrupts disabled) and some parts of that
function might sleep. That's why that call to it was moved to
intel_begin_crtc_commit(). The check for change in width was moved to
intel_check_cursor_plane() (where the intel_crtc-atomic.update_wm flag
is set).
So the question here is why that logic is not working. Could you check
if update_wm is being set and intel_update_watermarks() called from
intel_begin_crtc_commit()?
Thanks,
Ander
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/8] drm/i915/skl: Add DC6 Trigger sequence.
On pe, 2015-04-10 at 20:41 +0530, Animesh Manna wrote:
From: Suketu Shah suketu.j.s...@intel.com
Add triggers for DC6 as per details provided in skl_enable_dc6
and skl_disable_dc6 implementations.
Also Call POSTING_READ for every write to a register to ensure
it is written to immediately
v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in
previous patches.
v2:
1] Remove check for backlight disabled as it should be the case by that time.
2] Mark DC5 as disabled when enabling DC6.
3] Return from DC5-disabling function early if DC5 is already be disabled
which can happen
due to DC6-enabling earlier.
3] Ensure CSR firmware is loaded after resume from DC6 as corresponding
memory contents won't
be retained after runtime-suspend.
4] Ensure that CSR isn't identified as loaded before CSR-loading program is
called during
runtime-resume.
v3: Rebase to latest
Modified as per review comments from Imre and after discussion with Art:
1] DC6 should be preferably enabled when PG2 is disabled by SW as the check
for PG1 being
disabled is taken of by HW to enter DC6, and disabled when PG2 is enabled
respectively.
This helps save more power, especially in the case when display is
disabled but GT is
enabled. Accordingly, replacing DC5 trigger sequence with DC6 for SKL.
2] DC6 could be enabled from intel_runtime_suspend() function, if DC5 is
already enabled.
3] Move CSR-load-status setting code from intel_runtime_suspend function to a
new function.
v4:
1] Enable/disable DC6 only when toggling the power-well using a newly defined
macro ENABLE_DC6.
v5:
1] Load CSR on system resume too as firmware may be lost on system suspend
preventing
enabling DC5, DC6.
2] DDI buffers shouldn't be programmed during driver-load/resume as it's
already done
during modeset initialization then and also that the encoder list is still
uninitialized by
then. Therefore, call intel_prepare_ddi function right after disabling DC6
but outside
skl_disable_dc6 function and not during driver-load/resume.
v6:
1] Rebase to latest.
2] Move SKL_ENABLE_DC6 macro definition from intel_display.c to
intel_runtime_pm.c.
v7:
1) Refactored the code for removing the warning got from checkpatch.
2) After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
v8:
- Reverted the changes done in v7.
- Removed the condition check in skl_prepare_resune(). (Animesh)
Issue: VIZ-2819
Signed-off-by: A.Sunil Kamath sunil.kam...@intel.com
Signed-off-by: Suketu Shah suketu.j.s...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Animesh Manna animesh.ma...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c | 30 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 40
++---
2 files changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index acd0e2b..7a1123c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -594,6 +594,8 @@ static void intel_suspend_encoders(struct
drm_i915_private *dev_priv)
static int intel_suspend_complete(struct drm_i915_private *dev_priv);
static int vlv_resume_prepare(struct drm_i915_private *dev_priv,
bool rpm_resume);
+static int skl_resume_prepare(struct drm_i915_private *dev_priv);
+
static int i915_drm_suspend(struct drm_device *dev)
{
@@ -808,6 +810,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
hsw_disable_pc8(dev_priv);
+ else if (IS_SKYLAKE(dev_priv))
+ ret = skl_resume_prepare(dev_priv);
intel_uncore_sanitize(dev);
intel_power_domains_init_hw(dev_priv);
@@ -1022,6 +1026,19 @@ static int i915_pm_resume(struct device *dev)
return i915_drm_resume(drm_dev);
}
+static int skl_suspend_complete(struct drm_i915_private *dev_priv)
+{
+ /* Enabling DC6 is not a hard requirement to enter runtime D3 */
+
+ /*
+ * This is to ensure that CSR isn't identified as loaded before
+ * CSR-loading program is called during runtime-resume.
+ */
+ intel_csr_load_status_set(dev_priv, false);
This sets the wrong state now, should be something like
intel_csr_state_set(dev_priv, FW_UNINITIALIZED);
+
+ return 0;
+}
+
static int hsw_suspend_complete(struct drm_i915_private *dev_priv)
{
hsw_enable_pc8(dev_priv);
@@ -1029,6 +1046,15 @@ static int hsw_suspend_complete(struct
drm_i915_private *dev_priv)
return 0;
}
+static int skl_resume_prepare(struct drm_i915_private *dev_priv)
+{
+ struct drm_device *dev = dev_priv-dev;
+
+ intel_csr_load_program(dev);
+
+ return 0;
+}
+
/*
* Save all Gunit registers that may be lost after a D3 and a subsequent
*
