Re: [Intel-gfx] FW: Release Notes for Beignet Version 0.1
Hi, Again not really important, we use LLVM and TGSI backends in the radeon drivers now. The gallium drivers currently use GPU specific LLVM IRs produced from specific LLVM backends, but that isn't strictly necessary just leads to better optimising opportunities. Because you now have a whole bunch of code that is useless to anyone else. Distro want to ship this sort of thing, we don't want 5 Mesa like implementations for OpenCL, we want one we can actually distribute and manage, and maybe in 5 years support. The point is at the current stage, we don't see the necessary of introduce all those complexity and dependencies. Considering we can share very few code with other part of Mesa(expect some GPU related define in header files). We want to keep this project tiny and self-contained at this point, focus on make OpenCL really fast and useful on IVB+ GPU. We can merge or hook the backend into gallium when there are other mature gallium based OpenCL implementations. That should not be a lot of task, consider the common code are very few. Some other questions: a) have you got an ivybridge LLVM backend? are you going to upstream this, I heard it isn't even written in LLVM machine description format. No, we convert llvm IR to Gen IR then to IVB assembly. There are many choices when implement an execute model of IVB. E.g 8 way or 16 way, SOA mode or AOS mode. We choose 16 way AOS mode in the driver. I don't know if it make sense to upstream only this particular combination. b) have you looked at pocl, libclc etc? Maybe you guys want to run on CPU as well at GPU at some point, in which case maybe again looking around before jumping into implementing stuff might help. We do have looked at libclc. Again, I don't see the necessary to introduce the complexity at this point Almost all the functions in libclc maps to 1 instructions on IVB. We do not see the necessary of introducing a library to wrap those. c) does this use the open source ICD at least? No, we will check that. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: shorten debugfs output simple attributes
On Fri, Apr 12, 2013 at 11:00:20AM -0700, Kees Cook wrote: On Fri, Apr 12, 2013 at 2:10 AM, Mika Kuoppala mika.kuopp...@linux.intel.com wrote: commit 647416f9eefe7699754b01b9fc82758fde83248c Author: Kees Cook keesc...@chromium.org Date: Sun Mar 10 14:10:06 2013 -0700 drm/i915: use simple attribute in debugfs routines made i915_next_seqno debugfs entry to crop it's output if returned value was large enough. Using simple_attr will limit the output to 24 bytes. Fix is to strip out preamples on all simple attributes that have one. v2: Fix all simple attributes (Daniel Vetter) Cc: Kees Cook keesc...@chromium.org Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com Acked-by: Kees Cook keesc...@chromium.org Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Scale ring, rather than ia, frequency on Haswell
On Fri, Apr 12, 2013 at 07:10:13PM +0100, Chris Wilson wrote: Haswell introduces a separate frequency domain for the ring (uncore). So where we used to increase the CPU (IA) clock with GPU busyness, we now need to scale the ring frequency directly instead. As the ring limits our memory bandwidth, it is vital for performance that when the GPU is busy, we increase the frequency of the ring to increase the available memory bandwidth. v2: Fix the algorithm to actually use the scaled gpu frequency for the ring. v3: s/max_ring_freq/min_ring_freq/ as that is what it is Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Cc: Jesse Barnes jbar...@virtuousgeek.org Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FW: Release Notes for Beignet Version 0.1
-Original Message- From: intel-gfx-bounces+zhigang.gong=linux.intel@lists.freedesktop.org [mailto:intel-gfx-bounces+zhigang.gong=linux.intel.com@lists.freedesktop. org] On Behalf Of Zou, Nanhai Sent: Tuesday, April 16, 2013 2:47 PM To: Dave Airlie Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] FW: Release Notes for Beignet Version 0.1 Hi, Again not really important, we use LLVM and TGSI backends in the radeon drivers now. The gallium drivers currently use GPU specific LLVM IRs produced from specific LLVM backends, but that isn't strictly necessary just leads to better optimising opportunities. Because you now have a whole bunch of code that is useless to anyone else. Distro want to ship this sort of thing, we don't want 5 Mesa like implementations for OpenCL, we want one we can actually distribute and manage, and maybe in 5 years support. The point is at the current stage, we don't see the necessary of introduce all those complexity and dependencies. Considering we can share very few code with other part of Mesa(expect some GPU related define in header files). We want to keep this project tiny and self-contained at this point, focus on make OpenCL really fast and useful on IVB+ GPU. We can merge or hook the backend into gallium when there are other mature gallium based OpenCL implementations. That should not be a lot of task, consider the common code are very few. Some other questions: a) have you got an ivybridge LLVM backend? are you going to upstream this, I heard it isn't even written in LLVM machine description format. No, we convert llvm IR to Gen IR then to IVB assembly. There are many choices when implement an execute model of IVB. E.g 8 way or 16 way, SOA mode or AOS mode. We choose 16 way AOS mode in the driver. I don't know if it make sense to upstream only this particular combination. b) have you looked at pocl, libclc etc? Maybe you guys want to run on CPU as well at GPU at some point, in which case maybe again looking around before jumping into implementing stuff might help. We do have looked at libclc. Again, I don't see the necessary to introduce the complexity at this point Almost all the functions in libclc maps to 1 instructions on IVB. We do not see the necessary of introducing a library to wrap those. c) does this use the open source ICD at least? No, we will check that. [Gong, Zhigang] As I know, Simon implemented ICD for Beignet and it may need some time to rebase to the latest beignet code base. If you are interested, this is the link http://psi5.com/~geier/beignet.git. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: VLV doesn't have LLC
On Mon, Apr 15, 2013 at 09:48:03PM -0700, Ben Widawsky wrote: Caused by me with v2 of commit 219f4fdbed5570f1d2e8da0af1c298dd3622060e Author: Ben Widawsky b...@bwidawsk.net Date: Fri Mar 15 11:17:54 2013 -0700 drm/i915: Introduce GEN7_FEATURES for device info I don't have a VLV to test it with, Jesse, Ken, can one of you test? Cc: Jesse Barnes jbar...@virtuousgeek.org Cc: Kenneth Graunke kenn...@whitecape.org Signed-off-by: Ben Widawsky b...@bwidawsk.net Humble apologies for missing it earlier, Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable FBC at Haswell.
On Mon, Apr 15, 2013 at 08:56:28PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
v2: Fixes from Ville.
* Fix Plane. FBC is tied to primary plane A in HSW
* Fix DPFC initial write to avoid let trash on the register.
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 46
-
3 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0cfc778..88fd6fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -291,6 +291,7 @@ static const struct intel_device_info
intel_haswell_m_info = {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = {/* aka */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e91fbb..cb8e213 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -849,6 +849,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE 0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN (128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT (115)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27f94cd..f3b35c4 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,45 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long stall_watermark = 200;
+
+ /* FBC is tied to primary plane A in HSW */
+ if (intel_crtc-plane != PLANE_A) {
+ dev_priv-no_fbc_reason = FBC_BAD_PLANE;
+ return;
+ }
Already checked in intel_update_fbc()
Otherwise looks fine.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines
On Mon, Apr 15, 2013 at 09:45:00PM +0100, Chris Wilson wrote: On Fri, Apr 12, 2013 at 06:16:53PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not have CRT, so just check for !IS_ULT. This problem happened on a real machine and resulted in a very ugly dmesg. Cc: sta...@vger.kernel.org Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com This doesn't apply to dinq. The approach I'd favour is to have a intel_info.has_crt similar to the other feature flags. I'm ok with piling checks on top here for now, I guess we should reconsider once the next hw platforms shows up around the corner ... All patches merged to dinq, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/7] drm/i915: Add HPD IRQ storm detection (v4)
Hi Jani, On Thu, Apr 11, 2013 at 12:32:29PM +0300, Jani Nikula wrote: Hi Egbert - Up front, I haven't been following this series or read any of the previous review comments. Please bear with me, and feel free to direct me to earlier comments if I'm in contradiction. Sorry for the late reply - last week I was quite busy with other stuff, this week i'm a bit preoccupied. On Tue, 09 Apr 2013, Egbert Eich e...@freedesktop.org wrote: From: Egbert Eich e...@suse.de Add a hotplug IRQ storm detection (triggered when a hotplug interrupt fires more than 5 times / sec). Okay, this is theoretical, but a display port sink could do more than that many hpd irq requests when connected. Which leads me to wonder in general if the storm detection should be different for hot plug vs. unplug and hpd irq events. Agreed. During my tests I did not see any issues with the statistics I've implemented: 5/sec was an ad-hoc choice and I wanted to start with something simple. I've tested it and it seemed to work, so I didn't bother to look into this more deeply, however if you feel 5 events / sec are too few to really do a good distinction, we could easily increase this number. There have been two situations where I have seen 'interrupt storms': 1. On G35: some boxes of the affected systems do not show this issue at all while others see a very high load but are still usable. In my recollection there were in the order of some 100 interrupts/sec on these machines. Then there were systems which would 'stall' in the worker during boot due to high load. At one point the NMI watchdog kicked in and stopped this mess. There the interrupts happened at an order of magnitude if 10k! 2. A laptop with a Sandybridge chipset where the system load went high at certain stages of charging levels - when the power supply was connected. I would assume the frequency there also was around some 100 / sec. Thus if we increase the threshold frequency to some 10 / sec we would still cover all those cases. Some other issue I've seen is 'bouncing' during manual plugging I've been contemplating how to address this. There are two things to look at: 1. multiple hotplug events due to not getting a perfect connection at first 2. EDID readout happening to early when the EDID lines are not yet fully and 'permanently' connected. It might well be, that a fix for these issues might actually also adress the issues you are pointing out. I have not seen them on Intel hardware - but this may be due to the fact that the hardware I saw it on was a separate gfx card which did not have the usual mounting bracket and thus the entire setup was a bit fragile and not really suitable for hot-plugging. However I believe that these things might happen everywere for people not quite used to plugging monitors too much. Have you observed difference between hot plug/unplug? There seems to be a difference between monitor connected/not connected: On DVI (G35) one doesn't distinguish between plug/unplug: when the hotplug line on the connector changes state an interrupt is sent. On this system storms only happened when a monitor was conneted - since the state of the HPD pin is signalled thru different frequencies on a line across SDVO (in my recollection it was 10 vs. 20 MHz) I believe that due to cross talk the higher(?) frequency could not always reliably be measured. I did not have access to the laptop system and the customer was not patient enough to help me to debug this further with me. Generally I think we would still adress the 'strom condition' if we raised the threshold to 20 or 30 /sec. What do you think? Has this been a problem on PCH split platforms, i.e. since ilk/gen5? I've also observed this on Sandybridge - which would be past GEN5, wouldn't it? I will address some of the other issues mentioned in a new patch. Thanks a lot for looking at it! Cheers, Egbert. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: drm_rect and clipping for intel sprite planes
I'm re-sending this whole plane clipping series, as it has been a quite while since the last time I posted it. Laurent went through patch 1 and I made the requested changes, and I also fixed a minor issue in patch 3 that I spotted myself. The other patches are unchanged and looking for volunteers to review them... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/4] drm: Add struct drm_rect and assorted utility functions
From: Ville Syrjälä ville.syrj...@linux.intel.com
struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.
v2: Moved the region stuff into its own file, made the smaller funcs
static inline, used 64bit maths in the scaled clipping function to
avoid overflows (instead it will saturate to INT_MIN or INT_MAX).
v3: Renamed drm_region to drm_rect, drm_region_clip to
drm_rect_intersect, and drm_region_subsample to drm_rect_downscale.
v4: Renamed some function parameters, improve kernel-doc comments a bit,
and actually generate documentation for drm_rect.[ch].
v5: s/RETUTRNS/RETURNS/
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
Documentation/DocBook/drm.tmpl | 2 +
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_rect.c | 96 ++
include/drm/drm_rect.h | 132 +
4 files changed, 232 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_rect.c
create mode 100644 include/drm/drm_rect.h
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f9df3b8..7c7af25 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1653,6 +1653,8 @@ void intel_crt_init(struct drm_device *dev)
sect2
titleKMS API Functions/title
!Edrivers/gpu/drm/drm_crtc.c
+!Edrivers/gpu/drm/drm_rect.c
+!Finclude/drm/drm_rect.h
/sect2
/sect1
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 6a42115..3374aac 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,8 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o
drm_cache.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
- drm_trace_points.o drm_global.o drm_prime.o
+ drm_trace_points.o drm_global.o drm_prime.o \
+ drm_rect.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
new file mode 100644
index 000..22091ec
--- /dev/null
+++ b/drivers/gpu/drm/drm_rect.c
@@ -0,0 +1,96 @@
+/*
+ * Copyright (C) 2011-2013 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+#include linux/errno.h
+#include linux/export.h
+#include linux/kernel.h
+#include drm/drm_rect.h
+
+/**
+ * drm_rect_intersect - intersect two rectangles
+ * @r1: first rectangle
+ * @r2: second rectangle
+ *
+ * Calculate the intersection of rectangles @r1 and @r2.
+ * @r1 will be overwritten with the intersection.
+ *
+ * RETURNS:
+ * %true if rectangle @r1 is still visible after the operation,
+ * %false otherwise.
+ */
+bool drm_rect_intersect(struct drm_rect *r1, const struct drm_rect *r2)
+{
+ r1-x1 = max(r1-x1, r2-x1);
+ r1-y1 = max(r1-y1, r2-y1);
+ r1-x2 = min(r1-x2, r2-x2);
+ r1-y2 = min(r1-y2, r2-y2);
+
+ return drm_rect_visible(r1);
+}
+EXPORT_SYMBOL(drm_rect_intersect);
+
+/**
+ * drm_rect_clip_scaled - perform a scaled clip operation
+ * @src: source window rectangle
+ * @dst: destination window rectangle
+ * @clip: clip rectangle
+ * @hscale: horizontal scaling factor
+ * @vscale: vertical scaling factor
+ *
+ * Clip rectangle @dst by rectangle @clip. Clip rectangle @src by the
+ * same amounts multiplied by @hscale and @vscale.
+ *
+ * RETURNS:
+ * %true if rectangle @dst is still visible after being clipped,
+ * %false otherwise
+ */
+bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst,
+ const struct drm_rect *clip,
+ int hscale, int vscale)
+{
+ int diff;
+
+
[Intel-gfx] [PATCH v3 3/4] drm: Add drm_rect_debug_print()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Add a debug function to print the rectangle in a human readable format.
v2: Renamed drm_region to drm_rect, the function from drm_region_debug
to drm_rect_debug_print(), and use %+d instead of +%d in the format.
v3: Use %d format for width/height in the non fixed point case as well
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/drm_rect.c | 22 ++
include/drm/drm_rect.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index 5dd9411..33d5930 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -24,6 +24,7 @@
#include linux/errno.h
#include linux/export.h
#include linux/kernel.h
+#include drm/drmP.h
#include drm/drm_rect.h
/**
@@ -271,3 +272,24 @@ int drm_rect_calc_vscale_relaxed(struct drm_rect *src,
return vscale;
}
EXPORT_SYMBOL(drm_rect_calc_vscale_relaxed);
+
+/**
+ * drm_rect_debug_print - print the rectangle information
+ * @r: rectangle to print
+ * @fixed_point: rectangle is in 16.16 fixed point format
+ */
+void drm_rect_debug_print(const struct drm_rect *r, bool fixed_point)
+{
+ int w = drm_rect_width(r);
+ int h = drm_rect_height(r);
+
+ if (fixed_point)
+ DRM_DEBUG_KMS(%d.%06ux%d.%06u%+d.%06u%+d.%06u\n,
+ w 16, ((w 0x) * 15625) 10,
+ h 16, ((h 0x) * 15625) 10,
+ r-x1 16, ((r-x1 0x) * 15625) 10,
+ r-y1 16, ((r-y1 0x) * 15625) 10);
+ else
+ DRM_DEBUG_KMS(%dx%d%+d%+d\n, w, h, r-x1, r-y1);
+}
+EXPORT_SYMBOL(drm_rect_debug_print);
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index de24f16..fe767b7 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -140,5 +140,6 @@ int drm_rect_calc_hscale_relaxed(struct drm_rect *src,
int drm_rect_calc_vscale_relaxed(struct drm_rect *src,
struct drm_rect *dst,
int min_vscale, int max_vscale);
+void drm_rect_debug_print(const struct drm_rect *r, bool fixed_point);
#endif
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 4/4] drm/i915: Implement proper clipping for video sprites
From: Ville Syrjälä ville.syrj...@linux.intel.com
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.
The scaling checks are done using the relaxed drm_region functions.
That means that the src/dst regions are reduced in size in order to keep
the scaling factor within the limits.
Also do some additional checking against various hardware limits.
v2: Truncate src coords instead of rounding to avoid increasing src
viewport size, and adapt to changes in drm_calc_{h,v}scale().
v3: Adapt to drm_region-drm_rect rename. Fix misaligned crtc_w for
packed YUV formats when scaling isn't supported.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_sprite.c | 191 +++-
1 file changed, 145 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index c7d25c5..72b2ce4 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -32,6 +32,7 @@
#include drm/drmP.h
#include drm/drm_crtc.h
#include drm/drm_fourcc.h
+#include drm/drm_rect.h
#include intel_drv.h
#include drm/i915_drm.h
#include i915_drv.h
@@ -583,6 +584,20 @@ ilk_get_colorkey(struct drm_plane *plane, struct
drm_intel_sprite_colorkey *key)
key-flags = I915_SET_COLORKEY_NONE;
}
+static bool
+format_is_yuv(uint32_t format)
+{
+ switch (format) {
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_VYUY:
+ case DRM_FORMAT_YVYU:
+ return true;
+ default:
+ return false;
+ }
+}
+
static int
intel_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
struct drm_framebuffer *fb, int crtc_x, int crtc_y,
@@ -600,9 +615,28 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
enum transcoder cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv,
pipe);
int ret = 0;
- int x = src_x 16, y = src_y 16;
int primary_w = crtc-mode.hdisplay, primary_h = crtc-mode.vdisplay;
bool disable_primary = false;
+ bool visible;
+ int hscale, vscale;
+ int max_scale, min_scale;
+ int pixel_size = drm_format_plane_cpp(fb-pixel_format, 0);
+ struct drm_rect src = {
+ .x1 = src_x,
+ .x2 = src_x + src_w,
+ .y1 = src_y,
+ .y2 = src_y + src_h,
+ };
+ struct drm_rect dst = {
+ .x1 = crtc_x,
+ .x2 = crtc_x + crtc_w,
+ .y1 = crtc_y,
+ .y2 = crtc_y + crtc_h,
+ };
+ const struct drm_rect clip = {
+ .x2 = crtc-mode.hdisplay,
+ .y2 = crtc-mode.vdisplay,
+ };
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
@@ -618,19 +652,23 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
intel_plane-src_w = src_w;
intel_plane-src_h = src_h;
- src_w = src_w 16;
- src_h = src_h 16;
-
/* Pipe must be running... */
- if (!(I915_READ(PIPECONF(cpu_transcoder)) PIPECONF_ENABLE))
- return -EINVAL;
-
- if (crtc_x = primary_w || crtc_y = primary_h)
+ if (!(I915_READ(PIPECONF(cpu_transcoder)) PIPECONF_ENABLE)) {
+ DRM_DEBUG_KMS(Pipe disabled\n);
return -EINVAL;
+ }
/* Don't modify another pipe's plane */
- if (intel_plane-pipe != intel_crtc-pipe)
+ if (intel_plane-pipe != intel_crtc-pipe) {
+ DRM_DEBUG_KMS(Wrong plane - crtc mapping\n);
return -EINVAL;
+ }
+
+ /* FIXME check all gen limits */
+ if (fb-width 3 || fb-height 3 || fb-pitches[0] 16384) {
+ DRM_DEBUG_KMS(Unsuitable framebuffer for plane\n);
+ return -EINVAL;
+ }
/* Sprite planes can be linear or x-tiled surfaces */
switch (obj-tiling_mode) {
@@ -638,53 +676,111 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
case I915_TILING_X:
break;
default:
+ DRM_DEBUG_KMS(Unsupported tiling mode\n);
return -EINVAL;
}
/*
-* Clamp the width height into the visible area. Note we don't
-* try to scale the source if part of the visible region is offscreen.
-* The caller must handle that by adjusting source offset and size.
+* FIXME the following code does a bunch of fuzzy adjustments to the
+* coordinates and sizes. We probably need some way to decide whether
+* more strict checking
[Intel-gfx] [PATCH] drm/i915: HSW: allow PCH clock gating for suspend
For the device to enter D3 we should enable PCH clock gating.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c |5 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 18 ++
5 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..e9a82f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,6 +521,8 @@ static int i915_drm_freeze(struct drm_device *dev)
*/
list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
dev_priv-display.crtc_disable(crtc);
+
+ intel_modeset_suspend_hw(dev);
}
i915_save_state(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5a495a..e549e6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1831,6 +1831,7 @@ static inline void intel_unregister_dsm_handler(void) {
return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
+extern void intel_modeset_suspend_hw(struct drm_device *dev);
extern void intel_modeset_init(struct drm_device *dev);
extern void intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 457a0a0..e9192bf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8984,6 +8984,11 @@ void intel_modeset_init_hw(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
}
+void intel_modeset_suspend_hw(struct drm_device *dev)
+{
+ intel_suspend_hw(dev);
+}
+
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..8b29897 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -652,6 +652,7 @@ extern void assert_pipe(struct drm_i915_private *dev_priv,
enum pipe pipe,
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
extern void intel_init_clock_gating(struct drm_device *dev);
+extern void intel_suspend_hw(struct drm_device *dev);
extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..3567881 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3735,6 +3735,18 @@ static void lpt_init_clock_gating(struct drm_device *dev)
PCH_LP_PARTITION_LEVEL_DISABLE);
}
+static void lpt_allow_clock_gating(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
+
+ val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
+ }
+}
+
static void haswell_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4085,6 +4097,12 @@ void intel_init_clock_gating(struct drm_device *dev)
dev_priv-display.init_clock_gating(dev);
}
+void intel_suspend_hw(struct drm_device *dev)
+{
+ if (IS_HASWELL(dev))
+ lpt_allow_clock_gating(dev);
+}
+
void intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/16] drm/i915: refuse to submit more batchbuffers from guilty context
If context has recently submitted a faulty batchbuffers guilty of
gpu hang and decides to keep submitting more crap, ban it permanently.
v2: Store guilty ban status bool in gpu_error instead of pointers
that might become danling before hang is declared.
Signed-off-by: Mika Kuoppala mika.kuopp...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c|6 +-
drivers/gpu/drm/i915/i915_drv.h|9 +
drivers/gpu/drm/i915/i915_gem.c| 14 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
4 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..ae689b4 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -885,10 +885,14 @@ int i915_reset(struct drm_device *dev)
mutex_lock(dev-struct_mutex);
+ /* i915_gem_reset() will set this */
+ dev_priv-gpu_error.ctx_banned = false;
+
i915_gem_reset(dev);
ret = -ENODEV;
- if (get_seconds() - dev_priv-gpu_error.last_reset 5)
+ if (!dev_priv-gpu_error.ctx_banned
+ get_seconds() - dev_priv-gpu_error.last_reset 5)
DRM_ERROR(GPU hanging too fast, declaring wedged!\n);
else
ret = intel_gpu_reset(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3b393ed..1945224 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -459,6 +459,12 @@ struct i915_ctx_hang_stats {
/* This context had batch active when hang was declared */
unsigned batch_active;
+
+ /* Time when this context was last blamed for a GPU reset */
+ unsigned long batch_active_reset_ts;
+
+ /* This context is banned to submit more work */
+ bool banned;
};
/* This must match up with the value previously used for execbuf2.rsvd1. */
@@ -835,6 +841,9 @@ struct i915_gpu_error {
unsigned long last_reset;
+ /* During reset handling, guilty context found and banned */
+ bool ctx_banned;
+
/**
* State variable and reset counter controlling the reset flow
*
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0e87765..134528a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2147,6 +2147,7 @@ static void i915_set_reset_status(struct
intel_ring_buffer *ring,
struct drm_i915_gem_request *request,
u32 acthd)
{
+ struct drm_i915_private *dev_priv = ring-dev-dev_private;
struct i915_ctx_hang_stats *hs = NULL;
bool inside, guilty;
@@ -2175,10 +2176,19 @@ static void i915_set_reset_status(struct
intel_ring_buffer *ring,
hs = request-file_priv-hang_stats;
if (hs) {
- if (guilty)
+ if (guilty) {
+ if (!hs-banned
+ get_seconds() - hs-batch_active_reset_ts 5) {
+ hs-banned = true;
+ DRM_ERROR(context hanging too fast,
+ declaring banned\n);
+ dev_priv-gpu_error.ctx_banned = true;
+ }
hs-batch_active++;
- else
+ hs-batch_active_reset_ts = get_seconds();
+ } else {
hs-batch_pending++;
+ }
}
}
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index bd1750a..f1b1ea9 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -844,6 +844,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
struct drm_clip_rect *cliprects = NULL;
struct intel_ring_buffer *ring;
struct i915_hw_context *ctx;
+ struct i915_ctx_hang_stats *hs;
u32 ctx_id = i915_execbuffer2_get_context_id(*args);
u32 exec_start, exec_len;
u32 mask, flags;
@@ -1026,6 +1027,18 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
if (ret)
goto err;
+ hs = i915_gem_context_get_hang_stats(dev_priv-ring[RCS],
+file, ctx_id);
+ if (IS_ERR(hs)) {
+ ret = PTR_ERR(hs);
+ goto err;
+ }
+
+ if (hs-banned) {
+ ret = -EIO;
+ goto err;
+ }
+
ctx = i915_switch_context(ring, file, ctx_id);
if (IS_ERR(ctx)) {
ret = PTR_ERR(ctx);
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/7] drm/i915: Add HPD IRQ storm detection (v4)
Hi Jani,
I've rebased and regenerated all the patches now, as there
were some other bikesheds i had not adressed. I've also
included all Reviewed-By:
This should make it easier to integrate the patches.
Some comments below:
On Thu, Apr 11, 2013 at 12:32:29PM +0300, Jani Nikula wrote:
+ struct {
+ unsigned long hpd_last_jiffies;
+ int hpd_cnt;
+ enum {
+ HPD_ENABLED = 0,
+ HPD_DISABLED = 1,
+ HPD_MARK_DISABLED = 2
+ } hpd_mark;
+ } hpd_stats[HPD_NUM_PINS];
With all the hotplug stuff being added, I think it's getting time to
group all the hotplug stuff under a struct.
I will postpone this until I address the issues that I have on my TODO.
int num_pch_pll;
int num_plane;
diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index 4c5bdd0..32b5527 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -582,6 +582,37 @@ static void gen6_queue_rps_work(struct
drm_i915_private *dev_priv,
queue_work(dev_priv-wq, dev_priv-rps.work);
}
+#define HPD_STORM_DETECT_PERIOD 1000
+
+static inline void hotplug_irq_storm_detect(struct drm_device *dev,
+ u32 hotplug_trigger,
+ const u32 *hpd)
I think you should just add the bool return status right here instead of
postponing until the later patch that needs it.
I thought about this and left it as it is: Returning a bool status now
will raise other questions as the logic in this patch doesn't require it.
I'd rather have a bigger patch later which will however clearly explains
the reason for the change to the function.
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ unsigned long irqflags;
+ int i;
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+
+ for (i = 1; i HPD_NUM_PINS; i++) {
+ if ((hpd[i] hotplug_trigger)
+ dev_priv-hpd_stats[i].hpd_mark == HPD_ENABLED) {
Bikeshed: You might get a nicer layout below by negating that if and
adding continue.
Fixed.
+ if (!time_in_range(jiffies,
dev_priv-hpd_stats[i].hpd_last_jiffies,
+
dev_priv-hpd_stats[i].hpd_last_jiffies
+ +
msecs_to_jiffies(HPD_STORM_DETECT_PERIOD))) {
+ dev_priv-hpd_stats[i].hpd_last_jiffies =
jiffies;
+ dev_priv-hpd_stats[i].hpd_cnt = 0;
+ } else if (dev_priv-hpd_stats[i].hpd_cnt 5) {
+ dev_priv-hpd_stats[i].hpd_mark =
HPD_MARK_DISABLED;
+ DRM_DEBUG_KMS(HPD interrupt storm detected on
PIN %d\n, i);
Extra space before PIN.
Fixed.
+ } else
+ dev_priv-hpd_stats[i].hpd_cnt++;
If one branch requires braces, then all do.
Fixed.
Cheers,
Egbert.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: HSW: allow PCH clock gating for suspend
On Tue, Apr 16, 2013 at 02:25:16PM +0300, Imre Deak wrote:
For the device to enter D3 we should enable PCH clock gating.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c |5 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 18 ++
5 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..e9a82f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,6 +521,8 @@ static int i915_drm_freeze(struct drm_device *dev)
*/
list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
dev_priv-display.crtc_disable(crtc);
+
+ intel_modeset_suspend_hw(dev);
}
i915_save_state(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b5a495a..e549e6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1831,6 +1831,7 @@ static inline void intel_unregister_dsm_handler(void) {
return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
+extern void intel_modeset_suspend_hw(struct drm_device *dev);
extern void intel_modeset_init(struct drm_device *dev);
extern void intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 457a0a0..e9192bf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8984,6 +8984,11 @@ void intel_modeset_init_hw(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
}
+void intel_modeset_suspend_hw(struct drm_device *dev)
+{
+ intel_suspend_hw(dev);
+}
+
Why this extra level of indirection?
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..8b29897 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -652,6 +652,7 @@ extern void assert_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe,
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
extern void intel_init_clock_gating(struct drm_device *dev);
+extern void intel_suspend_hw(struct drm_device *dev);
extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..3567881 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3735,6 +3735,18 @@ static void lpt_init_clock_gating(struct drm_device
*dev)
PCH_LP_PARTITION_LEVEL_DISABLE);
}
+static void lpt_allow_clock_gating(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
+
+ val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
+ }
So who sets it back when we resume?
+}
+
static void haswell_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4085,6 +4097,12 @@ void intel_init_clock_gating(struct drm_device *dev)
dev_priv-display.init_clock_gating(dev);
}
+void intel_suspend_hw(struct drm_device *dev)
+{
+ if (IS_HASWELL(dev))
+ lpt_allow_clock_gating(dev);
Do you need the HSW check? Isn't the LPT LP check enough?
+}
+
void intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.7.10.4
___
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
[Intel-gfx] [PATCH 1/7] drm/i915: Add HPD IRQ storm detection (v5)
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise seems to be bad routing of the hotplug line
on the board: cross talk from other signals seems to cause erronous
hotplug interrupts. This has been documented as an erratum for the
the i945GM chipset and thus hotplug support was disabled for this
chipset model but others seem to have this problem, too.
We have seen this issue on a G35 motherboard for example:
Even different motherboards of the same model seem to behave
differently: while some only see only around 10-100 interrupts/s
others seem to see 5k or more.
We've also observed a dependency on the selected video mode.
Also on certain laptops interrupt noise seems to occur duing
battery charging when the battery is at a certain charge levels.
Thus we add a simple algorithm here that detects an 'interrupt storm'
condition.
v2: Fixed comment.
v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff.
v4: Followed by Jesse Barnes to use a time_..() macro.
v5: Fixed coding style as suggested by Jani Nikula.
Signed-off-by: Egbert Eich e...@suse.de
Acked-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h | 9 ++
drivers/gpu/drm/i915/i915_irq.c | 69 ++---
2 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44fca0b..83fc1a6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -929,6 +929,15 @@ typedef struct drm_i915_private {
struct work_struct hotplug_work;
bool enable_hotplug_processing;
+ struct {
+ unsigned long hpd_last_jiffies;
+ int hpd_cnt;
+ enum {
+ HPD_ENABLED = 0,
+ HPD_DISABLED = 1,
+ HPD_MARK_DISABLED = 2
+ } hpd_mark;
+ } hpd_stats[HPD_NUM_PINS];
int num_pch_pll;
int num_plane;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4c5bdd0..71fc238 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -582,6 +582,40 @@ static void gen6_queue_rps_work(struct drm_i915_private
*dev_priv,
queue_work(dev_priv-wq, dev_priv-rps.work);
}
+#define HPD_STORM_DETECT_PERIOD 1000
+#define HPD_STORM_THRESHOLD 5
+
+static inline void hotplug_irq_storm_detect(struct drm_device *dev,
+ u32 hotplug_trigger,
+ const u32 *hpd)
+{
+ drm_i915_private_t *dev_priv = dev-dev_private;
+ unsigned long irqflags;
+ int i;
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+
+ for (i = 1; i HPD_NUM_PINS; i++) {
+ if (!(hpd[i] hotplug_trigger) ||
+ dev_priv-hpd_stats[i].hpd_mark != HPD_ENABLED)
+ continue;
+
+ if (!time_in_range(jiffies,
dev_priv-hpd_stats[i].hpd_last_jiffies,
+ dev_priv-hpd_stats[i].hpd_last_jiffies
+ +
msecs_to_jiffies(HPD_STORM_DETECT_PERIOD))) {
+ dev_priv-hpd_stats[i].hpd_last_jiffies = jiffies;
+ dev_priv-hpd_stats[i].hpd_cnt = 0;
+ } else if (dev_priv-hpd_stats[i].hpd_cnt
HPD_STORM_THRESHOLD) {
+ dev_priv-hpd_stats[i].hpd_mark = HPD_MARK_DISABLED;
+ DRM_DEBUG_KMS(HPD interrupt storm detected on PIN
%d\n, i);
+ } else {
+ dev_priv-hpd_stats[i].hpd_cnt++;
+ }
+ }
+
+ spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+}
+
static void gmbus_irq_handler(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = (drm_i915_private_t *)
dev-dev_private;
@@ -650,13 +684,15 @@ static irqreturn_t valleyview_irq_handler(int irq, void
*arg)
/* Consume port. Then clear IIR or we'll miss events */
if (iir I915_DISPLAY_PORT_INTERRUPT) {
u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
+ u32 hotplug_trigger = hotplug_status
HOTPLUG_INT_STATUS_I915;
DRM_DEBUG_DRIVER(hotplug event received, stat
0x%08x\n,
hotplug_status);
- if (hotplug_status HOTPLUG_INT_STATUS_I915)
+ if (hotplug_trigger) {
+ hotplug_irq_storm_detect(dev, hotplug_trigger,
hpd_status_i915);
queue_work(dev_priv-wq,
[Intel-gfx] [PATCH 2/7] drm/i915: (re)init HPD interrupt storm statistics
When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 14 ++
drivers/gpu/drm/i915/intel_crt.c | 6 ++
drivers/gpu/drm/i915/intel_dp.c | 1 -
drivers/gpu/drm/i915/intel_drv.h | 4
drivers/gpu/drm/i915/intel_hdmi.c | 1 -
drivers/gpu/drm/i915/intel_sdvo.c | 5 ++---
drivers/gpu/drm/i915/intel_tv.c | 2 +-
7 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 71fc238..bc00532 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -596,6 +596,7 @@ static inline void hotplug_irq_storm_detect(struct
drm_device *dev,
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
for (i = 1; i HPD_NUM_PINS; i++) {
+
if (!(hpd[i] hotplug_trigger) ||
dev_priv-hpd_stats[i].hpd_mark != HPD_ENABLED)
continue;
@@ -3048,7 +3049,20 @@ void intel_irq_init(struct drm_device *dev)
void intel_hpd_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_mode_config *mode_config = dev-mode_config;
+ struct drm_connector *connector;
+ int i;
+ for (i = 1; i HPD_NUM_PINS; i++) {
+ dev_priv-hpd_stats[i].hpd_cnt = 0;
+ dev_priv-hpd_stats[i].hpd_mark = HPD_ENABLED;
+ }
+ list_for_each_entry(connector, mode_config-connector_list, head) {
+ struct intel_connector *intel_connector =
to_intel_connector(connector);
+ connector-polled = intel_connector-polled;
+ if (!connector-polled I915_HAS_HOTPLUG(dev)
intel_connector-encoder-hpd_pin HPD_NONE)
+ connector-polled = DRM_CONNECTOR_POLL_HPD;
+ }
if (dev_priv-display.hpd_irq_setup)
dev_priv-display.hpd_irq_setup(dev);
}
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 1ae2d7f..c063b9f 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -793,10 +793,8 @@ void intel_crt_init(struct drm_device *dev)
drm_sysfs_connector_add(connector);
- if (I915_HAS_HOTPLUG(dev))
- connector-polled = DRM_CONNECTOR_POLL_HPD;
- else
- connector-polled = DRM_CONNECTOR_POLL_CONNECT;
+ if (!I915_HAS_HOTPLUG(dev))
+ intel_connector-polled = DRM_CONNECTOR_POLL_CONNECT;
/*
* Configure the automatic hotplug detection stuff
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 482b5e5..1e9b19a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2786,7 +2786,6 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
drm_connector_init(dev, connector, intel_dp_connector_funcs, type);
drm_connector_helper_add(connector, intel_dp_connector_helper_funcs);
- connector-polled = DRM_CONNECTOR_POLL_HPD;
connector-interlace_allowed = true;
connector-doublescan_allowed = 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..a05fde7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -171,6 +171,10 @@ struct intel_connector {
/* Cached EDID for eDP and LVDS. May hold ERR_PTR for invalid EDID. */
struct edid *edid;
+
+ /* since POLL and HPD connectors may use the same HPD line keep the
native
+ state of connector-polled in case hotplug storm detection changes
it */
+ u8 polled;
};
struct intel_crtc_config {
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee4a8da..8912201 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -998,7 +998,6 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
DRM_MODE_CONNECTOR_HDMIA);
drm_connector_helper_add(connector, intel_hdmi_connector_helper_funcs);
- connector-polled = DRM_CONNECTOR_POLL_HPD;
connector-interlace_allowed = 1;
connector-doublescan_allowed = 0;
diff --git
[Intel-gfx] [PATCH 3/7] drm/i915: Mask out the HPD irq bits before setting them individually.
To disable previously enabled HPD IRQs we need to reset them and
set the enabled ones individually.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc00532..4cf33b3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2121,9 +2121,11 @@ static void ibx_hpd_irq_setup(struct drm_device *dev)
u32 hotplug;
if (HAS_PCH_IBX(dev)) {
+ mask = ~SDE_HOTPLUG_MASK;
list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
mask |= hpd_ibx[intel_encoder-hpd_pin];
} else {
+ mask = ~SDE_HOTPLUG_MASK_CPT;
list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
mask |= hpd_cpt[intel_encoder-hpd_pin];
}
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.
v2: Fixed cleanup typo.
v3: Fixed format issues, clarified a variable name,
changed pr_warn() to DRM_INFO() as suggested by
Jani Nikula jani.nik...@linux.intel.com.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 75 +++--
1 file changed, 58 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4cf33b3..d059c5d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -88,7 +88,8 @@ static const u32 hpd_status_i915[] = { /* i915 and valleyview
are the same */
[HPD_PORT_D] = PORTD_HOTPLUG_INT_STATUS
};
-
+static void ibx_hpd_irq_setup(struct drm_device *dev);
+static void i915_hpd_irq_setup(struct drm_device *dev);
/* For display hotplug interrupt */
static void
@@ -342,7 +343,11 @@ static void i915_hotplug_work_func(struct work_struct
*work)
hotplug_work);
struct drm_device *dev = dev_priv-dev;
struct drm_mode_config *mode_config = dev-mode_config;
- struct intel_encoder *encoder;
+ struct intel_connector *intel_connector;
+ struct intel_encoder *intel_encoder;
+ struct drm_connector *connector;
+ unsigned long irqflags;
+ bool hpd_disabled = false;
/* HPD irq before everything is fully set up. */
if (!dev_priv-enable_hotplug_processing)
@@ -351,9 +356,33 @@ static void i915_hotplug_work_func(struct work_struct
*work)
mutex_lock(mode_config-mutex);
DRM_DEBUG_KMS(running encoder hotplug functions\n);
- list_for_each_entry(encoder, mode_config-encoder_list, base.head)
- if (encoder-hot_plug)
- encoder-hot_plug(encoder);
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ list_for_each_entry(connector, mode_config-connector_list, head) {
+ intel_connector = to_intel_connector(connector);
+ intel_encoder = intel_connector-encoder;
+ if (intel_encoder-hpd_pin HPD_NONE
+ dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark ==
HPD_MARK_DISABLED
+ connector-polled == DRM_CONNECTOR_POLL_HPD) {
+ DRM_INFO(HPD interrupt storm detected on connector %s:
+switching from hotplug detection to
polling\n,
+ drm_get_connector_name(connector));
+ dev_priv-hpd_stats[intel_encoder-hpd_pin].hpd_mark =
HPD_DISABLED;
+ connector-polled = DRM_CONNECTOR_POLL_CONNECT
+ | DRM_CONNECTOR_POLL_DISCONNECT;
+ hpd_disabled = true;
+ }
+ }
+/* if there were no outputs to poll, poll was disabled,
+ * therefore make sure it's enabled when disabling HPD on
+ * some connectors */
+ if (hpd_disabled)
+ drm_kms_helper_poll_enable(dev);
+
+ spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
+ list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
+ if (intel_encoder-hot_plug)
+ intel_encoder-hot_plug(intel_encoder);
mutex_unlock(mode_config-mutex);
@@ -585,13 +614,14 @@ static void gen6_queue_rps_work(struct drm_i915_private
*dev_priv,
#define HPD_STORM_DETECT_PERIOD 1000
#define HPD_STORM_THRESHOLD 5
-static inline void hotplug_irq_storm_detect(struct drm_device *dev,
+static inline bool hotplug_irq_storm_detect(struct drm_device *dev,
u32 hotplug_trigger,
const u32 *hpd)
{
drm_i915_private_t *dev_priv = dev-dev_private;
unsigned long irqflags;
int i;
+ bool ret = false;
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
@@ -609,12 +639,15 @@ static inline void hotplug_irq_storm_detect(struct
drm_device *dev,
} else if (dev_priv-hpd_stats[i].hpd_cnt
HPD_STORM_THRESHOLD) {
dev_priv-hpd_stats[i].hpd_mark = HPD_MARK_DISABLED;
DRM_DEBUG_KMS(HPD interrupt storm detected on PIN
%d\n, i);
+ ret = true;
} else {
dev_priv-hpd_stats[i].hpd_cnt++;
}
}
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
+
+ return ret;
}
static void gmbus_irq_handler(struct drm_device *dev)
@@ -690,7 +723,8 @@ static irqreturn_t
[Intel-gfx] [PATCH 5/7] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.
v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state
tracker.
v3: Clarified loop start value,
Removed superfluous test for Ivybridge and Haswell,
Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)
v4: Fixed two bugs pointed out by Jani Nikula.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 52 -
2 files changed, 52 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 83fc1a6..195b9fe 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -938,6 +938,7 @@ typedef struct drm_i915_private {
HPD_MARK_DISABLED = 2
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
+ struct timer_list hotplug_reenable_timer;
int num_pch_pll;
int num_plane;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d059c5d..ae759ac 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -337,6 +337,8 @@ static int i915_get_vblank_timestamp(struct drm_device
*dev, int pipe,
/*
* Handle hotplug events outside the interrupt handler proper.
*/
+#define I915_REENABLE_HOTPLUG_DELAY (2*60*1000)
+
static void i915_hotplug_work_func(struct work_struct *work)
{
drm_i915_private_t *dev_priv = container_of(work, drm_i915_private_t,
@@ -375,8 +377,11 @@ static void i915_hotplug_work_func(struct work_struct
*work)
/* if there were no outputs to poll, poll was disabled,
* therefore make sure it's enabled when disabling HPD on
* some connectors */
- if (hpd_disabled)
+ if (hpd_disabled) {
drm_kms_helper_poll_enable(dev);
+ mod_timer(dev_priv-hotplug_reenable_timer,
+ jiffies +
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+ }
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
@@ -2356,6 +2361,8 @@ static void valleyview_irq_uninstall(struct drm_device
*dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
@@ -2377,6 +2384,8 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(HWSTAM, 0x);
I915_WRITE(DEIMR, 0x);
@@ -2753,6 +2762,8 @@ static void i915_irq_uninstall(struct drm_device * dev)
drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev-dev_private;
int pipe;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -2997,6 +3008,8 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
+ del_timer_sync(dev_priv-hotplug_reenable_timer);
+
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -3012,6 +3025,41 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
}
+static void i915_reenable_hotplug_timer_func(unsigned long data)
+{
+ drm_i915_private_t *dev_priv = (drm_i915_private_t *)data;
+ struct drm_device *dev = dev_priv-dev;
+ struct drm_mode_config *mode_config = dev-mode_config;
+ unsigned long irqflags;
+ int i;
+
+ spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+ for (i = (HPD_NONE + 1); i HPD_NUM_PINS; i++) {
+ struct drm_connector *connector;
+
+ if (dev_priv-hpd_stats[i].hpd_mark != HPD_DISABLED)
+ continue;
+
+ dev_priv-hpd_stats[i].hpd_mark = HPD_ENABLED;
+
+ list_for_each_entry(connector, mode_config-connector_list,
head) {
+ struct intel_connector *intel_connector =
to_intel_connector(connector);
+
+ if (intel_connector-encoder-hpd_pin == i) {
+ if (connector-polled !=
intel_connector-polled)
+ DRM_DEBUG_DRIVER(Reenabling HPD on
connector %s\n,
+
[Intel-gfx] [PATCH 6/7] drm/i915: Add bit field to record which pins have received HPD events (v3)
This allows to add code which limits 're'-detect() of displays to connectors
that have received an HPD event.
v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking.
v3: Fixed merge conflicts with previous patches, removed some noisy debug
logging as suggested by Jani Nikula.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 195b9fe..c0d9fb9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -938,6 +938,7 @@ typedef struct drm_i915_private {
HPD_MARK_DISABLED = 2
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
+ u32 hpd_event_bits;
struct timer_list hotplug_reenable_timer;
int num_pch_pll;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index ae759ac..e108729 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -350,6 +350,7 @@ static void i915_hotplug_work_func(struct work_struct *work)
struct drm_connector *connector;
unsigned long irqflags;
bool hpd_disabled = false;
+ u32 hpd_event_bits;
/* HPD irq before everything is fully set up. */
if (!dev_priv-enable_hotplug_processing)
@@ -359,6 +360,9 @@ static void i915_hotplug_work_func(struct work_struct *work)
DRM_DEBUG_KMS(running encoder hotplug functions\n);
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
+
+ hpd_event_bits = dev_priv-hpd_event_bits;
+ dev_priv-hpd_event_bits = 0;
list_for_each_entry(connector, mode_config-connector_list, head) {
intel_connector = to_intel_connector(connector);
intel_encoder = intel_connector-encoder;
@@ -373,6 +377,10 @@ static void i915_hotplug_work_func(struct work_struct
*work)
| DRM_CONNECTOR_POLL_DISCONNECT;
hpd_disabled = true;
}
+ if (hpd_event_bits (1 intel_encoder-hpd_pin)) {
+ DRM_DEBUG_KMS(Connector %s (pin %i) received hotplug
event.\n,
+ drm_get_connector_name(connector),
intel_encoder-hpd_pin);
+ }
}
/* if there were no outputs to poll, poll was disabled,
* therefore make sure it's enabled when disabling HPD on
@@ -636,6 +644,8 @@ static inline bool hotplug_irq_storm_detect(struct
drm_device *dev,
dev_priv-hpd_stats[i].hpd_mark != HPD_ENABLED)
continue;
+ dev_priv-hpd_event_bits |= (1 i);
+
if (!time_in_range(jiffies,
dev_priv-hpd_stats[i].hpd_last_jiffies,
dev_priv-hpd_stats[i].hpd_last_jiffies
+
msecs_to_jiffies(HPD_STORM_DETECT_PERIOD))) {
@@ -643,6 +653,7 @@ static inline bool hotplug_irq_storm_detect(struct
drm_device *dev,
dev_priv-hpd_stats[i].hpd_cnt = 0;
} else if (dev_priv-hpd_stats[i].hpd_cnt
HPD_STORM_THRESHOLD) {
dev_priv-hpd_stats[i].hpd_mark = HPD_MARK_DISABLED;
+ dev_priv-hpd_event_bits = ~(1 i);
DRM_DEBUG_KMS(HPD interrupt storm detected on PIN
%d\n, i);
ret = true;
} else {
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/7] drm/i915: Only reprobe display on encoder which has received an HPD event (v2)
Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.
Signed-off-by: Egbert Eich e...@suse.de
Reviewed-by: Jani Nikula jani.nik...@intel.com
v2: Resolved conflicts with changes in previous commits.
Renamed function and and added a WARN_ON() to warn of
intel_hpd_irq_event() from being called without
mode_config.mutex held - suggested by Jani Nikula.
---
drivers/gpu/drm/i915/i915_irq.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index e108729..dd579d7 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -334,6 +334,21 @@ static int i915_get_vblank_timestamp(struct drm_device
*dev, int pipe,
crtc);
}
+static int intel_hpd_irq_event(struct drm_device *dev, struct drm_connector
*connector)
+{
+ enum drm_connector_status old_status;
+
+ WARN_ON(!mutex_is_locked(dev-mode_config.mutex));
+ old_status = connector-status;
+
+ connector-status = connector-funcs-detect(connector, false);
+ DRM_DEBUG_KMS([CONNECTOR:%d:%s] status updated from %d to %d\n,
+ connector-base.id,
+ drm_get_connector_name(connector),
+ old_status, connector-status);
+ return (old_status != connector-status);
+}
+
/*
* Handle hotplug events outside the interrupt handler proper.
*/
@@ -350,6 +365,7 @@ static void i915_hotplug_work_func(struct work_struct *work)
struct drm_connector *connector;
unsigned long irqflags;
bool hpd_disabled = false;
+ bool changed = false;
u32 hpd_event_bits;
/* HPD irq before everything is fully set up. */
@@ -393,14 +409,20 @@ static void i915_hotplug_work_func(struct work_struct
*work)
spin_unlock_irqrestore(dev_priv-irq_lock, irqflags);
- list_for_each_entry(intel_encoder, mode_config-encoder_list,
base.head)
- if (intel_encoder-hot_plug)
- intel_encoder-hot_plug(intel_encoder);
-
+ list_for_each_entry(connector, mode_config-connector_list, head) {
+ intel_connector = to_intel_connector(connector);
+ intel_encoder = intel_connector-encoder;
+ if (hpd_event_bits (1 intel_encoder-hpd_pin)) {
+ if (intel_encoder-hot_plug)
+ intel_encoder-hot_plug(intel_encoder);
+ if (intel_hpd_irq_event(dev, connector))
+ changed = true;
+ }
+ }
mutex_unlock(mode_config-mutex);
- /* Just fire off a uevent and let userspace tell us what to do */
- drm_helper_hpd_irq_event(dev);
+ if (changed)
+ drm_kms_helper_hotplug_event(dev);
}
static void ironlake_handle_rps_change(struct drm_device *dev)
--
1.8.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: HSW: allow PCH clock gating for suspend
On Tue, 2013-04-16 at 14:35 +0300, Ville Syrjälä wrote:
On Tue, Apr 16, 2013 at 02:25:16PM +0300, Imre Deak wrote:
For the device to enter D3 we should enable PCH clock gating.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c |5 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 18 ++
5 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..e9a82f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,6 +521,8 @@ static int i915_drm_freeze(struct drm_device *dev)
*/
list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
dev_priv-display.crtc_disable(crtc);
+
+ intel_modeset_suspend_hw(dev);
}
i915_save_state(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index b5a495a..e549e6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1831,6 +1831,7 @@ static inline void intel_unregister_dsm_handler(void)
{ return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
+extern void intel_modeset_suspend_hw(struct drm_device *dev);
extern void intel_modeset_init(struct drm_device *dev);
extern void intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 457a0a0..e9192bf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8984,6 +8984,11 @@ void intel_modeset_init_hw(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
}
+void intel_modeset_suspend_hw(struct drm_device *dev)
+{
+ intel_suspend_hw(dev);
+}
+
Why this extra level of indirection?
I thought it'd be more symmetric w.r.t.
__i915_drm_thaw-intel_modeset_init_hw().
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..8b29897 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -652,6 +652,7 @@ extern void assert_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe,
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
extern void intel_init_clock_gating(struct drm_device *dev);
+extern void intel_suspend_hw(struct drm_device *dev);
extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..3567881 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3735,6 +3735,18 @@ static void lpt_init_clock_gating(struct drm_device
*dev)
PCH_LP_PARTITION_LEVEL_DISABLE);
}
+static void lpt_allow_clock_gating(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
+
+ val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
+ }
So who sets it back when we resume?
intel_modeset_init_hw()-intel_init_clock_gating()
+}
+
static void haswell_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4085,6 +4097,12 @@ void intel_init_clock_gating(struct drm_device *dev)
dev_priv-display.init_clock_gating(dev);
}
+void intel_suspend_hw(struct drm_device *dev)
+{
+ if (IS_HASWELL(dev))
+ lpt_allow_clock_gating(dev);
Do you need the HSW check? Isn't the LPT LP check enough?
Not sure. According to the spec this is a workaround for HSW/LPT.
+}
+
void intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] FW: Release Notes for Beignet Version 0.1
Zou, Nanhai nanhai.zou at intel.com writes: Hi, We have just released the open source Linux OpenCL project Beignet Version 0.1. If you are interested in this project. Please try it and provide feedback to us. We welcome developers to join this project. It appears that CMakeLists.txt contains the following copyright header: http://cgit.freedesktop.org/beignet/tree/CMakeLists.txt?id=Release_v0.1 # # INTEL CORPORATION PROPRIETARY INFORMATION# # This software is supplied under the terms of a license agreement or # # nondisclosure agreement with Intel Corporation and may not be copied # # or disclosed except in accordance with the terms of that agreement. # # Copyright (C) 2009 Intel Corporation. All Rights Reserved. # # Is that an oversight or is it necessary to sign an agreement with Intel to redistribute the code? Best regards, Chi-Thanh Christopher Nguyen ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Enable FBC at Haswell.
Yeah, this makes sense. Yes, I tested many times here, with 0 at bit 28 I
always got that bug with missing updates, In the way it is it always worked
fine.
On Tue, Apr 16, 2013 at 7:28 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, Apr 15, 2013 at 06:14:46PM -0300, Rodrigo Vivi wrote:
On Wed, Apr 10, 2013 at 5:18 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Apr 09, 2013 at 03:13:10PM -0300, Rodrigo Vivi wrote:
On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrjälä
ville.syrj...@linux.intel.com
wrote:
On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for
HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 44
-
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 0cfc778..88fd6fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -291,6 +291,7 @@ static const struct intel_device_info
intel_haswell_m_info = {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = {/*
aka
*/
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 5e91fbb..cb8e213 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -849,6 +849,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE 0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN (128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT (115)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 27f94cd..94e1c3a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,43 @@ static bool ironlake_fbc_enabled(struct
drm_device
*dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned
long
interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb =
to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int plane = intel_crtc-plane == 0 ? DPFC_CTL_PLANEA :
DPFC_CTL_PLANEB;
+ unsigned long stall_watermark = 200;
+ u32 dpfc_ctl;
+
+ dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
+ dpfc_ctl |= (plane | DPFC_CTL_LIMIT_1X);
Accroding to BSpec FBC is always tied to plane A. Bit 30 is MBZ.
Yeah, you are right. I'm going to add a verification at begining
like:
if (intel_crtc-plane != PLANE_A) {
dev_priv-no_fbc_reason = FBC_BAD_PLANE;
return;
}
Maybe fix up plane C FBC support for IVB while you're poking at the
general direction?
Actually I wasn't trying general directions since I splited it out.
It
was
just bad copy and paste actually.
I'm not a fan of copy pasting code and letting the old code paths rot.
+ dpfc_ctl |= (HSW_DPFC_CTL_FENCE_EN | obj-fence_reg);
The CPU fence field must be written with 0. SNB/IVB could do with
the
same fix.
Where did you get this restriction for HSW?
BSpec.
Are you talking about bit 28 of 43208h DevHSW?
Bits 0:3 of the same register.
I couldn't find this restriction anywhere.
Besides that, setting it to 0 made me experience bugs like missing some
small screen updates. I mean, when it is 0 I missed many when
typing
my login password.
When it is set FBC works fine.
This is what BSpec is telling us to program:
FBC_CTL
28 = ?
0:3 = 0
DPFC_CONTROL_SA
29 = 1
0:4 = fence number
So the FBC_CTL bit 28 is not clear. BSpec doesn't say whether it should
be 0 or 1. Did you try both values for that bit?
--
Ville Syrjälä
Intel OTC
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
[Intel-gfx] [PATCH] drm/i915: Enable FBC at Haswell.
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
v2: Fixes from Ville.
* Fix Plane. FBC is tied to primary plane A in HSW
* Fix DPFC initial write to avoid let trash on the register.
v3: Checking for bad plane on intel_update_fbc() as Chris suggested.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 43 +++--
3 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0cfc778..88fd6fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -291,6 +291,7 @@ static const struct intel_device_info intel_haswell_m_info
= {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = { /* aka */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 5e91fbb..cb8e213 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -849,6 +849,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET 0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN(128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT(115)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 27f94cd..a88ae3c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,39 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long stall_watermark = 200;
+
+ I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
+ (stall_watermark DPFC_RECOMP_STALL_WM_SHIFT) |
+ (interval DPFC_RECOMP_TIMER_COUNT_SHIFT));
+ I915_WRITE(HSW_FBC_RT_BASE,
+ obj-gtt_offset HSW_FBC_RT_BASE_ADDR_SHIFT |
+ ILK_FBC_RT_VALID);
+
+ I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
+ (HSW_DPFC_CTL_FENCE_EN | obj-fence_reg) |
+ HSW_DPFC_CTL_DISABLE_SLB_INIT);
+
+ if (obj-fence_reg != I915_FENCE_REG_NONE) {
+ I915_WRITE(SNB_DPFC_CTL_SA,
+ SNB_CPU_FENCE_ENABLE | obj-fence_reg);
+ I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
+ } else
+ I915_WRITE(SNB_DPFC_CTL_SA, ~SNB_CPU_FENCE_ENABLE);
+
+ sandybridge_blit_fbc_update(dev);
+
+ DRM_DEBUG_KMS(enabled fbc on plane A\n);
+}
+
bool intel_fbc_enabled(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -460,7 +493,8 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_MODE_TOO_LARGE;
goto out_disable;
}
- if ((IS_I915GM(dev) || IS_I945GM(dev)) intel_crtc-plane != 0) {
+ if ((IS_I915GM(dev) || IS_I945GM(dev) || IS_HASWELL(dev))
+intel_crtc-plane != 0) {
DRM_DEBUG_KMS(plane not 0, disabling compression\n);
dev_priv-no_fbc_reason = FBC_BAD_PLANE;
goto out_disable;
@@ -4158,7 +4192,12 @@ void intel_init_pm(struct drm_device *dev)
if (I915_HAS_FBC(dev)) {
if (HAS_PCH_SPLIT(dev)) {
dev_priv-display.fbc_enabled = ironlake_fbc_enabled;
- dev_priv-display.enable_fbc = ironlake_enable_fbc;
+ if (IS_HASWELL(dev))
+ dev_priv-display.enable_fbc =
+ haswell_enable_fbc;
+ else
+ dev_priv-display.enable_fbc =
+ ironlake_enable_fbc;
dev_priv-display.disable_fbc = ironlake_disable_fbc;
} else if (IS_GM45(dev)) {
dev_priv-display.fbc_enabled = g4x_fbc_enabled;
--
1.8.1.4
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Implement proper clipping for video sprites
On Tue, Apr 16, 2013 at 01:47:22PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.
The scaling checks are done using the relaxed drm_region functions.
That means that the src/dst regions are reduced in size in order to keep
the scaling factor within the limits.
Also do some additional checking against various hardware limits.
v2: Truncate src coords instead of rounding to avoid increasing src
viewport size, and adapt to changes in drm_calc_{h,v}scale().
v3: Adapt to drm_region-drm_rect rename. Fix misaligned crtc_w for
packed YUV formats when scaling isn't supported.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Skipping to the end, use of drm_rect looks good.
The one ugly that stood out is:
/*
* If the sprite is completely covering the primary plane,
* we can disable the primary and save power.
*/
- if ((crtc_x == 0) (crtc_y == 0)
+ if (visible
+ (crtc_x == 0) (crtc_y == 0)
(crtc_w == primary_w) (crtc_h == primary_h))
disable_primary = true;
which would be
disable_primary = drm_rect_equals(dst, clip);
BUG_ON(disable_primary !visible);
with a little bit of massaging of crtc/dst.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Enable FBC at Haswell.
On Tue, Apr 16, 2013 at 10:23:17AM -0300, Rodrigo Vivi wrote:
Yeah, this makes sense. Yes, I tested many times here, with 0 at bit 28 I
always got that bug with missing updates, In the way it is it always worked
fine.
So did you actually test with this config?
FBC_CTL
28 = 1
0:3 = 0
DPFC_CONTROL_SA
29 = 1
0:4 = fence number
Oh, and for this test you should make sure fence reg != 0, so that
we can find out for sure whether the FBC_CTL bits 0:3 have some real
effect.
On Tue, Apr 16, 2013 at 7:28 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, Apr 15, 2013 at 06:14:46PM -0300, Rodrigo Vivi wrote:
On Wed, Apr 10, 2013 at 5:18 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Apr 09, 2013 at 03:13:10PM -0300, Rodrigo Vivi wrote:
On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrjälä
ville.syrj...@linux.intel.com
wrote:
On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for
HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 44
-
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 0cfc778..88fd6fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -291,6 +291,7 @@ static const struct intel_device_info
intel_haswell_m_info = {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = {/*
aka
*/
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 5e91fbb..cb8e213 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -849,6 +849,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE 0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN (128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT (115)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 27f94cd..94e1c3a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,43 @@ static bool ironlake_fbc_enabled(struct
drm_device
*dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned
long
interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb =
to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int plane = intel_crtc-plane == 0 ? DPFC_CTL_PLANEA :
DPFC_CTL_PLANEB;
+ unsigned long stall_watermark = 200;
+ u32 dpfc_ctl;
+
+ dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
+ dpfc_ctl |= (plane | DPFC_CTL_LIMIT_1X);
Accroding to BSpec FBC is always tied to plane A. Bit 30 is MBZ.
Yeah, you are right. I'm going to add a verification at begining
like:
if (intel_crtc-plane != PLANE_A) {
dev_priv-no_fbc_reason = FBC_BAD_PLANE;
return;
}
Maybe fix up plane C FBC support for IVB while you're poking at the
general direction?
Actually I wasn't trying general directions since I splited it out.
It
was
just bad copy and paste actually.
I'm not a fan of copy pasting code and letting the old code paths rot.
+ dpfc_ctl |= (HSW_DPFC_CTL_FENCE_EN | obj-fence_reg);
The CPU fence field must be written with 0. SNB/IVB could do with
the
same fix.
Where did you get this restriction for HSW?
BSpec.
Are you talking about bit 28 of 43208h DevHSW?
Bits 0:3 of the same register.
I couldn't find this restriction anywhere.
Besides that, setting it to 0 made me experience bugs like missing some
small screen updates. I mean, when it is 0 I missed
Re: [Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines
Hi 2013/4/16 Daniel Vetter dan...@ffwll.ch: On Mon, Apr 15, 2013 at 09:45:00PM +0100, Chris Wilson wrote: On Fri, Apr 12, 2013 at 06:16:53PM -0300, Paulo Zanoni wrote: From: Paulo Zanoni paulo.r.zan...@intel.com We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not have CRT, so just check for !IS_ULT. This problem happened on a real machine and resulted in a very ugly dmesg. Cc: sta...@vger.kernel.org Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com This doesn't apply to dinq. The approach I'd favour is to have a intel_info.has_crt similar to the other feature flags. I'm ok with piling checks on top here for now, I guess we should reconsider once the next hw platforms shows up around the corner ... We can always apply Chris's suggestion as a follow-up patch. All patches merged to dinq, thanks. I thought patch 2 would go to -fixes. We need it even for older Kernels. Thanks for the reviews, Paulo -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/4] drm: Add drm_rect_calc_{hscale, vscale}() utility functions
On Tue, Apr 16, 2013 at 01:47:20PM +0300, ville.syrj...@linux.intel.com wrote: diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h index 2b7278c..de24f16 100644 --- a/include/drm/drm_rect.h +++ b/include/drm/drm_rect.h @@ -128,5 +128,17 @@ bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip); bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, const struct drm_rect *clip, int hscale, int vscale); +int drm_rect_calc_hscale(const struct drm_rect *src, + const struct drm_rect *dst, + int min_hscale, int max_hscale); +int drm_rect_calc_vscale(const struct drm_rect *src, + const struct drm_rect *dst, + int min_vscale, int max_vscale); +int drm_rect_calc_hscale_relaxed(struct drm_rect *src, + struct drm_rect *dst, + int min_hscale, int max_hscale); +int drm_rect_calc_vscale_relaxed(struct drm_rect *src, + struct drm_rect *dst, + int min_vscale, int max_vscale); These struct drm_rect *src should be const so it is clear that dst is being manipulated. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Enable FBC at Haswell.
uhm, got your point... I'm getting exactly this values, because fence
number is 0 here,
so it is a coincidence and I should remove obj-fence_reg of FBC_CTL set,
right?
On Tue, Apr 16, 2013 at 10:37 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Apr 16, 2013 at 10:23:17AM -0300, Rodrigo Vivi wrote:
Yeah, this makes sense. Yes, I tested many times here, with 0 at bit 28 I
always got that bug with missing updates, In the way it is it always
worked
fine.
So did you actually test with this config?
FBC_CTL
28 = 1
0:3 = 0
DPFC_CONTROL_SA
29 = 1
0:4 = fence number
Oh, and for this test you should make sure fence reg != 0, so that
we can find out for sure whether the FBC_CTL bits 0:3 have some real
effect.
On Tue, Apr 16, 2013 at 7:28 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Mon, Apr 15, 2013 at 06:14:46PM -0300, Rodrigo Vivi wrote:
On Wed, Apr 10, 2013 at 5:18 AM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Apr 09, 2013 at 03:13:10PM -0300, Rodrigo Vivi wrote:
On Tue, Apr 9, 2013 at 5:35 AM, Ville Syrjälä
ville.syrj...@linux.intel.com
wrote:
On Mon, Apr 08, 2013 at 06:49:42PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support
for
HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 44
-
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 0cfc778..88fd6fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -291,6 +291,7 @@ static const struct intel_device_info
intel_haswell_m_info = {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = {
/*
aka
*/
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 5e91fbb..cb8e213 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -849,6 +849,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE 0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN (128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT (115)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 27f94cd..94e1c3a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,43 @@ static bool ironlake_fbc_enabled(struct
drm_device
*dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc,
unsigned
long
interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb =
to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int plane = intel_crtc-plane == 0 ? DPFC_CTL_PLANEA :
DPFC_CTL_PLANEB;
+ unsigned long stall_watermark = 200;
+ u32 dpfc_ctl;
+
+ dpfc_ctl = I915_READ(ILK_DPFC_CONTROL);
+ dpfc_ctl |= (plane | DPFC_CTL_LIMIT_1X);
Accroding to BSpec FBC is always tied to plane A. Bit 30 is
MBZ.
Yeah, you are right. I'm going to add a verification at begining
like:
if (intel_crtc-plane != PLANE_A) {
dev_priv-no_fbc_reason = FBC_BAD_PLANE;
return;
}
Maybe fix up plane C FBC support for IVB while you're poking
at the
general direction?
Actually I wasn't trying general directions since I splited it
out.
It
was
just bad copy and paste actually.
I'm not a fan of copy pasting code and letting the old code paths
rot.
+ dpfc_ctl |= (HSW_DPFC_CTL_FENCE_EN | obj-fence_reg);
The CPU fence field must be written with 0.
Re: [Intel-gfx] [PATCH 14/16] drm/i915: refuse to submit more batchbuffers from guilty context
On Tue, Apr 16, 2013 at 02:32:13PM +0300, Mika Kuoppala wrote: If context has recently submitted a faulty batchbuffers guilty of gpu hang and decides to keep submitting more crap, ban it permanently. v2: Store guilty ban status bool in gpu_error instead of pointers that might become danling before hang is declared. Meh. Stashing away a return parameter inside gpu_error, not pretty. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/4] drm: Add drm_rect_calc_{hscale, vscale}() utility functions
On Tue, Apr 16, 2013 at 02:42:34PM +0100, Chris Wilson wrote: On Tue, Apr 16, 2013 at 01:47:20PM +0300, ville.syrj...@linux.intel.com wrote: diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h index 2b7278c..de24f16 100644 --- a/include/drm/drm_rect.h +++ b/include/drm/drm_rect.h @@ -128,5 +128,17 @@ bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip); bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, const struct drm_rect *clip, int hscale, int vscale); +int drm_rect_calc_hscale(const struct drm_rect *src, +const struct drm_rect *dst, +int min_hscale, int max_hscale); +int drm_rect_calc_vscale(const struct drm_rect *src, +const struct drm_rect *dst, +int min_vscale, int max_vscale); +int drm_rect_calc_hscale_relaxed(struct drm_rect *src, +struct drm_rect *dst, +int min_hscale, int max_hscale); +int drm_rect_calc_vscale_relaxed(struct drm_rect *src, +struct drm_rect *dst, +int min_vscale, int max_vscale); These struct drm_rect *src should be const so it is clear that dst is being manipulated. Actually they can manipulate either src or dst, depending on whether we're trying upscale or downscale too much. The idea being that we can only decrease the size of either rect, never increase. -- 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 v3 4/4] drm/i915: Implement proper clipping for video sprites
On Tue, Apr 16, 2013 at 02:37:24PM +0100, Chris Wilson wrote:
On Tue, Apr 16, 2013 at 01:47:22PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Properly clip the source when the destination gets clipped
by the pipe dimensions.
Sadly the video sprite hardware is rather limited so it can't do proper
sub-pixel postitioning. Resort to truncating the source coordinates to
(macro)pixel boundary.
The scaling checks are done using the relaxed drm_region functions.
That means that the src/dst regions are reduced in size in order to keep
the scaling factor within the limits.
Also do some additional checking against various hardware limits.
v2: Truncate src coords instead of rounding to avoid increasing src
viewport size, and adapt to changes in drm_calc_{h,v}scale().
v3: Adapt to drm_region-drm_rect rename. Fix misaligned crtc_w for
packed YUV formats when scaling isn't supported.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Skipping to the end, use of drm_rect looks good.
The one ugly that stood out is:
/*
* If the sprite is completely covering the primary plane,
* we can disable the primary and save power.
*/
- if ((crtc_x == 0) (crtc_y == 0)
+ if (visible
+ (crtc_x == 0) (crtc_y == 0)
(crtc_w == primary_w) (crtc_h == primary_h))
disable_primary = true;
which would be
disable_primary = drm_rect_equals(dst, clip);
BUG_ON(disable_primary !visible);
with a little bit of massaging of crtc/dst.
Yeah, looks nicer. I'll add drm_rect_equals() to our repertoire.
--
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 v3 2/4] drm: Add drm_rect_calc_{hscale, vscale}() utility functions
On Tue, Apr 16, 2013 at 05:14:14PM +0300, Ville Syrjälä wrote: On Tue, Apr 16, 2013 at 02:42:34PM +0100, Chris Wilson wrote: On Tue, Apr 16, 2013 at 01:47:20PM +0300, ville.syrj...@linux.intel.com wrote: diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h index 2b7278c..de24f16 100644 --- a/include/drm/drm_rect.h +++ b/include/drm/drm_rect.h @@ -128,5 +128,17 @@ bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip); bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, const struct drm_rect *clip, int hscale, int vscale); +int drm_rect_calc_hscale(const struct drm_rect *src, + const struct drm_rect *dst, + int min_hscale, int max_hscale); +int drm_rect_calc_vscale(const struct drm_rect *src, + const struct drm_rect *dst, + int min_vscale, int max_vscale); +int drm_rect_calc_hscale_relaxed(struct drm_rect *src, + struct drm_rect *dst, + int min_hscale, int max_hscale); +int drm_rect_calc_vscale_relaxed(struct drm_rect *src, + struct drm_rect *dst, + int min_vscale, int max_vscale); These struct drm_rect *src should be const so it is clear that dst is being manipulated. Actually they can manipulate either src or dst, depending on whether we're trying upscale or downscale too much. The idea being that we can only decrease the size of either rect, never increase. Hmm, ofc you are right. I guess I'm just not that comfortable with the concept of relaxed scaling. Dare I ask you to split patch 4 so that you can convince me with a solid changelog? s/calculcated/calculated. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Enable FBC at Haswell.
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
v2: Fixes from Ville.
* Fix Plane. FBC is tied to primary plane A in HSW
* Fix DPFC initial write to avoid let trash on the register.
v3: Checking for bad plane on intel_update_fbc() as Chris suggested.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 43 +++--
3 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9ebe895..ba0935d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -314,6 +314,7 @@ static const struct intel_device_info intel_haswell_m_info
= {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = { /* aka */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 077d40f..b9725ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -857,6 +857,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET 0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN(128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT(115)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f747cb0..21885eb 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,39 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long stall_watermark = 200;
+
+ I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
+ (stall_watermark DPFC_RECOMP_STALL_WM_SHIFT) |
+ (interval DPFC_RECOMP_TIMER_COUNT_SHIFT));
+ I915_WRITE(HSW_FBC_RT_BASE,
+ obj-gtt_offset HSW_FBC_RT_BASE_ADDR_SHIFT |
+ ILK_FBC_RT_VALID);
+
+ I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
+ (HSW_DPFC_CTL_FENCE_EN | obj-fence_reg) |
+ HSW_DPFC_CTL_DISABLE_SLB_INIT);
+
+ if (obj-fence_reg != I915_FENCE_REG_NONE) {
+ I915_WRITE(SNB_DPFC_CTL_SA,
+ SNB_CPU_FENCE_ENABLE | obj-fence_reg);
+ I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
+ } else
+ I915_WRITE(SNB_DPFC_CTL_SA, ~SNB_CPU_FENCE_ENABLE);
+
+ sandybridge_blit_fbc_update(dev);
+
+ DRM_DEBUG_KMS(enabled fbc on plane A\n);
+}
+
bool intel_fbc_enabled(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -460,7 +493,8 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_MODE_TOO_LARGE;
goto out_disable;
}
- if ((IS_I915GM(dev) || IS_I945GM(dev)) intel_crtc-plane != 0) {
+ if ((IS_I915GM(dev) || IS_I945GM(dev) || IS_HASWELL(dev))
+intel_crtc-plane != 0) {
DRM_DEBUG_KMS(plane not 0, disabling compression\n);
dev_priv-no_fbc_reason = FBC_BAD_PLANE;
goto out_disable;
@@ -4180,7 +4214,12 @@ void intel_init_pm(struct drm_device *dev)
if (I915_HAS_FBC(dev)) {
if (HAS_PCH_SPLIT(dev)) {
dev_priv-display.fbc_enabled = ironlake_fbc_enabled;
- dev_priv-display.enable_fbc = ironlake_enable_fbc;
+ if (IS_HASWELL(dev))
+ dev_priv-display.enable_fbc =
+ haswell_enable_fbc;
+ else
+ dev_priv-display.enable_fbc =
+ ironlake_enable_fbc;
dev_priv-display.disable_fbc = ironlake_disable_fbc;
} else if (IS_GM45(dev)) {
dev_priv-display.fbc_enabled = g4x_fbc_enabled;
--
1.8.1.4
___
Intel-gfx mailing list
Re: [Intel-gfx] [PATCH v3 2/4] drm: Add drm_rect_calc_{hscale, vscale}() utility functions
On Tue, Apr 16, 2013 at 03:49:58PM +0100, Chris Wilson wrote: On Tue, Apr 16, 2013 at 05:14:14PM +0300, Ville Syrjälä wrote: On Tue, Apr 16, 2013 at 02:42:34PM +0100, Chris Wilson wrote: On Tue, Apr 16, 2013 at 01:47:20PM +0300, ville.syrj...@linux.intel.com wrote: diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h index 2b7278c..de24f16 100644 --- a/include/drm/drm_rect.h +++ b/include/drm/drm_rect.h @@ -128,5 +128,17 @@ bool drm_rect_intersect(struct drm_rect *r, const struct drm_rect *clip); bool drm_rect_clip_scaled(struct drm_rect *src, struct drm_rect *dst, const struct drm_rect *clip, int hscale, int vscale); +int drm_rect_calc_hscale(const struct drm_rect *src, +const struct drm_rect *dst, +int min_hscale, int max_hscale); +int drm_rect_calc_vscale(const struct drm_rect *src, +const struct drm_rect *dst, +int min_vscale, int max_vscale); +int drm_rect_calc_hscale_relaxed(struct drm_rect *src, +struct drm_rect *dst, +int min_hscale, int max_hscale); +int drm_rect_calc_vscale_relaxed(struct drm_rect *src, +struct drm_rect *dst, +int min_vscale, int max_vscale); These struct drm_rect *src should be const so it is clear that dst is being manipulated. Actually they can manipulate either src or dst, depending on whether we're trying upscale or downscale too much. The idea being that we can only decrease the size of either rect, never increase. Hmm, ofc you are right. I guess I'm just not that comfortable with the concept of relaxed scaling. Yeah it's a bit of an open question how we should do things. The hardware constraints can be very complicated to describe, so I don't see any simple/sane way to report them to userspace. Which means writing simple hardware agnostic userspace code is pretty much impossible unless the kernel is very relaxed about what it accepts. OTOH if you want to be sure that the final picture will look exactly as specified, then you'd probably want an error instead. But I haven't really made up my mind on how we should handle those two cases. Some kind of control knob might be nice, but I've not yet figured out where the knob should live, and what kind of granularity it should have. And then we also have the problem that our errno based error reporting isn't really adequate for figuring out why something failed. Usually you just have to enable drm debugs, try again, and read through the log. Dare I ask you to split patch 4 so that you can convince me with a solid changelog? So you'd like me to implement strict checks first, and then relax them in a follow up patch? s/calculcated/calculated. Fixed. Thanks. -- 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 v3 2/4] drm: Add drm_rect_calc_{hscale, vscale}() utility functions
On Tue, Apr 16, 2013 at 06:16:10PM +0300, Ville Syrjälä wrote: On Tue, Apr 16, 2013 at 03:49:58PM +0100, Chris Wilson wrote: [snip] Dare I ask you to split patch 4 so that you can convince me with a solid changelog? So you'd like me to implement strict checks first, and then relax them in a follow up patch? Yes, please. The strict checking should give us an interface with the least surprises. Then we can discuss how to relax those checks in combination with atomic modesetting flipping to make sure the interface remains consistent and unsurprising. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: VLV doesn't have LLC
On Mon, 15 Apr 2013 21:48:03 -0700
Ben Widawsky b...@bwidawsk.net wrote:
Caused by me with v2 of
commit 219f4fdbed5570f1d2e8da0af1c298dd3622060e
Author: Ben Widawsky b...@bwidawsk.net
Date: Fri Mar 15 11:17:54 2013 -0700
drm/i915: Introduce GEN7_FEATURES for device info
I don't have a VLV to test it with, Jesse, Ken, can one of you test?
Cc: Jesse Barnes jbar...@virtuousgeek.org
Cc: Kenneth Graunke kenn...@whitecape.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..c413aab 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -294,6 +294,7 @@ static const struct intel_device_info
intel_valleyview_m_info = {
.num_pipes = 2,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_llc = 0, /* legal, last one wins */
};
static const struct intel_device_info intel_valleyview_d_info = {
@@ -301,6 +302,7 @@ static const struct intel_device_info
intel_valleyview_d_info = {
.num_pipes = 2,
.is_valleyview = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+ .has_llc = 0, /* legal, last one wins */
};
static const struct intel_device_info intel_haswell_d_info = {
Oh this should help.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
--
Jesse Barnes, 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] FW: Release Notes for Beignet Version 0.1
Hi Nanhai, I'm a developer for AMD working on an Open Source OpenCL implementation for our GPUs. I am very familiar with a number of the active Open Source OpenCL projects, and I have a few comments: It is not really true to say that the code is duplicated. Have you done a survey of all the current OpenCL related Open Source projects, because it really looks like several parts of Beignet duplicate functionality that exists in one or more Open Source projects: OpenCL API Implemtation: clover (http://www.mesa3d.com) pocl (http://pocl.sourceforge.net/) OpenCL Builtin Library: pocl libclc (http://libclc.llvm.org/) OpenCL Test Suite: piglit (http://cgit.freedesktop.org/piglit) IvyBridge Compiler intel mesa driver ?? Beignet maps OpenCL into GPGPU pipeline of IvyBridge+ hardware. So this is real GPGPU other than mimic GPGPU with 3D functions. The Gallium compute interface has separate state setup and dispatch for compute, so there is no need to mimic anything with 3D functions. GPGPU different with 3D pipeline a lot on IvyBridge+. Both the pipeline setting and run time are totally different than that in 3D driver. The GPU thread spawn model, thread communication model, memory model are also totally different. The 3D and compute pipelines are different on radeon hardware too, and the gallium interface is designed for hardware like this. Also the binary representation is different. Ben choose LLVM scalar IR for many reasons(you can find the decision make reason in the document), that means IR backend are different. Clover passes LLVM scalar IR to the drivers. If you had a gallium compute driver for ivy bridge you could tell clover to give you LLVM IR targeted for NVPTX (which appears to be what you are currently generating from clang) and you would get the exact same IR that use for Beignet. For GPGPU programming, I don't see a lot benefit to introduce state tracker. There is not so many states to track. I think pretty much any OpenCL implementation is a state tracker, even if it is not called that explicitly. You're right there is not much state for OpenCL, but I think the amount of overhead added by clover is really minimal. The project is already a functional OpenCL implementation on IvyBridge at this point. 1. Most of the language features are supported. 2. Most of built-in functions are supported. 3. Global, Local memory, thread barriers are supported. 3. OpenGL to OpenCL texture sharing are supported. We have already implement something like CSS filters with this driver, and we see performance gain than OpenGL filters. It sounds like a lot of progress has been made. Are there any popular OpenCL applications that work with Beignet? I would be really disappointed to see yet another Open Source OpenCL implementation, and I would encourage you to take another look at clover or pocl and see if it would be possible to merge the Beignet code into one of those projects. I think it would be really easy to merge this code into a gallium driver, because you could drop in your compiler backend completely unchanged and there are really not very many gallium API functions that need to be implemented. I would also encourage you to take a look at the piglit OpenCL framework for tests. The framework is very good and has a lot of convenient helpers that make it easy to write tests, including a scripting language for writing kernel tests. If you have any questions about any of this, please let me know. I am happy to help and look forward to being able to collaborate with your team as I already do with your terrific Open Source graphics team. Thanks, Tom Stellard ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] intel: Add pci id for Haswell Harris Beach Mobile GT2+
On 04/15/2013 05:52 PM, Chad Versace wrote: Signed-off-by: Chad Versace chad.vers...@linux.intel.com --- intel/intel_chipset.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index b73fa0f..da2fbee 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -82,6 +82,7 @@ #define PCI_CHIP_HASWELL_CRW_S_GT1 0x0D1A /* Server */ #define PCI_CHIP_HASWELL_CRW_S_GT2 0x0D2A #define PCI_CHIP_HASWELL_CRW_S_GT2_PLUS 0x0D3A +#define PCI_CHIP_HASWELL_HSB_M_GT2_PLUS 0x0A26 /* Mobile */ #define IS_830(dev) (dev == 0x3577) #define IS_845(dev) (dev == 0x2562) @@ -198,7 +199,8 @@ devid == PCI_CHIP_HASWELL_ULT_S_GT2_PLUS || \ devid == PCI_CHIP_HASWELL_CRW_GT2_PLUS || \ devid == PCI_CHIP_HASWELL_CRW_M_GT2_PLUS || \ -devid == PCI_CHIP_HASWELL_CRW_S_GT2_PLUS) +devid == PCI_CHIP_HASWELL_CRW_S_GT2_PLUS || \ +devid == PCI_CHIP_HASWELL_HSB_M_GT2_PLUS) #define IS_HASWELL(devid) (IS_HSW_GT1(devid) || \ IS_HSW_GT2(devid)) What project is this patch for? libdrm? Regardless, NAK - see above line: #define PCI_CHIP_HASWELL_ULT_M_GT2_PLUS 0x0A26 It's already been supported for ages: commit 93fef04b1e3a83e2f884880ed1c3395f67b038ab Author: Paulo Zanoni paulo.r.zan...@intel.com Date: Mon Aug 6 14:55:23 2012 -0300 intel: add more Haswell PCI IDs Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com --Ken ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Enable FBC at Haswell.
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
v2: Fixes from Ville.
* Fix Plane. FBC is tied to primary plane A in HSW
* Fix DPFC initial write to avoid let trash on the register.
v3: Checking for bad plane on intel_update_fbc() as Chris suggested.
v4: Ville pointed out that according to BSpec FBC_CTL bits 0:3 must be 0.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 42 +++--
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9ebe895..ba0935d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -314,6 +314,7 @@ static const struct intel_device_info intel_haswell_m_info
= {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = { /* aka */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 077d40f..b9725ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -857,6 +857,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET 0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN(128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT(115)
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f747cb0..7b20fc5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,38 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long stall_watermark = 200;
+
+ I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
+ (stall_watermark DPFC_RECOMP_STALL_WM_SHIFT) |
+ (interval DPFC_RECOMP_TIMER_COUNT_SHIFT));
+ I915_WRITE(HSW_FBC_RT_BASE,
+ obj-gtt_offset HSW_FBC_RT_BASE_ADDR_SHIFT |
+ ILK_FBC_RT_VALID);
+
+ I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
+ HSW_DPFC_CTL_FENCE_EN | HSW_DPFC_CTL_DISABLE_SLB_INIT);
+
+ if (obj-fence_reg != I915_FENCE_REG_NONE) {
+ I915_WRITE(SNB_DPFC_CTL_SA,
+ SNB_CPU_FENCE_ENABLE | obj-fence_reg);
+ I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
+ } else
+ I915_WRITE(SNB_DPFC_CTL_SA, ~SNB_CPU_FENCE_ENABLE);
+
+ sandybridge_blit_fbc_update(dev);
+
+ DRM_DEBUG_KMS(enabled fbc on plane A\n);
+}
+
bool intel_fbc_enabled(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -460,7 +492,8 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_MODE_TOO_LARGE;
goto out_disable;
}
- if ((IS_I915GM(dev) || IS_I945GM(dev)) intel_crtc-plane != 0) {
+ if ((IS_I915GM(dev) || IS_I945GM(dev) || IS_HASWELL(dev))
+intel_crtc-plane != 0) {
DRM_DEBUG_KMS(plane not 0, disabling compression\n);
dev_priv-no_fbc_reason = FBC_BAD_PLANE;
goto out_disable;
@@ -4180,7 +4213,12 @@ void intel_init_pm(struct drm_device *dev)
if (I915_HAS_FBC(dev)) {
if (HAS_PCH_SPLIT(dev)) {
dev_priv-display.fbc_enabled = ironlake_fbc_enabled;
- dev_priv-display.enable_fbc = ironlake_enable_fbc;
+ if (IS_HASWELL(dev))
+ dev_priv-display.enable_fbc =
+ haswell_enable_fbc;
+ else
+ dev_priv-display.enable_fbc =
+ ironlake_enable_fbc;
dev_priv-display.disable_fbc = ironlake_disable_fbc;
} else if (IS_GM45(dev)) {
dev_priv-display.fbc_enabled = g4x_fbc_enabled;
--
1.8.1.4
[Intel-gfx] [PATCH] drm/i915: implement HSW display sequences for package C8+
From: Paulo Zanoni paulo.r.zan...@intel.com
This patch implements Display Sequences for Package C8, from the
Display Mode Set Sequence section from the Haswell documentation.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
Hi
This patch was tested and the machines do enter C8+, so it shows our driver is
not preventing C8+. There may be additional patches in the future to allow C8+
in more cases, but they shouldn't stop this patch from being merged.
Please also notice that we need i915.disable_power_well=1 because we can't allow
C8+ if the power well is enabled. So even if we merge this patch, the feature
won't be enabled by default. This is not really a problem and it allows us to
properly test everything without needing to rebase a 600-line patch every time.
I wrote this patch on top of drm-intel-next-queued + the 4 patches I already
sent to this list:
- 2 patches that fix CPT FDI RX polarity bugs (already reviewed by Imre)
- 2 patches that enable FIFO underruns and Poison messages (not reviewed yet)
Thanks,
Paulo
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu/drm/i915/i915_drv.h | 29 +++
drivers/gpu/drm/i915/i915_reg.h | 27 ++
drivers/gpu/drm/i915/intel_crt.c | 26 +-
drivers/gpu/drm/i915/intel_display.c | 459 ++
drivers/gpu/drm/i915/intel_dp.c | 11 +-
drivers/gpu/drm/i915/intel_drv.h |2 +
drivers/gpu/drm/i915/intel_hdmi.c|3 +
8 files changed, 549 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3b315ba..bc81ab9 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1630,6 +1630,7 @@ int i915_driver_load(struct drm_device *dev, unsigned
long flags)
spin_lock_init(dev_priv-gpu_error.lock);
spin_lock_init(dev_priv-rps.lock);
mutex_init(dev_priv-dpio_lock);
+ mutex_init(dev_priv-c8_lock);
mutex_init(dev_priv-rps.hw_lock);
mutex_init(dev_priv-modeset_restore_lock);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b0da4ae..b64d0e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -504,6 +504,29 @@ struct intel_gmbus {
struct drm_i915_private *dev_priv;
};
+struct i915_c8_saved_registers {
+ u32 de_imr;
+ u32 de_ier;
+ u32 aud_imr;
+ u32 aud_ier;
+ u32 gt_imr;
+ u32 gt_ier;
+ u32 pm_imr;
+ u32 pm_ier;
+ u32 srd_imr;
+ u32 hotplug_ctl;
+ u32 err_int;
+
+ u32 sde_imr;
+ u32 sde_ier;
+ u32 fdirx_imr;
+ u32 gtcpch_imr;
+ u32 shotplug_ctl;
+ u32 serr_int;
+
+ u32 lcpll_freq;
+};
+
struct i915_suspend_saved_registers {
u8 saveLBB;
u32 saveDSPACNTR;
@@ -1068,6 +1091,12 @@ typedef struct drm_i915_private {
struct i915_suspend_saved_registers regfile;
+ struct i915_c8_saved_registers c8_regfile;
+ bool allowing_package_c8;
+ /* Wake ups should happen when allowing_package_c8 is true. */
+ int c8_wakeup_refcnt;
+ struct mutex c8_lock;
+
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d954612..6808ae5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2013,6 +2013,8 @@
#define BLC_PWM_CPU_CTL2 0x48250
#define BLC_PWM_CPU_CTL0x48254
+#define HSW_BLC_PWM2_CTL 0x48350
+
/* PCH CTL1 is totally different, all but the below bits are reserved. CTL2 is
* like the normal CTL from gen4 and earlier. Hooray for confusing naming. */
#define BLC_PWM_PCH_CTL1 0xc8250
@@ -2021,6 +2023,12 @@
#define BLM_PCH_POLARITY (1 29)
#define BLC_PWM_PCH_CTL2 0xc8254
+#define UTIL_PIN_CTL 0x48400
+#define UTIL_PIN_ENABLE (1 31)
+
+#define PCH_GTC_CTL0xe7000
+#define PCH_GTC_ENABLE (1 31)
+
/* TV port control */
#define TV_CTL 0x68000
/** Enables the TV encoder */
@@ -3535,6 +3543,16 @@
#define DEIIR 0x44008
#define DEIER 0x4400c
+#define AUDIMR 0x44084
+#define AUDIIR 0x44088
+#define AUDIER 0x4408c
+
+#define SRDIMR 0x64834
+#define SRDIIR 0x64838
+
+#define PCH_GTCIMR 0xe7054
+#define PCH_GTCIIR 0xe7058
+
/* GT interrupt.
* Note that for gen6+ the ring-specific interrupt bits do alias with the
* corresponding bits in the per-ring interrupt control registers. */
@@ -4709,6 +4727,8 @@
#define SBI_SSCAUXDIV_FINALDIV2SEL(x)((x)4)
#define SBI_DBUFF00x2a00
#define SBI_DBUFF0_ENABLE(10)
+#define SBI_GEN0 0x1f00
+#define SBI_GEN0_ENABLE (10)
/* LPT PIXCLK_GATE */
Re: [Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines
On Tue, Apr 16, 2013 at 3:41 PM, Paulo Zanoni przan...@gmail.com wrote: All patches merged to dinq, thanks. I thought patch 2 would go to -fixes. We need it even for older Kernels. This late in the release cycle -fixes is for severe regressions and black-screen level non-regression issues only. Hence merged through -next with cc: stable. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable FBC at Haswell.
On Tue, Apr 16, 2013 at 01:33:44PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
v2: Fixes from Ville.
* Fix Plane. FBC is tied to primary plane A in HSW
* Fix DPFC initial write to avoid let trash on the register.
v3: Checking for bad plane on intel_update_fbc() as Chris suggested.
v4: Ville pointed out that according to BSpec FBC_CTL bits 0:3 must be 0.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 42
+++--
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9ebe895..ba0935d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -314,6 +314,7 @@ static const struct intel_device_info
intel_haswell_m_info = {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = {/* aka */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 077d40f..b9725ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -857,6 +857,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE 0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN (128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT (115)
These registers/bits already exists on IVB. All the registers you set
seem to be in line with IVB BSpec, so I think you just need to to
s/haswell/gen7/ everywhere, and then we get FBC for IVB for free.
Well, the only real work left would be adding plane B and C FBC
support on IVB.
The new DPFC_CTL bits should also probably be grouped with the rest of
the ILK_DPFC_CONTROL bits, otherwise it's difficult to know which
register they belong to.
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index f747cb0..7b20fc5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,38 @@ static bool ironlake_fbc_enabled(struct drm_device *dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long stall_watermark = 200;
+
+ I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
+(stall_watermark DPFC_RECOMP_STALL_WM_SHIFT) |
+(interval DPFC_RECOMP_TIMER_COUNT_SHIFT));
+ I915_WRITE(HSW_FBC_RT_BASE,
+obj-gtt_offset HSW_FBC_RT_BASE_ADDR_SHIFT |
+ILK_FBC_RT_VALID);
+
+ I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
+HSW_DPFC_CTL_FENCE_EN | HSW_DPFC_CTL_DISABLE_SLB_INIT);
+
+ if (obj-fence_reg != I915_FENCE_REG_NONE) {
Is there actually a case that we wouldn't have a fence? I think we
always reserve a fence for scanout even though we wouldn't really
need it on gen4+ (or for untiled on gen2-3). At least we don't have any
sanity checks for fence_reg in the ironlake_enable_fbc().
But if this can happen, then shouldn't we also clear the
fence enable bit from ILK_DPFC_CONTROL?
+ I915_WRITE(SNB_DPFC_CTL_SA,
+SNB_CPU_FENCE_ENABLE | obj-fence_reg);
+ I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
+ } else
+ I915_WRITE(SNB_DPFC_CTL_SA, ~SNB_CPU_FENCE_ENABLE);
+
+ sandybridge_blit_fbc_update(dev);
+
+ DRM_DEBUG_KMS(enabled fbc on plane A\n);
+}
+
bool intel_fbc_enabled(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -460,7 +492,8 @@ void intel_update_fbc(struct drm_device *dev)
dev_priv-no_fbc_reason = FBC_MODE_TOO_LARGE;
goto out_disable;
}
- if ((IS_I915GM(dev) || IS_I945GM(dev)) intel_crtc-plane != 0) {
+ if ((IS_I915GM(dev) || IS_I945GM(dev) || IS_HASWELL(dev))
+ intel_crtc-plane != 0) {
DRM_DEBUG_KMS(plane not 0, disabling compression\n);
dev_priv-no_fbc_reason =
Re: [Intel-gfx] [PATCH] drm/i915: HSW: allow PCH clock gating for suspend
2013/4/16 Imre Deak imre.d...@intel.com:
On Tue, 2013-04-16 at 14:35 +0300, Ville Syrjälä wrote:
On Tue, Apr 16, 2013 at 02:25:16PM +0300, Imre Deak wrote:
For the device to enter D3 we should enable PCH clock gating.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c |5 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 18 ++
5 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..e9a82f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,6 +521,8 @@ static int i915_drm_freeze(struct drm_device *dev)
*/
list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
dev_priv-display.crtc_disable(crtc);
+
+ intel_modeset_suspend_hw(dev);
}
i915_save_state(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index b5a495a..e549e6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1831,6 +1831,7 @@ static inline void
intel_unregister_dsm_handler(void) { return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
+extern void intel_modeset_suspend_hw(struct drm_device *dev);
extern void intel_modeset_init(struct drm_device *dev);
extern void intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 457a0a0..e9192bf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8984,6 +8984,11 @@ void intel_modeset_init_hw(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
}
+void intel_modeset_suspend_hw(struct drm_device *dev)
+{
+ intel_suspend_hw(dev);
+}
+
Why this extra level of indirection?
I thought it'd be more symmetric w.r.t.
__i915_drm_thaw-intel_modeset_init_hw().
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..8b29897 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -652,6 +652,7 @@ extern void assert_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe,
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
extern void intel_init_clock_gating(struct drm_device *dev);
+extern void intel_suspend_hw(struct drm_device *dev);
extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..3567881 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3735,6 +3735,18 @@ static void lpt_init_clock_gating(struct drm_device
*dev)
PCH_LP_PARTITION_LEVEL_DISABLE);
}
+static void lpt_allow_clock_gating(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
+
+ val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
+ }
So who sets it back when we resume?
intel_modeset_init_hw()-intel_init_clock_gating()
+}
+
static void haswell_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4085,6 +4097,12 @@ void intel_init_clock_gating(struct drm_device *dev)
dev_priv-display.init_clock_gating(dev);
}
+void intel_suspend_hw(struct drm_device *dev)
+{
+ if (IS_HASWELL(dev))
+ lpt_allow_clock_gating(dev);
Do you need the HSW check? Isn't the LPT LP check enough?
Not sure. According to the spec this is a workaround for HSW/LPT.
I'd check for HAS_PCH_LPT before calling lpt_allow_clock_gating. Let's
not forget that, for example, PPT is considered the same as CPT, so
any code that's inside a HAS_PCH_CPT runs for both SNB and IVB.
Optional bikeshed: maybe rename lpt_allow_clock_gating to lpt_suspend_hw?
+}
+
void intel_set_power_well(struct drm_device *dev, bool enable)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
On Tue, Apr 16, 2013 at 01:36:58PM +0200, Egbert Eich wrote: We disable hoptplug detection when we encounter a hotplug event storm. Still hotplug detection is required on some outputs (like Display Port). The interrupt storm may be only temporary (on certain Dell Laptops for instance it happens at certain charging states of the system). Thus we enable it after a certain grace period (2 minutes). Should the interrupt storm persist it will be detected immediately and it will be disabled again. v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker. v3: Clarified loop start value, Removed superfluous test for Ivybridge and Haswell, Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä) v4: Fixed two bugs pointed out by Jani Nikula. Signed-off-by: Egbert Eich e...@suse.de Reviewed-by: Jani Nikula jani.nik...@intel.com I've queued up patches 1-5 of this series, thanks a lot for doing all this. Wrt bikesheds: checkpatch seemed a bit unhappy about some of them, but I've decided that I want this more for 3.10 than care about checkpatch ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: preserve the PBC bits of TRANS_CHICKEN2
On Wed, Apr 10, 2013 at 06:23:25PM +0300, Imre Deak wrote:
On Mon, 2013-04-08 at 15:48 -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h |8 ++--
drivers/gpu/drm/i915/intel_pm.c |7 ++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 759b1b8..f4d6673 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3949,8 +3949,12 @@
#define _TRANSA_CHICKEN20xf0064
#define _TRANSB_CHICKEN20xf1064
#define TRANS_CHICKEN2(pipe) _PIPE(pipe, _TRANSA_CHICKEN2,
_TRANSB_CHICKEN2)
-#define TRANS_CHICKEN2_TIMING_OVERRIDE(131)
-#define TRANS_CHICKEN2_FDI_POLARITY_REVERSED (129)
+#define TRANS_CHICKEN2_TIMING_OVERRIDE(131)
+#define TRANS_CHICKEN2_FDI_POLARITY_REVERSED (129)
+#define TRANS_CHICKEN2_FRAME_START_DELAY_MASK (327)
+#define TRANS_CHICKEN2_DISABLE_DEEP_COLOR_COUNTER (126)
+#define TRANS_CHICKEN2_DISABLE_DEEP_COLOR_MODESWITCH (125)
+#define TRANS_CHICKEN2_PBC(130 |
0x1ff)
The above _PBC value seems to be redundant. In any case on both patches:
Reviewed-by: Imre Deak imre.d...@intel.com
Redundant #define deleted and both patches merged, thanks.
-Daniel
#define SOUTH_CHICKEN1 0xc2000
#define FDIA_PHASE_SYNC_SHIFT_OVR 19
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index ce3d892..e4ead41 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3589,9 +3589,14 @@ static void cpt_init_clock_gating(struct drm_device
*dev)
* downward, on (only) LVDS of some HP laptops with IVY.
*/
for_each_pipe(pipe) {
- val = TRANS_CHICKEN2_TIMING_OVERRIDE;
+ val = I915_READ(TRANS_CHICKEN2(pipe));
+ val |= TRANS_CHICKEN2_TIMING_OVERRIDE;
+ val = ~TRANS_CHICKEN2_FDI_POLARITY_REVERSED;
if (dev_priv-fdi_rx_polarity_inverted)
val |= TRANS_CHICKEN2_FDI_POLARITY_REVERSED;
+ val = ~TRANS_CHICKEN2_FRAME_START_DELAY_MASK;
+ val = ~TRANS_CHICKEN2_DISABLE_DEEP_COLOR_COUNTER;
+ val = ~TRANS_CHICKEN2_DISABLE_DEEP_COLOR_MODESWITCH;
I915_WRITE(TRANS_CHICKEN2(pipe), val);
}
/* WADP0ClockGatingDisable */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: HSW: allow PCH clock gating for suspend
On Tue, 2013-04-16 at 14:50 -0300, Paulo Zanoni wrote:
2013/4/16 Imre Deak imre.d...@intel.com:
On Tue, 2013-04-16 at 14:35 +0300, Ville Syrjälä wrote:
On Tue, Apr 16, 2013 at 02:25:16PM +0300, Imre Deak wrote:
For the device to enter D3 we should enable PCH clock gating.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c |5 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_pm.c | 18 ++
5 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..e9a82f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -521,6 +521,8 @@ static int i915_drm_freeze(struct drm_device *dev)
*/
list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
dev_priv-display.crtc_disable(crtc);
+
+ intel_modeset_suspend_hw(dev);
}
i915_save_state(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index b5a495a..e549e6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1831,6 +1831,7 @@ static inline void
intel_unregister_dsm_handler(void) { return; }
/* modesetting */
extern void intel_modeset_init_hw(struct drm_device *dev);
+extern void intel_modeset_suspend_hw(struct drm_device *dev);
extern void intel_modeset_init(struct drm_device *dev);
extern void intel_modeset_gem_init(struct drm_device *dev);
extern void intel_modeset_cleanup(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 457a0a0..e9192bf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8984,6 +8984,11 @@ void intel_modeset_init_hw(struct drm_device *dev)
mutex_unlock(dev-struct_mutex);
}
+void intel_modeset_suspend_hw(struct drm_device *dev)
+{
+ intel_suspend_hw(dev);
+}
+
Why this extra level of indirection?
I thought it'd be more symmetric w.r.t.
__i915_drm_thaw-intel_modeset_init_hw().
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..8b29897 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -652,6 +652,7 @@ extern void assert_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe,
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
extern void intel_init_clock_gating(struct drm_device *dev);
+extern void intel_suspend_hw(struct drm_device *dev);
extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..3567881 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3735,6 +3735,18 @@ static void lpt_init_clock_gating(struct
drm_device *dev)
PCH_LP_PARTITION_LEVEL_DISABLE);
}
+static void lpt_allow_clock_gating(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
+
+ val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
+ I915_WRITE(SOUTH_DSPCLK_GATE_D, val);
+ }
So who sets it back when we resume?
intel_modeset_init_hw()-intel_init_clock_gating()
+}
+
static void haswell_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -4085,6 +4097,12 @@ void intel_init_clock_gating(struct drm_device
*dev)
dev_priv-display.init_clock_gating(dev);
}
+void intel_suspend_hw(struct drm_device *dev)
+{
+ if (IS_HASWELL(dev))
+ lpt_allow_clock_gating(dev);
Do you need the HSW check? Isn't the LPT LP check enough?
Not sure. According to the spec this is a workaround for HSW/LPT.
I'd check for HAS_PCH_LPT before calling lpt_allow_clock_gating. Let's
not forget that, for example, PPT is considered the same as CPT, so
any code that's inside a HAS_PCH_CPT runs for both SNB and IVB.
Optional bikeshed: maybe rename lpt_allow_clock_gating to lpt_suspend_hw?
Ok, will change these.
--Imre
___
Intel-gfx mailing list
Re: [Intel-gfx] FW: Release Notes for Beignet Version 0.1
Hi, On 16.04.2013 09:50, Zhigang Gong wrote: [Gong, Zhigang] As I know, Simon implemented ICD for Beignet and it may need some time to rebase to the latest beignet code base. If you are interested, this is the link http://psi5.com/~geier/beignet.git. I've rebased on top of the release 0.1 tag, and updated accordingly. These changes have not yet been widely tested and should be subject to extensive debate. I've uploaded a build of the package to Debian experimental to allow for some testing by brave adventurers. Note that these packages do not support OpenGL sharing as Debian has an old version of Mesa. Changes: commit 13c650fb4492b7c96b1a1dfb31cf048da3de9729 Author: Simon Richter simon.rich...@hogyros.de Date: Tue Apr 2 15:01:52 2013 +0200 Use clang command from PATH This assumes that LLVM is installed in the system path, but avoids compiling the path of binaries into the library. commit 8d468fcc820330c872441f552cf0edcc73e10341 Author: Simon Richter simon.rich...@hogyros.de Date: Tue Apr 16 20:04:42 2013 +0200 Make EGL optional This fixes builds if EGL is unavailable. The OpenGL sharing extension will be disabled then. commit bb03533ee094f4b0a9e0a5f17fe20388e960c7d3 Author: Simon Richter simon.rich...@hogyros.de Date: Tue Apr 16 20:02:08 2013 +0200 Prefer versioned llvm-config If multiple versions are installed, prefer version 3.2 before falling back to the default version. commit 19cee97add90abcd7e3410b7b8d748c4e99e Author: Simon Richter simon.rich...@hogyros.de Date: Fri Apr 12 11:21:19 2013 +0200 Accept glibc's implementation of memalign() If the platform is not Linux, but glibc based, we assume that the memalign() function is working satisfactorily. commit dceb446181a23209888595d13b0382e49b1a43bc Author: Simon Richter simon.rich...@hogyros.de Date: Wed Apr 3 20:32:45 2013 +0200 Implement KHR ICD extension This adds a pointer to the dispatch table at the beginning of every object of type - cl_command_queue - cl_context - cl_device_id - cl_event - cl_kernel - cl_mem - cl_platform_id - cl_program - cl_sampler as required by the ICD specification. The layout of the dispatch table comes from the OpenCL ICD loader by Brice Videau brice.vid...@imag.fr and Vincent Danjean vincent.danj...@ens-lyon.org. To avoid dispatch table entries being overwritten with the ICD loader's implementations of the CL functions (as would be the proper behaviour for the ELF loader), the -Bsymbolic option is given to the linker. commit 2756d1a9a2446faad1bacd203c234ce81581179b Author: Simon Richter simon.rich...@hogyros.de Date: Tue Apr 2 15:11:01 2013 +0200 Implement clGetExtensionFunctionAddress() This function should not fail if a function entry point cannot be found -- instead we return NULL. commit 4fe13e919524378b799205e71aa2c35f7049bbf9 Author: Simon Richter simon.rich...@hogyros.de Date: Tue Apr 16 20:05:54 2013 +0200 Avoid extension names as preprocessor tokens The Khronos Group headers define constants with the names of extensions if the header defines the extension API. When the preprocessor sees one of these names, it performs macro substitution, leading to compilation errors. commit 644432d586d47ddcdbc9e9e91732a715a73884c2 Author: Simon Richter simon.rich...@hogyros.de Date: Tue Apr 2 14:51:52 2013 +0200 Fix typo in cl_get_platform_info function name Simon signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
On Tue, Apr 16, 2013 at 08:07:09PM +0200, Daniel Vetter wrote: On Tue, Apr 16, 2013 at 01:36:58PM +0200, Egbert Eich wrote: We disable hoptplug detection when we encounter a hotplug event storm. Still hotplug detection is required on some outputs (like Display Port). The interrupt storm may be only temporary (on certain Dell Laptops for instance it happens at certain charging states of the system). Thus we enable it after a certain grace period (2 minutes). Should the interrupt storm persist it will be detected immediately and it will be disabled again. v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker. v3: Clarified loop start value, Removed superfluous test for Ivybridge and Haswell, Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä) v4: Fixed two bugs pointed out by Jani Nikula. Signed-off-by: Egbert Eich e...@suse.de Reviewed-by: Jani Nikula jani.nik...@intel.com I've queued up patches 1-5 of this series, thanks a lot for doing all this. Wrt bikesheds: checkpatch seemed a bit unhappy about some of them, but I've decided that I want this more for 3.10 than care about checkpatch ;-) I've run checkpatch on every patch - here it only complains about lines longer than 80 characters. Now - if you can prove that my file introduced lines with more than 80 characters to a file that had no such lines already we can talk about fixing this ;p Cheers, Egbert. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/7] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
On Tue, Apr 16, 2013 at 10:22 PM, Egbert Eich e...@freedesktop.org wrote: On Tue, Apr 16, 2013 at 08:07:09PM +0200, Daniel Vetter wrote: On Tue, Apr 16, 2013 at 01:36:58PM +0200, Egbert Eich wrote: We disable hoptplug detection when we encounter a hotplug event storm. Still hotplug detection is required on some outputs (like Display Port). The interrupt storm may be only temporary (on certain Dell Laptops for instance it happens at certain charging states of the system). Thus we enable it after a certain grace period (2 minutes). Should the interrupt storm persist it will be detected immediately and it will be disabled again. v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker. v3: Clarified loop start value, Removed superfluous test for Ivybridge and Haswell, Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä) v4: Fixed two bugs pointed out by Jani Nikula. Signed-off-by: Egbert Eich e...@suse.de Reviewed-by: Jani Nikula jani.nik...@intel.com I've queued up patches 1-5 of this series, thanks a lot for doing all this. Wrt bikesheds: checkpatch seemed a bit unhappy about some of them, but I've decided that I want this more for 3.10 than care about checkpatch ;-) I've run checkpatch on every patch - here it only complains about lines longer than 80 characters. Now - if you can prove that my file introduced lines with more than 80 characters to a file that had no such lines already we can talk about fixing this ;p Yeah, the nesting levels in i915_irq.c are already pretty offensive, hence why I didn't complain louder than with a little comment after merging ;-) But maybe someone reading this is a bit bored and looks for an easy refactor patch ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Enable FBC at Haswell.
On Tue, Apr 16, 2013 at 2:49 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
On Tue, Apr 16, 2013 at 01:33:44PM -0300, Rodrigo Vivi wrote:
This patch introduce Frame Buffer Compression (FBC) support for HSW.
It adds a new function haswell_enable_fbc to avoid getting
ironlake_enable_fbc messed with many IS_HASWELL checks.
v2: Fixes from Ville.
* Fix Plane. FBC is tied to primary plane A in HSW
* Fix DPFC initial write to avoid let trash on the register.
v3: Checking for bad plane on intel_update_fbc() as Chris suggested.
v4: Ville pointed out that according to BSpec FBC_CTL bits 0:3 must be 0.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_pm.c | 42
+++--
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 9ebe895..ba0935d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -314,6 +314,7 @@ static const struct intel_device_info
intel_haswell_m_info = {
GEN7_FEATURES,
.is_haswell = 1,
.is_mobile = 1,
+ .has_fbc = 1,
};
static const struct pci_device_id pciidlist[] = {/* aka */
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index 077d40f..b9725ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -857,6 +857,12 @@
#define SNB_CPU_FENCE_ENABLE (129)
#define DPFC_CPU_FENCE_OFFSET0x100104
+/* Framebuffer compression for Haswell */
+#define HSW_FBC_RT_BASE 0x7020
+#define HSW_FBC_RT_BASE_ADDR_SHIFT 12
+
+#define HSW_DPFC_CTL_FENCE_EN (128)
+#define HSW_DPFC_CTL_DISABLE_SLB_INIT (115)
These registers/bits already exists on IVB. All the registers you set
seem to be in line with IVB BSpec, so I think you just need to to
s/haswell/gen7/ everywhere, and then we get FBC for IVB for free.
Well, the only real work left would be adding plane B and C FBC
support on IVB.
I implemented here the ivb version, tested and it didn't worked.
So I believe we can go on with HSW names and change it in the future if we
can really get fbc working on ivb.
What do you think?
The new DPFC_CTL bits should also probably be grouped with the rest of
the ILK_DPFC_CONTROL bits, otherwise it's difficult to know which
register they belong to.
I just didn't do this because it was already organized by platforms. But it
makes sense. coming on v5.
/*
* GPIO regs
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index f747cb0..7b20fc5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -253,6 +253,38 @@ static bool ironlake_fbc_enabled(struct drm_device
*dev)
return I915_READ(ILK_DPFC_CONTROL) DPFC_CTL_EN;
}
+static void haswell_enable_fbc(struct drm_crtc *crtc, unsigned long
interval)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_framebuffer *fb = crtc-fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb-obj;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ unsigned long stall_watermark = 200;
+
+ I915_WRITE(ILK_DPFC_RECOMP_CTL, DPFC_RECOMP_STALL_EN |
+(stall_watermark DPFC_RECOMP_STALL_WM_SHIFT) |
+(interval DPFC_RECOMP_TIMER_COUNT_SHIFT));
+ I915_WRITE(HSW_FBC_RT_BASE,
+obj-gtt_offset HSW_FBC_RT_BASE_ADDR_SHIFT |
+ILK_FBC_RT_VALID);
+
+ I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
+HSW_DPFC_CTL_FENCE_EN | HSW_DPFC_CTL_DISABLE_SLB_INIT);
+
+ if (obj-fence_reg != I915_FENCE_REG_NONE) {
Is there actually a case that we wouldn't have a fence? I think we
always reserve a fence for scanout even though we wouldn't really
need it on gen4+ (or for untiled on gen2-3). At least we don't have any
sanity checks for fence_reg in the ironlake_enable_fbc().
Yeah, you are right. I don't see any case without the fence. So I'm going
to remove this check and else block in v5.
But if this can happen, then shouldn't we also clear the
fence enable bit from ILK_DPFC_CONTROL?
+ I915_WRITE(SNB_DPFC_CTL_SA,
+SNB_CPU_FENCE_ENABLE | obj-fence_reg);
+ I915_WRITE(DPFC_CPU_FENCE_OFFSET, crtc-y);
+ } else
+ I915_WRITE(SNB_DPFC_CTL_SA, ~SNB_CPU_FENCE_ENABLE);
+
+ sandybridge_blit_fbc_update(dev);
+
+
