Re: [Intel-gfx] [PATCH] drm/i915: Expose LLC size to user space
On Wed, Jul 10, 2013 at 05:16:54PM -0700, Chad Versace wrote:
On 07/09/2013 07:58 PM, Ben Widawsky wrote:
The algorithm/information was originally written by Chad, though I
changed the control flow, and I think his original code had a couple of
bugs, though I didn't look very hard before rewriting. That could have
also been different interpretations of the spec.
The excellent comments remain entirely copied from Chad's code.
I've tested this on two platforms, and it seems to perform how I want.
CC: Chad Versace chad.vers...@linux.intel.com
CC: Bryan Bell bryan.j.b...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 53
+
3 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 0e22142..377949e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -974,7 +974,7 @@ static int i915_getparam(struct drm_device *dev, void
*data,
value = 1;
break;
case I915_PARAM_HAS_LLC:
-value = HAS_LLC(dev);
+value = dev_priv-llc_size;
break;
case I915_PARAM_HAS_ALIASING_PPGTT:
value = dev_priv-mm.aliasing_ppgtt ? 1 : 0;
I would like to see a dedicated param for the llc size. 'has' is always
boolean valued, right?
Sounds like Chris wants the same anyway, but no. Getparam is always an
int. Just the name is, 'has'
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index c8d6104..43a549d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1187,6 +1187,8 @@ typedef struct drm_i915_private {
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
+
+size_t llc_size;
} drm_i915_private_t;
/* Iterate over initialised rings */
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index af61be8..a070686 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4282,6 +4282,57 @@ i915_gem_lastclose(struct drm_device *dev)
DRM_ERROR(failed to idle hardware: %d\n, ret);
}
+/**
+ * Return the size, in bytes, of the CPU L3 cache size. If the CPU has no L3
+ * cache, or if an error occurs in obtaining the cache size, then return 0.
+ * From Intel Processor Identification and the CPUID Instruction 5.15
+ * Deterministic Cache Parmaeters (Function 04h):
+ *When EAX is initialized to a value of 4, the CPUID instruction returns
+ *deterministic cache information in the EAX, EBX, ECX and EDX
registers.
+ *This function requires ECX be initialized with an index which
indicates
+ *which cache to return information about. The OS is expected to call
this
+ *function (CPUID.4) with ECX = 0, 1, 2, until EAX[4:0] == 0,
indicating no
+ *more caches. The order in which the caches are returned is not
specified
+ *and may change at Intel's discretion.
+ *
+ * Equation 5-4. Calculating the Cache Size in bytes:
+ * = (Ways +1) � (Partitions +1) � (Line Size +1) � (Sets +1)
+ * = (EBX[31:22] +1) � (EBX[21:12] +1) � (EBX[11:0] +1 � (ECX + 1)
+ */
+static size_t get_llc_size(struct drm_device *dev)
+{
+u8 cnt = 0;
+unsigned int eax, ebx, ecx, edx;
+
+if (!HAS_LLC(dev))
+return 0;
+
+do {
+uint32_t cache_level;
+uint32_t associativity, line_partitions, line_size, sets;
+
+eax = 4;
+ecx = cnt;
+__cpuid(eax, ebx, ecx, edx);
+
+cache_level = (eax 5) 0x7;
+if (cache_level != 3)
+continue;
+
+associativity = ((ebx 22) 0x3ff) + 1;
+line_partitions = ((ebx 12) 0x3ff) + 1;
+line_size = (ebx 0xfff) + 1;
+sets = ecx + 1;
+
+return associativity * line_partitions * line_size * sets;
+} while (eax 0x1f ++cnt);
+
+/* Let user space know we have LLC, but we can't figure it out */
+DRM_DEBUG_DRIVER(Couldn't find LLC size. Bug?\n);
+return 1;
+}
This function looks good to me, since I wrote most of it ;)
Still arguing over whether or not to try to pull it from the x86 core. I
tried to get some comment from hpa today , but haven't heard anything
yet.
I do agree if we can just take the code from the x86 core it would be
best, but AFAICT I'd need to change some code, or do an almost equal
amount of logic to determine l2 vs. l3. Thinking about it now though, I
suppose I can assume if HAS_LLC, then whatever cache size was obtained
during boot is l3... dunno.
--
Ben Widawsky, Intel Open Source Technology Center
Re: [Intel-gfx] [PATCH 06/11] drm/i915: plumb VM into object operations
On Thu, Jul 11, 2013 at 12:23 AM, Ben Widawsky b...@bwidawsk.net wrote: On Wed, Jul 10, 2013 at 07:05:52PM +0200, Daniel Vetter wrote: On Wed, Jul 10, 2013 at 09:37:10AM -0700, Ben Widawsky wrote: On Tue, Jul 09, 2013 at 09:15:01AM +0200, Daniel Vetter wrote: On Mon, Jul 08, 2013 at 11:08:37PM -0700, Ben Widawsky wrote: This patch was formerly known as: drm/i915: Create VMAs (part 3) - plumbing This patch adds a VM argument, bind/unbind, and the object offset/size/color getters/setters. It preserves the old ggtt helper functions because things still need, and will continue to need them. Some code will still need to be ported over after this. v2: Fix purge to pick an object and unbind all vmas This was doable because of the global bound list change. v3: With the commit to actually pin/unpin pages in place, there is no longer a need to check if unbind succeeded before calling put_pages(). Make put_pages only BUG() after checking pin count. v4: Rebased on top of the new hangcheck work by Mika plumbed eb_destroy also Many checkpatch related fixes v5: Very large rebase Signed-off-by: Ben Widawsky b...@bwidawsk.net This one is a rather large beast. Any chance we could split it into topics, e.g. convert execbuf code, convert shrinker code? Or does that get messy, fast? I've thought of this... The one solution I came up with is to have two bind/unbind functions (similar to what I did with pin, and indeed it was my original plan with pin), and do the set_caching one separately. I think it won't be too messy, just a lot of typing, as Keith likes to say. However, my opinion was, since it's early in the merge cycle, we don't yet have multiple VMs, and it's /mostly/ a copypasta kind of patch, it's not a big deal. At a functional level too, I felt this made more sense. So I'll defer to your request on this and start splitting it up, unless my email has changed your mind ;-). Well, my concern is mostly in reviewing since we need to think about each case and whether it makes sense to talk in therms of vma or objects in that function. And what exactly to test. If you've played around and concluded it'll be a mess then I don't think it'll help in reviewing. So pointless. I said I don't think it will be a mess, though I feel it won't really help review too much. Can you take a crack and review and poke me if you want me to try it. I'd rather not do it if I can avoid it, so I can try to go back to my 15 patch maximum rule. Still, there's a bunch of questions on this patch that we need to discuss ;-) Ready whenever. It's waiting for you in my first reply, just scroll down a bit ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [Regression 3.10.0+] i915: pipe state does not match!
Hi everybody! During booting a pipe state doesn't match error occures. Reproducibility: high (3 of 3 test boots) Hardware: Aopen i915GMm-hfs, Pentium-M, opensuse 12.3, kernel 3.10.0+, git 496322bc91e35007ed754184dcd447a02b6dd685 trace attached. cu, Knut [2.273091] Linux agpgart interface v0.103 [2.273265] agpgart-intel :00:00.0: Intel 915GM Chipset [2.273431] agpgart-intel :00:00.0: detected gtt size: 262144K total, 262144K mappable [2.274173] agpgart-intel :00:00.0: detected 8192K stolen memory [2.274624] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000 [2.274775] [drm] Initialized drm 1.1.0 20060810 [2.278402] [drm] Memory usable by graphics device = 256M [2.278536] i915 :00:02.0: setting latency timer to 64 [2.280498] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.280507] [drm] Driver supports precise vblank timestamp query. [2.281762] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.282130] [drm] Skipping LVDS initialization for AOpen i915GMm-HFS [2.924782] [drm] initialized overlay support [3.136113] tsc: Refined TSC clocksource calibration: 1199.999 MHz [3.323980] [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.control (expected 0, found 8) [3.324182] [ cut here ] [3.324196] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/intel_display.c:8287 check_crtc_state+0x62b/0x65c() [3.324201] pipe state doesn't match! [3.324206] Modules linked in: [3.324216] CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-main+ #14 [3.324221] Hardware name: /i915GMm-HFS, BIOS 6.00 PG 11/04/2005 [3.324227] c06f10ea f606f89c c052e356 f606f8b4 c012a137 c03bde50 f60e3000 [3.324247] f6218000 f606f8cc c012a1c1 0009 f606f8c4 c06f10ea f606f8e0 [3.324267] f606fb30 c03bde50 c06f047a 205f c06f10ea c0168801 0003 f635af44 [3.324287] Call Trace: [3.324300] [c052e356] dump_stack+0x16/0x18 [3.324311] [c012a137] warn_slowpath_common+0x5a/0x71 [3.324320] [c03bde50] ? check_crtc_state+0x62b/0x65c [3.324330] [c012a1c1] warn_slowpath_fmt+0x2b/0x2f [3.324339] [c03bde50] check_crtc_state+0x62b/0x65c [3.324351] [c0168801] ? lock_set_class+0x4be/0x511 [3.324378] [c03c75b4] intel_modeset_check_state+0x30c/0x55f [3.324389] [c03c7882] intel_set_mode+0x26/0x2f [3.324399] [c03c8619] intel_get_load_detect_pipe+0x2b4/0x308 [3.324412] [c03e11d8] intel_tv_detect+0xd1/0x3ea [3.324431] [c038a00e] drm_helper_probe_single_connector_modes+0xa0/0x270 [3.324441] [c0387bf2] drm_fb_helper_probe_connector_modes+0x39/0x4c [3.324452] [c03890d7] drm_fb_helper_initial_config+0x143/0x3ac [3.324462] [c0533df8] ? _raw_spin_unlock_irqrestore+0x38/0x5b [3.324471] [c0533e04] ? _raw_spin_unlock_irqrestore+0x44/0x5b [3.324482] [c0533e04] ? _raw_spin_unlock_irqrestore+0x44/0x5b [3.324491] [c03e051a] intel_fbdev_initial_config+0x1e/0x20 [3.324502] [c03a3ae4] i915_driver_load+0xa1c/0xbfe [3.324516] [c0393d9a] drm_get_pci_dev+0x13a/0x21a [3.324525] [c0533e04] ? _raw_spin_unlock_irqrestore+0x44/0x5b [3.324535] [c03a0268] i915_pci_probe+0x46/0x4f [3.324547] [c0301011] pci_device_probe+0x5e/0x96 [3.324557] [c03f704d] driver_probe_device+0x83/0x17a [3.324566] [c03f7197] __driver_attach+0x53/0x6f [3.324577] [c03f5b3a] bus_for_each_dev+0x43/0x6d [3.324586] [c03f6c8b] driver_attach+0x19/0x1b [3.324595] [c03f7144] ? driver_probe_device+0x17a/0x17a [3.324603] [c03f6914] bus_add_driver+0xc3/0x1c0 [3.324613] [c03f766c] driver_register+0x79/0xf1 [3.324623] [c02f42e4] ? __raw_spin_lock_init+0x26/0x49 [3.324633] [c03010f4] __pci_register_driver+0x4a/0x4d [3.324645] [c07e9584] ? ftrace_define_fields_drm_vblank_event+0x45/0x45 [3.324654] [c0393ee7] drm_pci_init+0x6d/0xc5 [3.324663] [c07e9584] ? ftrace_define_fields_drm_vblank_event+0x45/0x45 [3.324672] [c07e95e2] i915_init+0x5e/0x60 [3.324682] [c01003b5] do_one_initcall+0x6f/0xea [3.324691] [c07c0428] ? repair_env_string+0x12/0x51 [3.324700] [c07c0400] ? do_early_param+0x5f/0x75 [3.324709] [c01436e9] ? parse_args+0x175/0x213 [3.324721] [c07c09c2] kernel_init_freeable+0xce/0x153 [3.324730] [c052876e] kernel_init+0xd/0xb9 [3.324740] [c05394b7] ret_from_kernel_thread+0x1b/0x28 [3.324749] [c0528761] ? rest_init+0xa5/0xa5 [3.324927] ---[ end trace cdf7452bb4a6b6eb ]--- [3.477035] fbcon: inteldrmfb (fb0) is primary device [3.579446] Console: switching to colour frame buffer device 160x64 [3.593142] i915 :00:02.0: fb0: inteldrmfb frame buffer device [3.593150] i915 :00:02.0: registered panic notifier [3.593213] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [Regression 3.10.0+] i915: pipe state does not match!
___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/14] drm/i915: unify GT/PM irq postinstall code
On Wed, Jul 10, 2013 at 10:48 PM, Paulo Zanoni przan...@gmail.com wrote: Which means we're now initializing GEN6_PM* code on SNB, which seems good. You might want to dedicate a paragraph for this on the commit message. On the IRQ patches I wrote (but did not sent yet) I unified the ILK/SNB irq_handler vfuncs with IVB/HSW ones. I guess bugs like the one you've just fixed here and in the previous patch are a good way to justify my patches :) I think we have a language communication fail going on here in these few patches. With unify I don't mean extract identical code, simple refactoring with no functional change but make them work the same way since currently they don't. Note that with the exception of the gt_irq_mask initialization on vlv there's no bugfix in here: PM interrupte setup simply works differently on snb/vlv than on ivb/hsw after Ben's VECS enabling patches. What these few patches here try to do is unify the sequences again so all platforms set up the PM registers the same way. Note that the PMIER update in gen6_enable_rps isn't a bugfix either: The interrupt handler doesn't touch this register. The only other place is the hsw vecs interrupt setup in the ivybridge irq vfuncs, but those two codepaths can never run in parrallel due to init/teardown sequence ordering (even though that gen6_enable_rps runs from a work item). I've read through the commit message again and for me it seems to be clear what's going on (but I'm obviously biased). So again, do you have ideas for improvements? Wrt patch splitting I'm not sure whether it's worth it, since the current code is simply a bit a confusing mess imo. -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 13/14] drm/i915: extract rps interrupt enable/disable helpers
On Wed, Jul 10, 2013 at 06:12:13PM -0300, Paulo Zanoni wrote:
2013/7/4 Daniel Vetter daniel.vet...@ffwll.ch:
This just unifies the vlv code with the snb-hsw code which matched
exactly before the VECS enabling.
So now the VLV code is behaving differently. Is that intentional? You
could write about the implications here.
It's just for consistency that we now also reset GEN6_PMINTRMSK for vlv
and that the additional clearing of the rps event bits in PMIIR now
consistently happens in enable_interrupts. Like I've said in the next
commit message, the PMIIR handling here still smells a bit funny - as long
as we properly clear them at irq install time and keep the actual rps
events masked we should never see PMIIR bits here.
-Daniel
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 59
-
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 96f0872..787a528 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3121,13 +3121,10 @@ void valleyview_set_rps(struct drm_device *dev, u8
val)
trace_intel_gpu_freq_change(vlv_gpu_freq(dev_priv-mem_freq, val));
}
-
-static void gen6_disable_rps(struct drm_device *dev)
+static void gen6_disable_rps_interrupts(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- I915_WRITE(GEN6_RC_CONTROL, 0);
- I915_WRITE(GEN6_RPNSWREQ, 1 31);
I915_WRITE(GEN6_PMINTRMSK, 0x);
I915_WRITE(GEN6_PMIER, I915_READ(GEN6_PMIER) ~GEN6_PM_RPS_EVENTS);
/* Complete PM interrupt masking here doesn't race with the rps work
@@ -3142,23 +3139,23 @@ static void gen6_disable_rps(struct drm_device *dev)
I915_WRITE(GEN6_PMIIR, GEN6_PM_RPS_EVENTS);
}
-static void valleyview_disable_rps(struct drm_device *dev)
+static void gen6_disable_rps(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
I915_WRITE(GEN6_RC_CONTROL, 0);
- I915_WRITE(GEN6_PMINTRMSK, 0x);
- I915_WRITE(GEN6_PMIER, 0);
- /* Complete PM interrupt masking here doesn't race with the rps work
-* item again unmasking PM interrupts because that is using a
different
-* register (PMIMR) to mask PM interrupts. The only risk is in
leaving
-* stale bits in PMIIR and PMIMR which gen6_enable_rps will clean
up. */
+ I915_WRITE(GEN6_RPNSWREQ, 1 31);
- spin_lock_irq(dev_priv-irq_lock);
- dev_priv-rps.pm_iir = 0;
- spin_unlock_irq(dev_priv-irq_lock);
+ gen6_disable_rps_interrupts(dev);
+}
+
+static void valleyview_disable_rps(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ I915_WRITE(GEN6_RC_CONTROL, 0);
- I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
+ gen6_disable_rps_interrupts(dev);
if (dev_priv-vlv_pctx) {
drm_gem_object_unreference(dev_priv-vlv_pctx-base);
@@ -3191,6 +3188,21 @@ int intel_enable_rc6(const struct drm_device *dev)
return (INTEL_RC6_ENABLE | INTEL_RC6p_ENABLE);
}
+static void gen6_enable_rps_interrupts(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ spin_lock_irq(dev_priv-irq_lock);
+ /* FIXME: Our interrupt enabling sequence is bonghits.
+* dev_priv-rps.pm_iir really should be 0 here. */
+ dev_priv-rps.pm_iir = 0;
+ I915_WRITE(GEN6_PMIMR, I915_READ(GEN6_PMIMR) ~GEN6_PM_RPS_EVENTS);
+ I915_WRITE(GEN6_PMIIR, GEN6_PM_RPS_EVENTS);
+ spin_unlock_irq(dev_priv-irq_lock);
+ /* unmask all PM interrupts */
+ I915_WRITE(GEN6_PMINTRMSK, 0);
+}
+
static void gen6_enable_rps(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -3319,15 +3331,7 @@ static void gen6_enable_rps(struct drm_device *dev)
gen6_set_rps(dev_priv-dev, (gt_perf_status 0xff00) 8);
- spin_lock_irq(dev_priv-irq_lock);
- /* FIXME: Our interrupt enabling sequence is bonghits.
-* dev_priv-rps.pm_iir really should be 0 here. */
- dev_priv-rps.pm_iir = 0;
- I915_WRITE(GEN6_PMIMR, I915_READ(GEN6_PMIMR) ~GEN6_PM_RPS_EVENTS);
- I915_WRITE(GEN6_PMIIR, GEN6_PM_RPS_EVENTS);
- spin_unlock_irq(dev_priv-irq_lock);
- /* unmask all PM interrupts */
- I915_WRITE(GEN6_PMINTRMSK, 0);
+ gen6_enable_rps_interrupts(dev);
rc6vids = 0;
ret = sandybridge_pcode_read(dev_priv, GEN6_PCODE_READ_RC6VIDS,
rc6vids);
@@ -3597,12 +3601,7 @@ static void valleyview_enable_rps(struct drm_device
*dev)
valleyview_set_rps(dev_priv-dev,
Re: [Intel-gfx] [Regression 3.10.0+] i915: pipe state does not match!
On Thu, Jul 11, 2013 at 8:11 AM, Knut Petersen knut_peter...@t-online.de wrote: Hi everybody! During booting a pipe state doesn't match error occures. Reproducibility: high (3 of 3 test boots) Hardware: Aopen i915GMm-hfs, Pentium-M, opensuse 12.3, kernel 3.10.0+, git 496322bc91e35007ed754184dcd447a02b6dd685 trace attached. Can you please boot with drm.debug=0xe added to your kernel cmdline and the attach the complete dmesg? 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
[Intel-gfx] [Regression 3.10.0+] i915 resume problem: pipe state doesn't match!
Hi everybody! During resume from S3 there is a pipe state problem Reproducibility: high (3 of 3 test resumes) Hardware: Aopen i915GMm-hfs, Pentium-M, opensuse 12.3, kernel 3.10.0+, git 496322bc91e35007ed754184dcd447a02b6dd685 Three slightly differing trace attached. cu, Knut [ 99.485475] [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.control (expected 0, found 8) [ 99.485490] [ cut here ] [ 99.485516] WARNING: CPU: 0 PID: 1276 at drivers/gpu/drm/i915/intel_display.c:8287 check_crtc_state+0x62b/0x65c() [ 99.485526] pipe state doesn't match! [ 99.485535] Modules linked in: ipv6 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_rme96 snd_pcm snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc [ 99.485610] CPU: 0 PID: 1276 Comm: kworker/0:6 Tainted: GW 3.10.0-main+ #14 [ 99.485622] Hardware name:/i915GMm-HFS, BIOS 6.00 PG 11/04/2005 [ 99.485640] Workqueue: events output_poll_execute [ 99.485653] 0006 c06f10ea efded9cc c052e356 efded9e4 c012a137 c03bde50 f60e3000 [ 99.485694] f6218000 efded9fc c012a1c1 0009 efded9f4 c06f10ea efdeda10 [ 99.485736] efdedc60 c03bde50 c06f047a 205f c06f10ea efdeda01 c0533e4d f635af44 [ 99.485777] Call Trace: [ 99.485802] [c052e356] dump_stack+0x16/0x18 [ 99.485823] [c012a137] warn_slowpath_common+0x5a/0x71 [ 99.485842] [c03bde50] ? check_crtc_state+0x62b/0x65c [ 99.485862] [c012a1c1] warn_slowpath_fmt+0x2b/0x2f [ 99.485881] [c03bde50] check_crtc_state+0x62b/0x65c [ 99.485902] [c0533e4d] ? _raw_spin_unlock_irq+0x32/0x48 [ 99.485956] [c03c75b4] intel_modeset_check_state+0x30c/0x55f [ 99.485979] [c03c7882] intel_set_mode+0x26/0x2f [ 99.485999] [c03c8619] intel_get_load_detect_pipe+0x2b4/0x308 [ 99.486021] [c0531be1] ? __mutex_unlock_slowpath+0xf4/0x111 [ 99.486044] [c0168a50] ? trace_hardirqs_on_caller+0x12e/0x180 [ 99.486063] [c0168aad] ? trace_hardirqs_on+0xb/0xd [ 99.486084] [c03e11d8] intel_tv_detect+0xd1/0x3ea [ 99.486118] [c038a00e] drm_helper_probe_single_connector_modes+0xa0/0x270 [ 99.486140] [c0387bf2] drm_fb_helper_probe_connector_modes+0x39/0x4c [ 99.486158] [c0531ad2] ? mutex_lock_nested+0x27d/0x298 [ 99.486179] [c03893a4] drm_fb_helper_hotplug_event+0x64/0x9a [ 99.486199] [c03e0641] intel_fb_output_poll_changed+0x19/0x1b [ 99.486218] [c0389871] drm_kms_helper_hotplug_event+0x21/0x24 [ 99.486237] [c0389989] output_poll_execute+0x115/0x139 [ 99.486260] [c01402e0] process_one_work+0x22a/0x3ec [ 99.486279] [c01409b4] ? worker_thread+0x2c/0x28a [ 99.486301] [c0140b2b] worker_thread+0x1a3/0x28a [ 99.486322] [c0140988] ? manage_workers.isra.22+0x19a/0x19a [ 99.486341] [c0144df9] kthread+0x8e/0x93 [ 99.486368] [c05394b7] ret_from_kernel_thread+0x1b/0x28 [ 99.486387] [c0144d6b] ? __init_kthread_worker+0x47/0x47 [ 99.486402] ---[ end trace b2b34c622ca1d660 ]--- [ 1295.520126] PM: Basic memory bitmaps freed [ 1298.525937] [drm:intel_pipe_config_compare] *ERROR* mismatch in gmch_pfit.control (expected 0, found 8) [ 1298.525952] [ cut here ] [ 1298.525977] WARNING: CPU: 0 PID: 1308 at drivers/gpu/drm/i915/intel_display.c:8287 check_crtc_state+0x62b/0x65c() [ 1298.525987] pipe state doesn't match! [ 1298.525996] Modules linked in: ipv6 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_rme96 snd_pcm snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc [ 1298.526072] CPU: 0 PID: 1308 Comm: kworker/0:2 Tainted: GW 3.10.0-main+ #14 [ 1298.526084] Hardware name:/i915GMm-HFS, BIOS 6.00 PG 11/04/2005 [ 1298.526102] Workqueue: events output_poll_execute [ 1298.526115] 0006 c06f10ea f5a279cc c052e356 f5a279e4 c012a137 c03bde50 f60e3000 [ 1298.526157] f6218000 f5a279fc c012a1c1 0009 f5a279f4 c06f10ea f5a27a10 [ 1298.526199] f5a27c60 c03bde50 c06f047a 205f c06f10ea f5a27a01 0101 f635af44 [ 1298.526241] Call Trace: [ 1298.526267] [c052e356] dump_stack+0x16/0x18 [ 1298.526288] [c012a137] warn_slowpath_common+0x5a/0x71 [ 1298.526306] [c03bde50] ? check_crtc_state+0x62b/0x65c [ 1298.526326] [c012a1c1] warn_slowpath_fmt+0x2b/0x2f [ 1298.526345] [c03bde50] check_crtc_state+0x62b/0x65c [ 1298.526368] [c0130524] ? __do_softirq+0x165/0x207 [ 1298.526422] [c03c75b4] intel_modeset_check_state+0x30c/0x55f [ 1298.526444] [c03c7882] intel_set_mode+0x26/0x2f [ 1298.526464] [c03c8619] intel_get_load_detect_pipe+0x2b4/0x308 [ 1298.526487] [c0531be1] ? __mutex_unlock_slowpath+0xf4/0x111 [ 1298.526509] [c0168a50] ? trace_hardirqs_on_caller+0x12e/0x180 [ 1298.526529] [c0168aad] ? trace_hardirqs_on+0xb/0xd [ 1298.526550] [c03e11d8] intel_tv_detect+0xd1/0x3ea [ 1298.526584] [c038a00e] drm_helper_probe_single_connector_modes+0xa0/0x270 [ 1298.526606] [c0387bf2] drm_fb_helper_probe_connector_modes+0x39/0x4c [ 1298.526624] [c0531ad2] ? mutex_lock_nested+0x27d/0x298 [ 1298.526645] [c03893a4]
[Intel-gfx] [PATCH] drm/i915: Decrease pll-refcount when freeze gpu
display.crtc_mode_set will increase pll-refcount, but no one will
decrease pll-refcount when freeze gpu. So when gpu resume from freeze,
pll-refcount is still larger than zero. This is abnormal
Without this patch, connecting vga screen on Haswell platform, there
are following results:
1. when resume S3, call trace exist in intel_ddi_put_crtc_pll()
2. when resume s4, vga monitor is black. because intel_ddi_pll_mode_set()
return false and haswell_crtc_mode_set() exit without setting mode
With this patch, I don't find S3 and S4 regression on SandyBridge
and IvyBridge platform connecting VGA, HDMI and DP screen.
Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0485f43..0065735 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -575,8 +575,10 @@ static int i915_drm_freeze(struct drm_device *dev)
* Disable CRTCs directly since we want to preserve sw state
* for _thaw.
*/
- list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
dev_priv-display.crtc_disable(crtc);
+ dev_priv-display.off(crtc);
+ }
intel_modeset_suspend_hw(dev);
}
--
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 01/11] drm/i915: Move gtt and ppgtt under address space umbrella
On Mon, 2013-07-08 at 23:08 -0700, Ben Widawsky wrote:
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions (insert entries), state (LRU lists) and
many of their characteristics (size), can be shared. Do that.
The change itself doesn't actually impact most of the VMA/VM rework
coming up, it just fits in with the grand scheme. GGTT will usually be a
special case where we either know an object must be in the GGTT (dislay
engine, workarounds, etc.).
v2: Drop usage of i915_gtt_vm (Daniel)
Make cleanup also part of the parent class (Ben)
Modified commit msg
Rebased
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_dma.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 57 ++---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 162
5 files changed, 121 insertions(+), 110 deletions(-)
[...]
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 242d0f9..693115a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -102,7 +102,7 @@ static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
static void gen6_write_pdes(struct i915_hw_ppgtt *ppgtt)
{
- struct drm_i915_private *dev_priv = ppgtt-dev-dev_private;
+ struct drm_i915_private *dev_priv = ppgtt-base.dev-dev_private;
gen6_gtt_pte_t __iomem *pd_addr;
uint32_t pd_entry;
int i;
@@ -181,18 +181,18 @@ static int gen6_ppgtt_enable(struct drm_device *dev)
}
/* PPGTT support for Sandybdrige/Gen6 and later */
-static void gen6_ppgtt_clear_range(struct i915_hw_ppgtt *ppgtt,
+static void gen6_ppgtt_clear_range(struct i915_address_space *vm,
unsigned first_entry,
unsigned num_entries)
{
- struct drm_i915_private *dev_priv = ppgtt-dev-dev_private;
+ struct i915_hw_ppgtt *ppgtt =
+ container_of(vm, struct i915_hw_ppgtt, base);
gen6_gtt_pte_t *pt_vaddr, scratch_pte;
unsigned act_pt = first_entry / I915_PPGTT_PT_ENTRIES;
unsigned first_pte = first_entry % I915_PPGTT_PT_ENTRIES;
unsigned last_pte, i;
- scratch_pte = ppgtt-pte_encode(dev_priv-gtt.scratch.addr,
- I915_CACHE_LLC);
+ scratch_pte = vm-pte_encode(vm-scratch.addr, I915_CACHE_LLC);
I only see ggtt's scratch page being initialized, but can't find the
corresponding init/teardown for ppgtt. Btw, why do we need separate
global/per-process scratch pages? (would be nice to add it to the commit
message)
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Create VMAs
On Mon, 2013-07-08 at 23:08 -0700, Ben Widawsky wrote:
Formerly: drm/i915: Create VMAs (part 1)
In a previous patch, the notion of a VM was introduced. A VMA describes
an area of part of the VM address space. A VMA is similar to the concept
in the linux mm. However, instead of representing regular memory, a VMA
is backed by a GEM BO. There may be many VMAs for a given object, one
for each VM the object is to be used in. This may occur through flink,
dma-buf, or a number of other transient states.
Currently the code depends on only 1 VMA per object, for the global GTT
(and aliasing PPGTT). The following patches will address this and make
the rest of the infrastructure more suited
v2: s/i915_obj/i915_gem_obj (Chris)
v3: Only move an object to the now global unbound list if there are no
more VMAs for the object which are bound into a VM (ie. the list is
empty).
v4: killed obj-gtt_space
some reworks due to rebase
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h| 48 ++--
drivers/gpu/drm/i915/i915_gem.c| 57
+-
drivers/gpu/drm/i915/i915_gem_evict.c | 12 ---
drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 14 ++---
5 files changed, 110 insertions(+), 26 deletions(-)
[...]
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 525aa8f..058ad44 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2578,6 +2578,7 @@ int
i915_gem_object_unbind(struct drm_i915_gem_object *obj)
{
drm_i915_private_t *dev_priv = obj-base.dev-dev_private;
+ struct i915_vma *vma;
int ret;
if (!i915_gem_obj_ggtt_bound(obj))
@@ -2615,11 +2616,20 @@ i915_gem_object_unbind(struct drm_i915_gem_object
*obj)
i915_gem_object_unpin_pages(obj);
list_del(obj-mm_list);
- list_move_tail(obj-global_list, dev_priv-mm.unbound_list);
/* Avoid an unnecessary call to unbind on rebind. */
obj-map_and_fenceable = true;
- drm_mm_remove_node(obj-gtt_space);
+ vma = __i915_gem_obj_to_vma(obj);
+ list_del(vma-vma_link);
+ drm_mm_remove_node(vma-node);
+ i915_gem_vma_destroy(vma);
+
+ /* Since the unbound list is global, only move to that list if
+ * no more VMAs exist.
+ * NB: Until we have real VMAs there will only ever be one */
+ WARN_ON(!list_empty(obj-vma_list));
+ if (list_empty(obj-vma_list))
+ list_move_tail(obj-global_list, dev_priv-mm.unbound_list);
return 0;
}
@@ -3070,8 +3080,12 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object
*obj,
bool mappable, fenceable;
size_t gtt_max = map_and_fenceable ?
dev_priv-gtt.mappable_end : dev_priv-gtt.base.total;
+ struct i915_vma *vma;
int ret;
+ if (WARN_ON(!list_empty(obj-vma_list)))
+ return -EBUSY;
+
fence_size = i915_gem_get_gtt_size(dev,
obj-base.size,
obj-tiling_mode);
@@ -3110,9 +3124,15 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object
*obj,
i915_gem_object_pin_pages(obj);
+ vma = i915_gem_vma_create(obj, dev_priv-gtt.base);
+ if (vma == NULL) {
+ i915_gem_object_unpin_pages(obj);
+ return -ENOMEM;
+ }
+
search_free:
ret = drm_mm_insert_node_in_range_generic(dev_priv-gtt.base.mm,
- obj-gtt_space,
+ vma-node,
size, alignment,
obj-cache_level, 0, gtt_max);
if (ret) {
@@ -3126,22 +3146,23 @@ search_free:
i915_gem_object_unpin_pages(obj);
return ret;
}
- if (WARN_ON(!i915_gem_valid_gtt_space(dev, obj-gtt_space,
+ if (WARN_ON(!i915_gem_valid_gtt_space(dev, vma-node,
obj-cache_level))) {
i915_gem_object_unpin_pages(obj);
- drm_mm_remove_node(obj-gtt_space);
+ drm_mm_remove_node(vma-node);
return -EINVAL;
}
ret = i915_gem_gtt_prepare_object(obj);
if (ret) {
i915_gem_object_unpin_pages(obj);
- drm_mm_remove_node(obj-gtt_space);
+ drm_mm_remove_node(vma-node);
return ret;
}
Freeing vma on the error path is missing.
With this and the issue in 1/5 addressed things look good to me, so on
1-5:
Reviewed-by: Imre Deak imre.d...@intel.com
--Imre
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] [PATCH] drm/i915: fix up readout of the lvds dither bit on gen2/3
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.
Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
output and we've left the dither bit enabled behind us. This can
happen if the BIOS has set the bit (some seem to unconditionally do
that, even in the complete absence of an lvds port), but not enabled
pipe B at boot-up. Then we won't clear the pfit control register since
we can only touch that if the pfit is associated with our pipe in the
crtc configuration - we could trample over the pfit state of the other
pipe otherwise since it's shared. Once pipe B is enabled we notice
that the 6to8 dither bit is set and complain about the mismatch.
Note that testing indicates that we don't actually need to set this
bit when the pfit is disabled, dithering on 18bpp panels seems to work
regardless. But ripping that code out is not something for a bugfix
meant for -rc kernels.
v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
comments from Chris on irc.
v3: Use Chris suggestion to make the control flow in
i9xx_get_pfit_config easier to understand.
Reported-by: Knut Petersen knut_peter...@t-online.de
Cc: Knut Petersen knut_peter...@t-online.de
Cc: Chris Wilson ch...@chris-wilson.co.uk
References:
http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 12 +---
drivers/gpu/drm/i915/intel_lvds.c| 7 +++
2 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 85f3eb7..1ccc468 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4913,22 +4913,20 @@ static void i9xx_get_pfit_config(struct intel_crtc
*crtc,
uint32_t tmp;
tmp = I915_READ(PFIT_CONTROL);
+ if (!(tmp PFIT_ENABLE))
+ return;
+
+ /* Check whether the pfit is attached to our pipe. */
if (INTEL_INFO(dev)-gen 4) {
if (crtc-pipe != PIPE_B)
return;
-
- /* gen2/3 store dither state in pfit control, needs to match */
- pipe_config-gmch_pfit.control = tmp PANEL_8TO6_DITHER_ENABLE;
} else {
if ((tmp PFIT_PIPE_MASK) != (crtc-pipe PFIT_PIPE_SHIFT))
return;
}
- if (!(tmp PFIT_ENABLE))
- return;
-
- pipe_config-gmch_pfit.control = I915_READ(PFIT_CONTROL);
+ pipe_config-gmch_pfit.control = tmp;
pipe_config-gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
if (INTEL_INFO(dev)-gen 5)
pipe_config-gmch_pfit.lvds_border_bits =
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 2abb2d3..1207998 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -109,6 +109,13 @@ static void intel_lvds_get_config(struct intel_encoder
*encoder,
flags |= DRM_MODE_FLAG_PVSYNC;
pipe_config-adjusted_mode.flags |= flags;
+
+ /* gen2/3 store dither state in pfit control, needs to match */
+ if (INTEL_INFO(dev)-gen 4) {
+ tmp = I915_READ(PFIT_CONTROL);
+
+ pipe_config-gmch_pfit.control |= tmp
PANEL_8TO6_DITHER_ENABLE;
+ }
}
/* The LVDS pin pair needs to be on before the DPLLs are enabled.
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix up readout of the lvds dither bit on gen2/3
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.
Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
output and we've left the dither bit enabled behind us. This can
happen if the BIOS has set the bit (some seem to unconditionally do
that, even in the complete absence of an lvds port), but not enabled
pipe B at boot-up. Then we won't clear the pfit control register since
we can only touch that if the pfit is associated with our pipe in the
crtc configuration - we could trample over the pfit state of the other
pipe otherwise since it's shared. Once pipe B is enabled we notice
that the 6to8 dither bit is set and complain about the mismatch.
Note that testing indicates that we don't actually need to set this
bit when the pfit is disabled, dithering on 18bpp panels seems to work
regardless. But ripping that code out is not something for a bugfix
meant for -rc kernels.
v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
comments from Chris on irc.
v3: Use Chris suggestion to make the control flow in
i9xx_get_pfit_config easier to understand.
v4: Kill the extra line, spotted by Chris.
Reported-by: Knut Petersen knut_peter...@t-online.de
Cc: Knut Petersen knut_peter...@t-online.de
Cc: Chris Wilson ch...@chris-wilson.co.uk
References:
http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
drivers/gpu/drm/i915/intel_lvds.c| 7 +++
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 85f3eb7..c59335c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4913,22 +4913,19 @@ static void i9xx_get_pfit_config(struct intel_crtc
*crtc,
uint32_t tmp;
tmp = I915_READ(PFIT_CONTROL);
+ if (!(tmp PFIT_ENABLE))
+ return;
+ /* Check whether the pfit is attached to our pipe. */
if (INTEL_INFO(dev)-gen 4) {
if (crtc-pipe != PIPE_B)
return;
-
- /* gen2/3 store dither state in pfit control, needs to match */
- pipe_config-gmch_pfit.control = tmp PANEL_8TO6_DITHER_ENABLE;
} else {
if ((tmp PFIT_PIPE_MASK) != (crtc-pipe PFIT_PIPE_SHIFT))
return;
}
- if (!(tmp PFIT_ENABLE))
- return;
-
- pipe_config-gmch_pfit.control = I915_READ(PFIT_CONTROL);
+ pipe_config-gmch_pfit.control = tmp;
pipe_config-gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
if (INTEL_INFO(dev)-gen 5)
pipe_config-gmch_pfit.lvds_border_bits =
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 2abb2d3..1207998 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -109,6 +109,13 @@ static void intel_lvds_get_config(struct intel_encoder
*encoder,
flags |= DRM_MODE_FLAG_PVSYNC;
pipe_config-adjusted_mode.flags |= flags;
+
+ /* gen2/3 store dither state in pfit control, needs to match */
+ if (INTEL_INFO(dev)-gen 4) {
+ tmp = I915_READ(PFIT_CONTROL);
+
+ pipe_config-gmch_pfit.control |= tmp
PANEL_8TO6_DITHER_ENABLE;
+ }
}
/* The LVDS pin pair needs to be on before the DPLLs are enabled.
--
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: fix up readout of the lvds dither bit on gen2/3
On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote: It's in the PFIT_CONTROL register, but very much associated with the lvds encoder. So move the readout for it (in the case of an otherwise disabled pfit) from the pipe to the lvds encoder's get_config function. Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds output and we've left the dither bit enabled behind us. This can happen if the BIOS has set the bit (some seem to unconditionally do that, even in the complete absence of an lvds port), but not enabled pipe B at boot-up. Then we won't clear the pfit control register since we can only touch that if the pfit is associated with our pipe in the crtc configuration - we could trample over the pfit state of the other pipe otherwise since it's shared. Once pipe B is enabled we notice that the 6to8 dither bit is set and complain about the mismatch. Note that testing indicates that we don't actually need to set this bit when the pfit is disabled, dithering on 18bpp panels seems to work regardless. But ripping that code out is not something for a bugfix meant for -rc kernels. v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by comments from Chris on irc. v3: Use Chris suggestion to make the control flow in i9xx_get_pfit_config easier to understand. v4: Kill the extra line, spotted by Chris. Reported-by: Knut Petersen knut_peter...@t-online.de Cc: Knut Petersen knut_peter...@t-online.de Cc: Chris Wilson ch...@chris-wilson.co.uk References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch 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: fix up readout of the lvds dither bit on gen2/3
Hi Knut,
When you test this patch please grab a dmesg with drm.debug=0xe
regardless of outcome, I'd like to check a few other odd things with
your system (which seem to not be directly related to the issue at
hand).
Thanks, Daniel
On Thu, Jul 11, 2013 at 1:35 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
It's in the PFIT_CONTROL register, but very much associated with the
lvds encoder. So move the readout for it (in the case of an otherwise
disabled pfit) from the pipe to the lvds encoder's get_config
function.
Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds
output and we've left the dither bit enabled behind us. This can
happen if the BIOS has set the bit (some seem to unconditionally do
that, even in the complete absence of an lvds port), but not enabled
pipe B at boot-up. Then we won't clear the pfit control register since
we can only touch that if the pfit is associated with our pipe in the
crtc configuration - we could trample over the pfit state of the other
pipe otherwise since it's shared. Once pipe B is enabled we notice
that the 6to8 dither bit is set and complain about the mismatch.
Note that testing indicates that we don't actually need to set this
bit when the pfit is disabled, dithering on 18bpp panels seems to work
regardless. But ripping that code out is not something for a bugfix
meant for -rc kernels.
v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by
comments from Chris on irc.
v3: Use Chris suggestion to make the control flow in
i9xx_get_pfit_config easier to understand.
v4: Kill the extra line, spotted by Chris.
Reported-by: Knut Petersen knut_peter...@t-online.de
Cc: Knut Petersen knut_peter...@t-online.de
Cc: Chris Wilson ch...@chris-wilson.co.uk
References:
http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
drivers/gpu/drm/i915/intel_lvds.c| 7 +++
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 85f3eb7..c59335c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4913,22 +4913,19 @@ static void i9xx_get_pfit_config(struct intel_crtc
*crtc,
uint32_t tmp;
tmp = I915_READ(PFIT_CONTROL);
+ if (!(tmp PFIT_ENABLE))
+ return;
+ /* Check whether the pfit is attached to our pipe. */
if (INTEL_INFO(dev)-gen 4) {
if (crtc-pipe != PIPE_B)
return;
-
- /* gen2/3 store dither state in pfit control, needs to match
*/
- pipe_config-gmch_pfit.control = tmp
PANEL_8TO6_DITHER_ENABLE;
} else {
if ((tmp PFIT_PIPE_MASK) != (crtc-pipe PFIT_PIPE_SHIFT))
return;
}
- if (!(tmp PFIT_ENABLE))
- return;
-
- pipe_config-gmch_pfit.control = I915_READ(PFIT_CONTROL);
+ pipe_config-gmch_pfit.control = tmp;
pipe_config-gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
if (INTEL_INFO(dev)-gen 5)
pipe_config-gmch_pfit.lvds_border_bits =
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 2abb2d3..1207998 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -109,6 +109,13 @@ static void intel_lvds_get_config(struct intel_encoder
*encoder,
flags |= DRM_MODE_FLAG_PVSYNC;
pipe_config-adjusted_mode.flags |= flags;
+
+ /* gen2/3 store dither state in pfit control, needs to match */
+ if (INTEL_INFO(dev)-gen 4) {
+ tmp = I915_READ(PFIT_CONTROL);
+
+ pipe_config-gmch_pfit.control |= tmp
PANEL_8TO6_DITHER_ENABLE;
+ }
}
/* The LVDS pin pair needs to be on before the DPLLs are enabled.
--
1.8.1.4
--
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] [PULL] drm-intel-fixes
Cc lists this time around ... -Daniel On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter dan...@ffwll.ch wrote: Hi Dave, One feature latecomer, I've forgotten to merge the patch to reeanble the Haswell power well feature now that the audio interaction is fixed up. Since that was the only unfixed issue with it I've figured I could throw it in a bit late, and it's trivial to revert in case I'm wrong. Otherwise all bug/regression fixes: - Fix status page reinit after gpu hangs, spotted by more paranoid igt checks. - Fix object list walking fumble regression in the shrinker (only the counting part, the actual shrinking code was correct so no Oops potential), from Xiong Zhang. - Fix DP 1.2 bw limits (Imre). - Restore legacy forcewake on ivb, too many broken biosen out there. We dump a warn though that recent userspace might fall over with that config (Guenter Roeck). - Patch up the gen2 cs tlb w/a. - Improve the fence coherency w/a now that we have a better understanding what's going on. The removed wbinvd+ipi should make -rt folks happy. Big thanks to Jon Bloomfield for figuring this out, patches from Chris. - Fix write-read race when switching ring (Chris). Spotted with code inspection, but now we also have an igt for it. There's an ugly regression we're still working on introduced between 3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since that one fixes another regression :( I've asked Steven to include my -fixes branch into linux-next to prevent such fallout in the future, hopefully. Otherwise pretty calm thus far. Cheers, Daniel The following changes since commit 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e: drm/i915: Don't try to tear down the stolen drm_mm if it's not there (2013-07-02 11:47:19 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-07-11 for you to fetch changes up to 46a0b638f35b45fc13d3dc0deb6a7e17988170b2: Revert drm/i915: Workaround incoherence between fences and LLC across multiple CPUs (2013-07-10 15:31:12 +0200) Chris Wilson (3): drm/i915: Fix write-read race with multiple rings drm/i915: Fix incoherence with fence updates on Sandybridge+ Revert drm/i915: Workaround incoherence between fences and LLC across multiple CPUs Daniel Vetter (2): drm/i915: reinit status page registers after gpu reset drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a Guenter Roeck (1): Partially revert drm/i915: unconditionally use mt forcewake on hsw/ivb Imre Deak (1): drm/i915: fix lane bandwidth capping for DP 1.2 sinks Paulo Zanoni (1): drm/i915: switch disable_power_well default value to 1 Xiong Zhang (1): drm/i915: Correct obj-mm_list link to dev_priv-dev_priv-mm.inactive_list drivers/gpu/drm/i915/i915_drv.c | 4 +- drivers/gpu/drm/i915/i915_gem.c | 83 + drivers/gpu/drm/i915/intel_dp.c | 5 ++ drivers/gpu/drm/i915/intel_pm.c | 31 +++- drivers/gpu/drm/i915/intel_ringbuffer.c | 38 +-- 5 files changed, 93 insertions(+), 68 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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 10/14] drm/i915: don't enable PM_VEBOX_CS_ERROR_INTERRUPT
On Thu, Jul 04, 2013 at 11:35:30PM +0200, Daniel Vetter wrote: The code to handle it is broken - there's simply no code to clear CS parser errors on gen5+. And behold, for all the other rings we also don't enable it! Leave the handling code itself in place just to be consistent with the existing mess though. And in case someone feels like fixing it all up. This has been errornously enabled in commit 12638c57f31952127c734c26315e1348fa1334c2 Author: Ben Widawsky b...@bwidawsk.net Date: Tue May 28 19:22:31 2013 -0700 drm/i915: Enable vebox interrupts Cc: Damien Lespiau damien.lesp...@intel.com Cc: Ben Widawsky b...@bwidawsk.net Reviewed-by: Ben Widawsky b...@bwidawsk.net Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Ok, I've merged the series up to this patch. Thanks to Ben and Paulo for the review. -Daniel --- drivers/gpu/drm/i915/i915_irq.c | 3 +-- drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 27bf7c1..910912b 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2812,8 +2812,7 @@ static int ivybridge_irq_postinstall(struct drm_device *dev) I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR)); if (HAS_VEBOX(dev)) - pm_irqs |= PM_VEBOX_USER_INTERRUPT | - PM_VEBOX_CS_ERROR_INTERRUPT; + pm_irqs |= PM_VEBOX_USER_INTERRUPT; /* Our enable/disable rps functions may touch these registers so * make sure to set a known state for only the non-RPS bits. diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 99d119c..4a0d171 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -2009,8 +2009,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev) ring-add_request = gen6_add_request; ring-get_seqno = gen6_ring_get_seqno; ring-set_seqno = ring_set_seqno; - ring-irq_enable_mask = PM_VEBOX_USER_INTERRUPT | - PM_VEBOX_CS_ERROR_INTERRUPT; + ring-irq_enable_mask = PM_VEBOX_USER_INTERRUPT; ring-irq_get = hsw_vebox_get_irq; ring-irq_put = hsw_vebox_put_irq; ring-dispatch_execbuffer = gen6_ring_dispatch_execbuffer; -- 1.8.1.4 -- 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: clean up vlv -pre_pll_enable and pll enable sequence
On Thu, 2013-06-06 at 10:22 +0200, Daniel Vetter wrote:
No need to call the -pre_pll_enable hook twice if we don't enable the
dpll too early. This should make Jani a bit less grumpy.
v2: Rebase on top of the newly-colored BUG_ONs.
Cc: Jani Nikula jani.nik...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 45
+++-
1 file changed, 18 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e43b9a..6e4d666 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1268,32 +1268,38 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
}
-static void vlv_enable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
+static void vlv_enable_pll(struct intel_crtc *crtc)
{
- int reg;
- u32 val;
+ struct drm_device *dev = crtc-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int reg = DPLL(crtc-pipe);
+ u32 dpll = crtc-config.dpll_hw_state.dpll;
- assert_pipe_disabled(dev_priv, pipe);
+ assert_pipe_disabled(dev_priv, crtc-pipe);
/* No really, not for ILK+ */
BUG_ON(!IS_VALLEYVIEW(dev_priv-dev));
/* PLL is protected by panel, make sure we can write it */
if (IS_MOBILE(dev_priv-dev) !IS_I830(dev_priv-dev))
- assert_panel_unlocked(dev_priv, pipe);
+ assert_panel_unlocked(dev_priv, crtc-pipe);
+
+ I915_WRITE(reg, dpll);
+ POSTING_READ(reg);
+ udelay(150);
+
+ if (wait_for(((I915_READ(reg) DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
+ DRM_ERROR(DPLL %d failed to lock\n, crtc-pipe);
- reg = DPLL(pipe);
- val = I915_READ(reg);
- val |= DPLL_VCO_ENABLE;
/* We do this three times for luck */
- I915_WRITE(reg, val);
+ I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150); /* wait for warmup */
- I915_WRITE(reg, val);
+ I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150); /* wait for warmup */
- I915_WRITE(reg, val);
+ I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150); /* wait for warmup */
}
@@ -3561,7 +3567,7 @@ static void valleyview_crtc_enable(struct drm_crtc
*crtc)
if (encoder-pre_pll_enable)
encoder-pre_pll_enable(encoder);
- vlv_enable_pll(dev_priv, pipe);
+ vlv_enable_pll(intel_crtc);
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder-pre_enable)
@@ -4315,7 +4321,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
{
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_encoder *encoder;
int pipe = crtc-pipe;
u32 dpll, mdiv;
u32 bestn, bestm1, bestm2, bestp1, bestp2;
@@ -4403,10 +4408,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
vlv_dpio_write(dev_priv, DPIO_PLL_CML(pipe), 0x87871000);
- for_each_encoder_on_crtc(dev, crtc-base, encoder)
- if (encoder-pre_pll_enable)
- encoder-pre_pll_enable(encoder);
-
/* Enable DPIO clock input */
dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV |
DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
@@ -4416,20 +4417,10 @@ static void vlv_update_pll(struct intel_crtc *crtc)
dpll |= DPLL_VCO_ENABLE;
crtc-config.dpll_hw_state.dpll = dpll;
- I915_WRITE(DPLL(pipe), dpll);
- POSTING_READ(DPLL(pipe));
- udelay(150);
-
- if (wait_for(((I915_READ(DPLL(pipe)) DPLL_LOCK_VLV) ==
DPLL_LOCK_VLV), 1))
- DRM_ERROR(DPLL %d failed to lock\n, pipe);
-
dpll_md = (crtc-config.pixel_multiplier - 1)
DPLL_MD_UDI_MULTIPLIER_SHIFT;
crtc-config.dpll_hw_state.dpll_md = dpll_md;
- I915_WRITE(DPLL_MD(pipe), dpll_md);
- POSTING_READ(DPLL_MD(pipe));
This piece was not added to vlv_enable_pll. Other than this patches
29-31 look ok, so on those:
Reviewed-by: Imre Deak imre.d...@intel.com
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Decrease pll-refcount when freeze gpu
On Thu, 11 Jul 2013 16:02:27 +0800
Xiong Zhang xiong.y.zh...@intel.com wrote:
display.crtc_mode_set will increase pll-refcount, but no one will
decrease pll-refcount when freeze gpu. So when gpu resume from freeze,
pll-refcount is still larger than zero. This is abnormal
Without this patch, connecting vga screen on Haswell platform, there
are following results:
1. when resume S3, call trace exist in intel_ddi_put_crtc_pll()
2. when resume s4, vga monitor is black. because intel_ddi_pll_mode_set()
return false and haswell_crtc_mode_set() exit without setting mode
With this patch, I don't find S3 and S4 regression on SandyBridge
and IvyBridge platform connecting VGA, HDMI and DP screen.
Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0485f43..0065735 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -575,8 +575,10 @@ static int i915_drm_freeze(struct drm_device *dev)
* Disable CRTCs directly since we want to preserve sw state
* for _thaw.
*/
- list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
dev_priv-display.crtc_disable(crtc);
+ dev_priv-display.off(crtc);
+ }
intel_modeset_suspend_hw(dev);
}
The comment above this call indicates we'll trash the sw state if we
call -off directly. Does suspend/resume still work both with and
without X with this patch applied? If we trash the sw state, the VT
switchless resume shouldn't work...
--
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests: Basic tools tester
Requested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
tests/Makefile.am | 1 +
tests/drm_lib.sh | 4
tests/tools_test | 20
3 files changed, 25 insertions(+)
create mode 100755 tests/tools_test
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a422899..ccc97b8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -115,6 +115,7 @@ TESTS_scripts_M = \
TESTS_scripts = \
test_rte_check \
+ tools_test \
debugfs_reader \
debugfs_emon_crash \
sysfs_l3_parity \
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index 5ca815b..5975b58 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -4,6 +4,10 @@ die() {
exit 1
}
+do_or_die() {
+ $@ /dev/null 21 || (echo FAIL: $@ ($?) exit -1)
+}
+
if [ -d /debug/dri ] ; then
debugfs_path=/debug/dri
fi
diff --git a/tests/tools_test b/tests/tools_test
new file mode 100755
index 000..bca726c
--- /dev/null
+++ b/tests/tools_test
@@ -0,0 +1,20 @@
+#!/bin/bash
+# Test some of the most critical tools we have accidentally broken before.
+# TODO: Possibly make tests parse output
+
+whoami | grep -q root || ( echo ERROR: not running as root; exit 1 )
+
+SOURCE_DIR=$( dirname ${BASH_SOURCE[0]} )
+. $SOURCE_DIR/drm_lib.sh
+
+# ARB_MODE has existed for many gens
+do_or_die $SOURCE_DIR/../tools/intel_reg_read 0x4030
+# ARB_MODE should have mask bits, so it should be safe to write
+do_or_die $SOURCE_DIR/../tools/intel_reg_write 0x4030 0
+
+do_or_die $SOURCE_DIR/../tools/intel_reg_dumper
+
+# TODO: Add more tests
+
+exit 0
+
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix up readout of the lvds dither bit on gen2/3
On Thu, Jul 11, 2013 at 06:29:15PM +0200, Knut Petersen wrote: On 11.07.2013 13:49, Chris Wilson wrote: On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote: It's in the PFIT_CONTROL register, but very much associated with the lvds encoder. So move the readout for it (in the case of an otherwise disabled pfit) from the pipe to the lvds encoder's get_config function. Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds output and we've left the dither bit enabled behind us. This can happen if the BIOS has set the bit (some seem to unconditionally do that, even in the complete absence of an lvds port), but not enabled pipe B at boot-up. Then we won't clear the pfit control register since we can only touch that if the pfit is associated with our pipe in the crtc configuration - we could trample over the pfit state of the other pipe otherwise since it's shared. Once pipe B is enabled we notice that the 6to8 dither bit is set and complain about the mismatch. Note that testing indicates that we don't actually need to set this bit when the pfit is disabled, dithering on 18bpp panels seems to work regardless. But ripping that code out is not something for a bugfix meant for -rc kernels. v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by comments from Chris on irc. v3: Use Chris suggestion to make the control flow in i9xx_get_pfit_config easier to understand. v4: Kill the extra line, spotted by Chris. Reported-by: Knut Petersen knut_peter...@t-online.de Cc: Knut Petersen knut_peter...@t-online.de Cc: Chris Wilson ch...@chris-wilson.co.uk References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris Tested-by: Knut Petersen knut_peter...@t-online.de Thanks, that patch cures both inital boot and suspend/resume problems. Attached find dmesg (inital boot) and dmesg2 (suspend/resume cycle). Thanks for testing and reporting this issue, patch is merged into my -fixes queue now. 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] drm/i915: Decrease pll-refcount when freeze gpu
On Thu, Jul 11, 2013 at 6:53 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 11 Jul 2013 16:02:27 +0800
Xiong Zhang xiong.y.zh...@intel.com wrote:
display.crtc_mode_set will increase pll-refcount, but no one will
decrease pll-refcount when freeze gpu. So when gpu resume from freeze,
pll-refcount is still larger than zero. This is abnormal
Without this patch, connecting vga screen on Haswell platform, there
are following results:
1. when resume S3, call trace exist in intel_ddi_put_crtc_pll()
2. when resume s4, vga monitor is black. because intel_ddi_pll_mode_set()
return false and haswell_crtc_mode_set() exit without setting mode
With this patch, I don't find S3 and S4 regression on SandyBridge
and IvyBridge platform connecting VGA, HDMI and DP screen.
Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 0485f43..0065735 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -575,8 +575,10 @@ static int i915_drm_freeze(struct drm_device *dev)
* Disable CRTCs directly since we want to preserve sw state
* for _thaw.
*/
- list_for_each_entry(crtc, dev-mode_config.crtc_list, head)
+ list_for_each_entry(crtc, dev-mode_config.crtc_list, head) {
dev_priv-display.crtc_disable(crtc);
+ dev_priv-display.off(crtc);
+ }
intel_modeset_suspend_hw(dev);
}
The comment above this call indicates we'll trash the sw state if we
call -off directly. Does suspend/resume still work both with and
without X with this patch applied? If we trash the sw state, the VT
switchless resume shouldn't work...
Even without that little issue: ddi refcounting issue need to be fixed
in the haswell platform code, not by papering over in the core modeset
infrastructure. We have refcounted pch plls on snb/ivb, and it works.
So imo there's no issue with the core code in the driver.
-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] tests: Basic tools tester
On Thu, Jul 11, 2013 at 09:59:46AM -0700, Ben Widawsky wrote:
Requested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
tests/Makefile.am | 1 +
tests/drm_lib.sh | 4
tests/tools_test | 20
3 files changed, 25 insertions(+)
create mode 100755 tests/tools_test
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a422899..ccc97b8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -115,6 +115,7 @@ TESTS_scripts_M = \
TESTS_scripts = \
test_rte_check \
+ tools_test \
debugfs_reader \
debugfs_emon_crash \
sysfs_l3_parity \
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index 5ca815b..5975b58 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -4,6 +4,10 @@ die() {
exit 1
}
+do_or_die() {
+ $@ /dev/null 21 || (echo FAIL: $@ ($?) exit -1)
+}
+
if [ -d /debug/dri ] ; then
debugfs_path=/debug/dri
fi
diff --git a/tests/tools_test b/tests/tools_test
new file mode 100755
index 000..bca726c
--- /dev/null
+++ b/tests/tools_test
@@ -0,0 +1,20 @@
+#!/bin/bash
+# Test some of the most critical tools we have accidentally broken before.
+# TODO: Possibly make tests parse output
+
+whoami | grep -q root || ( echo ERROR: not running as root; exit 1 )
+
+SOURCE_DIR=$( dirname ${BASH_SOURCE[0]} )
+. $SOURCE_DIR/drm_lib.sh
+
+# ARB_MODE has existed for many gens
+do_or_die $SOURCE_DIR/../tools/intel_reg_read 0x4030
+# ARB_MODE should have mask bits, so it should be safe to write
+do_or_die $SOURCE_DIR/../tools/intel_reg_write 0x4030 0
As discussed on irc there doesn't seem to be a safe register value to
test intel_reg_write accross all platforms. I'd vote to just remove it, we
can solve that little issue once it breaks for real.
Otherwise lgtm, thanks for doing this, pls push.
-Daniel
+
+do_or_die $SOURCE_DIR/../tools/intel_reg_dumper
+
+# TODO: Add more tests
+
+exit 0
+
--
1.8.3.2
___
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: Match all PSR mode entry conditions before enabling it.
On Mon, Jul 8, 2013 at 7:25 PM, Rodrigo Vivi rodrigo.v...@gmail.com wrote:
On Fri, Jul 5, 2013 at 5:32 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Jul 01, 2013 at 05:47:39PM -0300, Rodrigo Vivi wrote:
Again, Thank you very much for your comments.
Replying what I did and why I didn't here and patches coming later.
Paulo asked me to drop by maintainer bikeshed on this patch. So here I'l
comply ;-)
Mainteiner's complies are always good ;)
Thanks for jumping in this discussion
On Fri, Jun 28, 2013 at 5:46 PM, Paulo Zanoni przan...@gmail.com wrote:
2013/6/28 Rodrigo Vivi rodrigo.v...@gmail.com:
v2: Prefer seq_puts to seq_printf by Paulo Zanoni.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 ++---
drivers/gpu/drm/i915/i915_drv.h | 12 +++
drivers/gpu/drm/i915/intel_dp.c | 68
-
3 files changed, 114 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 67c777f..95b27ac 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1882,11 +1882,42 @@ static int i915_edp_psr_status(struct seq_file
*m, void *data)
struct drm_info_node *node = m-private;
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 psrctl, psrstat, psrperf;
+ u32 psrstat, psrperf;
- psrctl = I915_READ(EDP_PSR_CTL);
- seq_printf(m, PSR Enabled: %s\n,
- yesno(psrctl EDP_PSR_ENABLE));
+ if (I915_READ(EDP_PSR_CTL) EDP_PSR_ENABLE) {
+ seq_puts(m, PSR enabled\n);
+ } else {
+ seq_puts(m, PSR disabled: );
+ switch (dev_priv-no_psr_reason) {
+ case PSR_NO_SOURCE:
+ seq_puts(m, not supported on this platform);
+ break;
+ case PSR_NO_SINK:
+ seq_puts(m, not supported by panel);
+ break;
+ case PSR_CRTC_NOT_ACTIVE:
+ seq_puts(m, crtc not active);
+ break;
+ case PSR_PWR_WELL_ENABLED:
+ seq_puts(m, power well enabled);
+ break;
+ case PSR_NOT_TILED:
+ seq_puts(m, not tiled);
+ break;
+ case PSR_SPRITE_ENABLED:
+ seq_puts(m, sprite enabled);
+ break;
+ case PSR_INTERLACED_ENABLED:
+ seq_puts(m, interlaced enabled);
+ break;
+ case PSR_HSW_NOT_DDIA:
+ seq_puts(m, HSW ties PSR to DDI A (eDP));
+ break;
+ default:
+ seq_puts(m, unknown reason);
+ }
+ seq_puts(m, \n);
+ }
psrstat = I915_READ(EDP_PSR_STATUS_CTL);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 56bd82b..f08c1d9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -543,6 +543,17 @@ enum no_fbc_reason {
FBC_CHIP_DEFAULT, /* disabled by default on this chip */
};
+enum no_psr_reason {
+ PSR_NO_SOURCE, /* Not supported on platform */
+ PSR_NO_SINK, /* Not supported by panel */
+ PSR_CRTC_NOT_ACTIVE,
+ PSR_PWR_WELL_ENABLED,
+ PSR_NOT_TILED,
+ PSR_SPRITE_ENABLED,
+ PSR_INTERLACED_ENABLED,
+ PSR_HSW_NOT_DDIA,
I see you left a few reasons listed on the spec, for example S3D,
which we don't support yet. I'm pretty sure that when we implement S3D
we'll totally forget about adding the PSR_S3D_ENABLED condition, so
shouldn't we do it now? Also, why did we not add the eDP hotplug
reason?
Since it isn't implemented I'm not sure how to check that.
Maybe we will have a function, maybe just a bit in some register or
maybe somehow else.
So I prefer to stay without it until we have a proper way.
Imo adding the S3D_ENABLED reason is good, since that increases the
chances that we won'd forget about it. Maybe even add a comment in the
psr_match_conditions function below saying that we need to do this.
ok, I'll do that then.
Wrt hotplug I've just chatted a bit and it sounds like the hw doesn't like
our hpd setup for port A. I guess we should fix that up first ...
Since we don't have any known issue with psr, couldn't we just move
forward and after we get hotplug fixed we remove this workaround from
here?
Also, if we wait this we will have to say Chris and Ville finish that
rework with vblank waits you mentioned on the
[Intel-gfx] 3.10.0+ laptop resolution problem
somewhere before commit 496322b (yesterday's kernel) resolution switching on my laptop broke. The screen switches to the right resolution but the screen is not horizontally centered. The screen is aligned left and the last vertical line is repeated until the right side of the screen. Normally there would be black bars on left and right side. -- Hans lspci: ... 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) ... Screen 0: minimum 320 x 200, current 800 x 600, maximum 4096 x 4096 LVDS1 connected 800x600+0+0 (0x47) normal (normal left inverted right x axis y axis) 261mm x 163mm Identifier: 0x41 Timestamp: 3327596 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 1 CRTCs: 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 00004ca34154 00110103801a10780a87f594574f8c27 2750540001010101010101010101 010101010101121b008b502010303020 360005a31019000f 0032d20232fe0050 593637350331323141540a2000fe 00263741496c88b0ff01010a20200084 BACKLIGHT: 0 (0x) range: (0,312) Backlight: 0 (0x) range: (0,312) scaling mode: Full aspect supported: None Full Center Full aspect 1280x800 (0x45) 69.3MHz -HSync -VSync +preferred h: width 1280 start 1328 end 1360 total 1419 skew0 clock 48.8KHz v: height 800 start 803 end 809 total 816 clock 59.8Hz 1024x768 (0x46) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 771 end 777 total 806 clock 60.0Hz 800x600 (0x47) 40.0MHz +HSync +VSync *current h: width 800 start 840 end 968 total 1056 skew0 clock 37.9KHz v: height 600 start 601 end 605 total 628 clock 60.3Hz 800x600 (0x48) 36.0MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.2KHz v: height 600 start 601 end 603 total 625 clock 56.2Hz 640x480 (0x49) 25.2MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew0 clock 31.5KHz v: height 480 start 490 end 492 total 525 clock 59.9Hz VGA1 disconnected (normal left inverted right x axis y axis) Identifier: 0x42 Timestamp: 3327596 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: DVI1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 3327596 Subpixel: horizontal rgb Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: TV1 disconnected (normal left inverted right x axis y axis) Identifier: 0x44 Timestamp: 3327596 Subpixel: unknown Clones: CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: bottom margin: 37 (0x0025) range: (0,100) right margin: 46 (0x002e) range: (0,100) top margin: 36 (0x0024) range: (0,100) left margin: 54 (0x0036)range: (0,100) mode: NTSC-M supported: NTSC-M NTSC-443 NTSC-J PAL-M PAL-NPAL 480p 576p 720p@60Hz720p@50Hz1080i@50Hz 1080i@60Hz ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.10.0+ laptop resolution problem
On Thu, Jul 11, 2013 at 8:04 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote: somewhere before commit 496322b (yesterday's kernel) resolution switching on my laptop broke. The screen switches to the right resolution but the screen is not horizontally centered. The screen is aligned left and the last vertical line is repeated until the right side of the screen. Normally there would be black bars on left and right side. Can you please boot with drm.debug=0xe added to your kernel cmdline and then reply with your complete dmesg? 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 -next] drm/i915: fix potential NULL pointer dereference in i915_gem_context_get_hang_stats()
On Thu, Jun 20, 2013 at 08:01:47AM +0800, Wei Yongjun wrote:
From: Wei Yongjun yongjun_...@trendmicro.com.cn
The dereference should be moved below the NULL test.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/gpu/drm/i915/i915_gem_context.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index ff47145..f32107e 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -309,7 +309,7 @@ i915_gem_context_get_hang_stats(struct intel_ring_buffer
*ring,
u32 id)
{
struct drm_i915_private *dev_priv = ring-dev-dev_private;
- struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct drm_i915_file_private *file_priv;
struct i915_hw_context *to;
if (dev_priv-hw_contexts_disabled)
@@ -321,6 +321,7 @@ i915_gem_context_get_hang_stats(struct intel_ring_buffer
*ring,
if (file == NULL)
return ERR_PTR(-EINVAL);
+ file_priv = file-driver_priv;
if (id == DEFAULT_CONTEXT_ID)
return file_priv-hang_stats;
I think we could just not check for file == NULL here as it comes
directly from the ioctl() through i915_gem_execbuffer().
Patch coming...
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't check if a drm_file * is NULL in the ioctl code path
Right now code checkers point out that we try to dereference file before testing it for NULL. This check doesn't seem necessary as file needs to be valid for the ioctl() code to run. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/i915_gem_context.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index ff47145..6573e47 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -318,9 +318,6 @@ i915_gem_context_get_hang_stats(struct intel_ring_buffer *ring, if (ring-id != RCS) return ERR_PTR(-EINVAL); - if (file == NULL) - return ERR_PTR(-EINVAL); - if (id == DEFAULT_CONTEXT_ID) return file_priv-hang_stats; -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Skip pixel multiplier x-check if we fail to send the command
If intel_sdvo_get_value() fails here, val is unitialized and the cross
check won't check anything.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_sdvo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index b8e1623..4481f6a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1357,7 +1357,10 @@ static void intel_sdvo_get_config(struct intel_encoder
*encoder,
}
/* Cross check the port pixel multiplier with the sdvo encoder state. */
- intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_CLOCK_RATE_MULT, val, 1);
+ if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_CLOCK_RATE_MULT,
+ val, 1))
+ return;
+
switch (val) {
case SDVO_CLOCK_RATE_MULT_1X:
encoder_pixel_multiplier = 1;
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] [v2] drm/i915: Expose LLC size to user space
The algorithm/information was originally written by Chad, though I
changed the control flow, and I think his original code had a couple of
bugs, though I didn't look very hard before rewriting. That could have
also been different interpretations of the spec.
I've tested this on two platforms, and it seems to perform how I want.
With this patch is a small tool for igt to query the size. This can be
used as a reference for DRI clients wishing to query the information.
v2: Update name of the SDM location (Bryan)
Dissent: Use a new param instead of reusing HAS_LLC param (Chris, Chad)
Fix unicode multiply symbol (Ben)
CC: Chad Versace chad.vers...@linux.intel.com
CC: Bryan Bell bryan.j.b...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 55 +
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 0e22142..1224586 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1000,6 +1000,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_EXEC_HANDLE_LUT:
value = 1;
break;
+ case I915_PARAM_LLC_SIZE:
+ value = dev_priv-llc_size;
+ break;
default:
DRM_DEBUG(Unknown parameter %d\n, param-param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c8d6104..43a549d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1187,6 +1187,8 @@ typedef struct drm_i915_private {
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
+
+ size_t llc_size;
} drm_i915_private_t;
/* Iterate over initialised rings */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index af61be8..629837d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4282,6 +4282,59 @@ i915_gem_lastclose(struct drm_device *dev)
DRM_ERROR(failed to idle hardware: %d\n, ret);
}
+/**
+ * Return the size, in bytes, of the CPU L3 cache size. If the CPU has no L3
+ * cache, or if an error occurs in obtaining the cache size, then return 0.
+ * From Intel 64 and IA32 Architectures Developer's Manual: Vol. 2A - section
+ * 3.2 - CPUID
+ *
+ * Deterministic Cache Parmaeters (Function 04h):
+ *When EAX is initialized to a value of 4, the CPUID instruction returns
+ *deterministic cache information in the EAX, EBX, ECX and EDX registers.
+ *This function requires ECX be initialized with an index which indicates
+ *which cache to return information about. The OS is expected to call this
+ *function (CPUID.4) with ECX = 0, 1, 2, until EAX[4:0] == 0, indicating no
+ *more caches. The order in which the caches are returned is not specified
+ *and may change at Intel's discretion.
+ *
+ * Calculating the Cache Size in bytes:
+ * = (Ways +1) * (Partitions +1) * (Line Size +1) * (Sets +1)
+ * = (EBX[31:22] +1) * (EBX[21:12] +1) * (EBX[11:0] +1 * (ECX + 1)
+ */
+static size_t get_llc_size(struct drm_device *dev)
+{
+ u8 cnt = 0;
+ unsigned int eax, ebx, ecx, edx;
+
+ if (!HAS_LLC(dev))
+ return 0;
+
+ do {
+ uint32_t cache_level;
+ uint32_t associativity, line_partitions, line_size, sets;
+
+ eax = 4;
+ ecx = cnt;
+ __cpuid(eax, ebx, ecx, edx);
+
+ cache_level = (eax 5) 0x7;
+ if (cache_level != 3)
+ continue;
+
+ associativity = ((ebx 22) 0x3ff) + 1;
+ line_partitions = ((ebx 12) 0x3ff) + 1;
+ line_size = (ebx 0xfff) + 1;
+ sets = ecx + 1;
+
+ return associativity * line_partitions * line_size * sets;
+ } while (eax 0x1f ++cnt);
+
+ /* Let user space know we have non-zero LLC, we can't figure it out */
+ DRM_DEBUG_DRIVER(Couldn't find LLC size. Bug?\n);
+ return 1;
+}
+
+
static void
init_ring_lists(struct intel_ring_buffer *ring)
{
@@ -4333,6 +4386,8 @@ i915_gem_load(struct drm_device *dev)
else
dev_priv-num_fence_regs = 8;
+ dev_priv-llc_size = get_llc_size(dev);
+
/* Initialize fence registers to zero */
INIT_LIST_HEAD(dev_priv-mm.fence_list);
i915_gem_restore_fences(dev);
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 923ed7f..c54559e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -310,6 +310,7 @@ typedef struct drm_i915_irq_wait {
#define
[Intel-gfx] [PATCH 1/2] intel_get_llc_size: Small tool to query LLC size
v2: Use the new param
CC: Chad Versace chad.vers...@linux.intel.com
CC: Bryan Bell bryan.j.b...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
tools/Makefile.am | 1 +
tools/intel_get_llc_size.c | 58 ++
2 files changed, 59 insertions(+)
create mode 100644 tools/intel_get_llc_size.c
diff --git a/tools/Makefile.am b/tools/Makefile.am
index 2519169..a064b65 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -9,6 +9,7 @@ bin_PROGRAMS = \
intel_bios_dumper \
intel_bios_reader \
intel_error_decode \
+ intel_get_llc_size \
intel_gpu_top \
intel_gpu_time \
intel_gtt \
diff --git a/tools/intel_get_llc_size.c b/tools/intel_get_llc_size.c
new file mode 100644
index 000..498e252
--- /dev/null
+++ b/tools/intel_get_llc_size.c
@@ -0,0 +1,58 @@
+/*
+ * Copyright © 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 sys/ioctl.h
+#include drmtest.h
+#include i915_drm.h
+
+#define LOCAL__I915_PARAM_LLC_SIZE 27
+static int get_llc_size(int fd)
+{
+ struct drm_i915_getparam gp;
+ int size;
+
+ gp.param = LOCAL__I915_PARAM_LLC_SIZE;
+ gp.value = size;
+
+ if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, gp, sizeof(gp)))
+ return 0;
+
+ return size;
+}
+
+int main(int argc, char **argv)
+{
+ int size, fd = drm_open_any();
+
+ size = get_llc_size(fd);
+
+ if (size == 0)
+ fprintf(stdout, Doesn't have LLC\n);
+ else if (size == 1)
+ fprintf(stdout, Kernel is too old to determine LLC size\n);
+ else
+ fprintf(stdout, LLC size = %dK\n, size10);
+
+ return 0;
+}
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] tests: Basic tools tester
v2: Remove the reg write test because it breaks pre gen5
Add the llc size param test
Requested-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
tests/Makefile.am | 1 +
tests/drm_lib.sh | 4
tests/tools_test | 21 +
3 files changed, 26 insertions(+)
create mode 100755 tests/tools_test
diff --git a/tests/Makefile.am b/tests/Makefile.am
index a422899..ccc97b8 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -115,6 +115,7 @@ TESTS_scripts_M = \
TESTS_scripts = \
test_rte_check \
+ tools_test \
debugfs_reader \
debugfs_emon_crash \
sysfs_l3_parity \
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index 5ca815b..5975b58 100755
--- a/tests/drm_lib.sh
+++ b/tests/drm_lib.sh
@@ -4,6 +4,10 @@ die() {
exit 1
}
+do_or_die() {
+ $@ /dev/null 21 || (echo FAIL: $@ ($?) exit -1)
+}
+
if [ -d /debug/dri ] ; then
debugfs_path=/debug/dri
fi
diff --git a/tests/tools_test b/tests/tools_test
new file mode 100755
index 000..17f7822
--- /dev/null
+++ b/tests/tools_test
@@ -0,0 +1,21 @@
+#!/bin/bash
+# Test some of the most critical tools we have accidentally broken before.
+# TODO: Possibly make tests parse output
+
+whoami | grep -q root || ( echo ERROR: not running as root; exit 1 )
+
+SOURCE_DIR=$( dirname ${BASH_SOURCE[0]} )
+. $SOURCE_DIR/drm_lib.sh
+
+# ARB_MODE has existed for many gens. It differs per gen, but should be safe to
+# read regardless
+do_or_die $SOURCE_DIR/../tools/intel_reg_read 0x4030
+
+do_or_die $SOURCE_DIR/../tools/intel_reg_dumper
+
+do_or_die $SOURCE_DIR/../tools/intel_get_llc_size
+
+# TODO: Add more tests
+
+exit 0
+
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use for_each_pipe() when possible
Came accross two open coding of for_each_pipe(), might as well use the
macro.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 218bc93..d426c0c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -,7 +,7 @@ static void assert_planes_disabled(struct
drm_i915_private *dev_priv,
}
/* Need to check both planes against the pipe */
- for (i = 0; i INTEL_INFO(dev)-num_pipes; i++) {
+ for_each_pipe(i) {
reg = DSPCNTR(i);
val = I915_READ(reg);
cur_pipe = (val DISPPLANE_SEL_PIPE_MASK)
@@ -9524,7 +9524,7 @@ void intel_modeset_init(struct drm_device *dev)
INTEL_INFO(dev)-num_pipes,
INTEL_INFO(dev)-num_pipes 1 ? s : );
- for (i = 0; i INTEL_INFO(dev)-num_pipes; i++) {
+ for_each_pipe(i) {
intel_crtc_init(dev, i);
for (j = 0; j dev_priv-num_plane; j++) {
ret = intel_plane_init(dev, i, j);
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 3.10.0+ laptop resolution problem
On Thu, Jul 11, 2013 at 09:05:45PM +0200, Hans de Bruin wrote:
On 07/11/2013 08:22 PM, Daniel Vetter wrote:
On Thu, Jul 11, 2013 at 8:04 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote:
somewhere before commit 496322b (yesterday's kernel) resolution switching on
my laptop broke. The screen switches to the right resolution but the screen
is not horizontally centered. The screen is aligned left and the last
vertical line is repeated until the right side of the screen. Normally there
would be black bars on left and right side.
Can you please boot with drm.debug=0xe added to your kernel cmdline
and then reply with your complete dmesg?
I have also started a bisect. Is it useful to continue that?
Let's first see whether my bug-spotting skills are still in working order.
Please test the below diff, thanks.
-Daniel
---
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index b0e1088..0536c9b 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -297,14 +297,11 @@ static bool intel_lvds_compute_config(struct
intel_encoder *intel_encoder,
intel_pch_panel_fitting(intel_crtc, pipe_config,
intel_connector-panel.fitting_mode);
- return true;
} else {
intel_gmch_panel_fitting(intel_crtc, pipe_config,
intel_connector-panel.fitting_mode);
- }
- drm_mode_set_crtcinfo(adjusted_mode, 0);
- pipe_config-timings_set = true;
+ }
/*
* XXX: It would be nice to support lower refresh rates on the
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 80bea1d..45010bb 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -194,6 +194,9 @@ void intel_gmch_panel_fitting(struct intel_crtc *intel_crtc,
adjusted_mode-vdisplay == mode-vdisplay)
goto out;
+ drm_mode_set_crtcinfo(adjusted_mode, 0);
+ pipe_config-timings_set = true;
+
switch (fitting_mode) {
case DRM_MODE_SCALE_CENTER:
/*
--
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] [Intel-gift] Linux 3.10-rc7
I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and pci_disable_msi(). Suspend calls mei_reset with request for disabling interrupts I'm pretty sure I do free_irq and I do disable_msi in the suspend (Hope we are looking at the same code) I don't see a call to mei_enable_interrupts() from mei_me_pci_resume(). I don't think mei_enable_interrupts() is used anywhere. pci_dev_msi_enabled() enables the interrupts in mei_me_pci_resume() looks like. Again here we call mei_reset with request of enabling the interrupts However, I did notice one thing, if pci_dev_msi_enabled() returns false, request_threaded_irq() is called with IRQF_SHARED. Again might just be fine, it leads me to the next question. Is the MSI disabled on your platform? mei_me_pci_suspend() has code that runs after disabling interrupts. Does this need to be split into suspend() and suspend_noirq() ops, since the IRQ could be shared? If you don't have msi I think usually it is shared with some USB device, but I haven't seen that in my code I will check again. Would other resume block the interrupt line? It is a possibility if pci_enable_msi() takes longer in resume path and pci_dev_msi_enabled() returns false, then IRQF_SHARED is requested. Don't know if this helpful, but I thought I would ask just in case, it helps you think of something you didn't before. Please let me know if you need help gathering data from my system. Thanks for ideas I will check that points. Thanks Tomas -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip pixel multiplier x-check if we fail to send the command
On Thu, Jul 11, 2013 at 07:46:00PM +0100, Damien Lespiau wrote:
If intel_sdvo_get_value() fails here, val is unitialized and the cross
check won't check anything.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_sdvo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index b8e1623..4481f6a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1357,7 +1357,10 @@ static void intel_sdvo_get_config(struct intel_encoder
*encoder,
}
/* Cross check the port pixel multiplier with the sdvo encoder state. */
- intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_CLOCK_RATE_MULT, val, 1);
+ if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_CLOCK_RATE_MULT,
+ val, 1))
+ return;
But now it fails silently instead of being paranoid ... Can we just shut
up the tool instead?
-Daniel
+
switch (val) {
case SDVO_CLOCK_RATE_MULT_1X:
encoder_pixel_multiplier = 1;
--
1.8.3.1
___
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: Use for_each_pipe() when possible
On Thu, Jul 11, 2013 at 08:10:54PM +0100, Damien Lespiau wrote:
Came accross two open coding of for_each_pipe(), might as well use the
macro.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Queued for -next, thanks for the patch.
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 218bc93..d426c0c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -,7 +,7 @@ static void assert_planes_disabled(struct
drm_i915_private *dev_priv,
}
/* Need to check both planes against the pipe */
- for (i = 0; i INTEL_INFO(dev)-num_pipes; i++) {
+ for_each_pipe(i) {
reg = DSPCNTR(i);
val = I915_READ(reg);
cur_pipe = (val DISPPLANE_SEL_PIPE_MASK)
@@ -9524,7 +9524,7 @@ void intel_modeset_init(struct drm_device *dev)
INTEL_INFO(dev)-num_pipes,
INTEL_INFO(dev)-num_pipes 1 ? s : );
- for (i = 0; i INTEL_INFO(dev)-num_pipes; i++) {
+ for_each_pipe(i) {
intel_crtc_init(dev, i);
for (j = 0; j dev_priv-num_plane; j++) {
ret = intel_plane_init(dev, i, j);
--
1.8.3.1
___
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
[Intel-gfx] [PATCH] drm/i915: clean up vlv -pre_pll_enable and pll enable sequence
No need to call the -pre_pll_enable hook twice if we don't enable the
dpll too early. This should make Jani a bit less grumpy.
v2: Rebase on top of the newly-colored BUG_ONs.
v3: Reinstate the lost write of the DPLL_MD register, spotted by Imre.
Cc: Imre Deak imre.d...@intel.com
Cc: Jani Nikula jani.nik...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 47 +++-
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4c647e0..923c913 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1300,32 +1300,40 @@ static void assert_pch_ports_disabled(struct
drm_i915_private *dev_priv,
assert_pch_hdmi_disabled(dev_priv, pipe, PCH_HDMID);
}
-static void vlv_enable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
+static void vlv_enable_pll(struct intel_crtc *crtc)
{
- int reg;
- u32 val;
+ struct drm_device *dev = crtc-base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int reg = DPLL(crtc-pipe);
+ u32 dpll = crtc-config.dpll_hw_state.dpll;
- assert_pipe_disabled(dev_priv, pipe);
+ assert_pipe_disabled(dev_priv, crtc-pipe);
/* No really, not for ILK+ */
BUG_ON(!IS_VALLEYVIEW(dev_priv-dev));
/* PLL is protected by panel, make sure we can write it */
if (IS_MOBILE(dev_priv-dev) !IS_I830(dev_priv-dev))
- assert_panel_unlocked(dev_priv, pipe);
+ assert_panel_unlocked(dev_priv, crtc-pipe);
- reg = DPLL(pipe);
- val = I915_READ(reg);
- val |= DPLL_VCO_ENABLE;
+ I915_WRITE(reg, dpll);
+ POSTING_READ(reg);
+ udelay(150);
+
+ if (wait_for(((I915_READ(reg) DPLL_LOCK_VLV) == DPLL_LOCK_VLV), 1))
+ DRM_ERROR(DPLL %d failed to lock\n, crtc-pipe);
+
+ I915_WRITE(DPLL_MD(crtc-pipe), crtc-config.dpll_hw_state.dpll_md);
+ POSTING_READ(DPLL_MD(crtc-pipe));
/* We do this three times for luck */
- I915_WRITE(reg, val);
+ I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150); /* wait for warmup */
- I915_WRITE(reg, val);
+ I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150); /* wait for warmup */
- I915_WRITE(reg, val);
+ I915_WRITE(reg, dpll);
POSTING_READ(reg);
udelay(150); /* wait for warmup */
}
@@ -3633,7 +3641,7 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
if (encoder-pre_pll_enable)
encoder-pre_pll_enable(encoder);
- vlv_enable_pll(dev_priv, pipe);
+ vlv_enable_pll(intel_crtc);
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder-pre_enable)
@@ -4388,7 +4396,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
{
struct drm_device *dev = crtc-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- struct intel_encoder *encoder;
int pipe = crtc-pipe;
u32 dpll, mdiv;
u32 bestn, bestm1, bestm2, bestp1, bestp2;
@@ -4477,10 +4484,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
vlv_dpio_write(dev_priv, DPIO_PLL_CML(pipe), 0x87871000);
- for_each_encoder_on_crtc(dev, crtc-base, encoder)
- if (encoder-pre_pll_enable)
- encoder-pre_pll_enable(encoder);
-
/* Enable DPIO clock input */
dpll = DPLL_EXT_BUFFER_ENABLE_VLV | DPLL_REFA_CLK_ENABLE_VLV |
DPLL_VGA_MODE_DIS | DPLL_INTEGRATED_CLOCK_VLV;
@@ -4490,20 +4493,10 @@ static void vlv_update_pll(struct intel_crtc *crtc)
dpll |= DPLL_VCO_ENABLE;
crtc-config.dpll_hw_state.dpll = dpll;
- I915_WRITE(DPLL(pipe), dpll);
- POSTING_READ(DPLL(pipe));
- udelay(150);
-
- if (wait_for(((I915_READ(DPLL(pipe)) DPLL_LOCK_VLV) ==
DPLL_LOCK_VLV), 1))
- DRM_ERROR(DPLL %d failed to lock\n, pipe);
-
dpll_md = (crtc-config.pixel_multiplier - 1)
DPLL_MD_UDI_MULTIPLIER_SHIFT;
crtc-config.dpll_hw_state.dpll_md = dpll_md;
- I915_WRITE(DPLL_MD(pipe), dpll_md);
- POSTING_READ(DPLL_MD(pipe));
-
if (crtc-config.has_dp_encoder)
intel_dp_set_m_n(crtc);
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Skip pixel multiplier x-check if we fail to send the command
On Thu, Jul 11, 2013 at 09:52:33PM +0200, Daniel Vetter wrote: On Thu, Jul 11, 2013 at 07:46:00PM +0100, Damien Lespiau wrote: If intel_sdvo_get_value() fails here, val is unitialized and the cross check won't check anything. Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/intel_sdvo.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index b8e1623..4481f6a 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -1357,7 +1357,10 @@ static void intel_sdvo_get_config(struct intel_encoder *encoder, } /* Cross check the port pixel multiplier with the sdvo encoder state. */ - intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_CLOCK_RATE_MULT, val, 1); + if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_CLOCK_RATE_MULT, + val, 1)) + return; But now it fails silently instead of being paranoid ... Can we just shut up the tool instead? We absolutely can! (and it's done). -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2] drm/i915: Expose LLC size to user space
On Thu, Jul 11, 2013 at 11:52:12AM -0700, Ben Widawsky wrote:
The algorithm/information was originally written by Chad, though I
changed the control flow, and I think his original code had a couple of
bugs, though I didn't look very hard before rewriting. That could have
also been different interpretations of the spec.
I've tested this on two platforms, and it seems to perform how I want.
With this patch is a small tool for igt to query the size. This can be
used as a reference for DRI clients wishing to query the information.
v2: Update name of the SDM location (Bryan)
Dissent: Use a new param instead of reusing HAS_LLC param (Chris, Chad)
Fix unicode multiply symbol (Ben)
Shrug. I still dislike calling it LLC_SIZE since it is actually L3_SIZE.
For very similar reasons, easily finding out L2 size would be useful, as
would L4.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c8d6104..43a549d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1187,6 +1187,8 @@ typedef struct drm_i915_private {
/* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
struct i915_dri1_state dri1;
+
+ size_t llc_size;
Don't put it below the dungeons, it will be tainted.
-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: Don't check if a drm_file * is NULL in the ioctl code path
On Thu, Jul 11, 2013 at 07:31:34PM +0100, Damien Lespiau wrote: Right now code checkers point out that we try to dereference file before testing it for NULL. This check doesn't seem necessary as file needs to be valid for the ioctl() code to run. This whole function was a copy'n'paste mistake with a rewrite on the mailing list. -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] 3.10.0+ laptop resolution problem
On 07/11/2013 09:41 PM, Daniel Vetter wrote: On Thu, Jul 11, 2013 at 09:05:45PM +0200, Hans de Bruin wrote: On 07/11/2013 08:22 PM, Daniel Vetter wrote: On Thu, Jul 11, 2013 at 8:04 PM, Hans de Bruin jmdebr...@xmsnet.nl wrote: somewhere before commit 496322b (yesterday's kernel) resolution switching on my laptop broke. The screen switches to the right resolution but the screen is not horizontally centered. The screen is aligned left and the last vertical line is repeated until the right side of the screen. Normally there would be black bars on left and right side. Can you please boot with drm.debug=0xe added to your kernel cmdline and then reply with your complete dmesg? I have also started a bisect. Is it useful to continue that? Let's first see whether my bug-spotting skills are still in working order. Please test the below diff, thanks. Apparently the are. The diff fixes my problem. -- Hans ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/11] Enable PSR on Haswell.
I'm resending full series again because after accepting most of suggestions and rebasing again on drm-intel-nightly most of patches got some kind of conflict so the full series is here again. First 3 patches on this series are already reviewed and I'd be glad if they were merged asap to avoid future conflicts. This patches at least allows people to know if they have psr panel or not. For the rest I accepted most of suggestions and explained on previous emails the ones I didn't accepted and why. However even the ones I didn't accepted I tested and verified that they caused some kind of issue. This version is working very fine for a long time in my machine. I'd appreciate if you could merge everything since now psr is disabled by default by kernel flag. So I'm 100% sure that this series won't cause any kind of regression for any user. I understand that it would be good to deliver psr enabled by default however I'm changing this default behaviour because I'm sure that PSR will cause regression without userspace (DDX) help when using kde and xdm. Thanks in advance, Rodrigo. Rodrigo Vivi (9): drm/i915: split aux_clock_divider logic in a separated function for reuse. drm/i915: Enable/Disable PSR drm/i915: Added debugfs support for PSR Status drm/i915: Match all PSR mode entry conditions before enabling it. drm/i915: add update function to disable/enable-back PSR drm/intel: add enable_psr module option and disable psr by default drm/i915: Adding global I915_PARAM for PSR ENABLED. drm/i915: Add functions to force psr exit drm/i915: Hook PSR functionality Shobhit Kumar (2): drm: Added SDP and VSC structures for handling PSR for eDP drm/i915: Read the EDP DPCD and PSR Capability drivers/gpu/drm/i915/i915_debugfs.c | 128 drivers/gpu/drm/i915/i915_dma.c | 3 + drivers/gpu/drm/i915/i915_drv.c | 4 + drivers/gpu/drm/i915/i915_drv.h | 15 ++ drivers/gpu/drm/i915/i915_gem.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 74 +++ drivers/gpu/drm/i915/intel_ddi.c | 2 + drivers/gpu/drm/i915/intel_display.c | 1 + drivers/gpu/drm/i915/intel_dp.c | 373 --- drivers/gpu/drm/i915/intel_drv.h | 10 + include/drm/drm_dp_helper.h | 31 ++- include/uapi/drm/i915_drm.h | 1 + 12 files changed, 618 insertions(+), 26 deletions(-) -- 1.7.11.7 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/11] drm: Added SDP and VSC structures for handling PSR for eDP
From: Shobhit Kumar shobhit.ku...@intel.com
SDP header and SDP VSC header as per eDP 1.3 spec, section 3.5,
chapter PSR Secondary Data Package Support.
v2: Modified and corrected the structures to be more in line for
kernel coding guidelines and rebased the code on Paulo's DP patchset
v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE
v4: moving them to include/drm/drm_dp_helper.h and also already
icluding EDP_PSR_RECEIVER_CAP_SIZE to add everything needed
for PSR at once at drm_dp_helper.h
v5: Fix SDP VSC header and identation by (Paulo Zanoni) and
remove i915 from title (Daniel Vetter)
v6: Fix spec version and move comments from code to commit message
since numbers might change in the future (by Paulo Zanoni).
CC: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Sateesh Kavuri sateesh.kav...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
include/drm/drm_dp_helper.h | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index e8e1417..ae8dbfb 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -342,13 +342,42 @@ u8 drm_dp_get_adjust_request_voltage(u8
link_status[DP_LINK_STATUS_SIZE],
u8 drm_dp_get_adjust_request_pre_emphasis(u8 link_status[DP_LINK_STATUS_SIZE],
int lane);
-#define DP_RECEIVER_CAP_SIZE 0xf
+#define DP_RECEIVER_CAP_SIZE 0xf
+#define EDP_PSR_RECEIVER_CAP_SIZE 2
+
void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
u8 drm_dp_link_rate_to_bw_code(int link_rate);
int drm_dp_bw_code_to_link_rate(u8 link_bw);
+struct edp_sdp_header {
+ u8 HB0; /* Secondary Data Packet ID */
+ u8 HB1; /* Secondary Data Packet Type */
+ u8 HB2; /* 7:5 reserved, 4:0 revision number */
+ u8 HB3; /* 7:5 reserved, 4:0 number of valid data bytes */
+} __packed;
+
+#define EDP_SDP_HEADER_REVISION_MASK 0x1F
+#define EDP_SDP_HEADER_VALID_PAYLOAD_BYTES 0x1F
+
+struct edp_vsc_psr {
+ struct edp_sdp_header sdp_header;
+ u8 DB0; /* Stereo Interface */
+ u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid */
+ u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
+ u8 DB3; /* CRC value bits 15:8 of the R or Cr component */
+ u8 DB4; /* CRC value bits 7:0 of the G or Y component */
+ u8 DB5; /* CRC value bits 15:8 of the G or Y component */
+ u8 DB6; /* CRC value bits 7:0 of the B or Cb component */
+ u8 DB7; /* CRC value bits 15:8 of the B or Cb component */
+ u8 DB8_31[24]; /* Reserved */
+} __packed;
+
+#define EDP_VSC_PSR_STATE_ACTIVE (10)
+#define EDP_VSC_PSR_UPDATE_RFB (11)
+#define EDP_VSC_PSR_CRC_VALUES_VALID (12)
+
static inline int
drm_dp_max_link_rate(u8 dpcd[DP_RECEIVER_CAP_SIZE])
{
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/11] drm/i915: Read the EDP DPCD and PSR Capability
From: Shobhit Kumar shobhit.ku...@intel.com
v2: reuse of just created is_edp_psr and put it at right place.
v3: move is_edp_psr above intel_edp_disable
v4: remove parentheses. Noticed by Paulo.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 13 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7db2cd7..bf0bfa1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1369,6 +1369,12 @@ static void intel_dp_get_config(struct intel_encoder
*encoder,
}
}
+static bool is_edp_psr(struct intel_dp *intel_dp)
+{
+ return is_edp(intel_dp)
+ intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED;
+}
+
static void intel_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
@@ -2282,6 +2288,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp-dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
+ /* Check if the panel supports PSR */
+ memset(intel_dp-psr_dpcd, 0, sizeof(intel_dp-psr_dpcd));
+ intel_dp_aux_native_read_retry(intel_dp, DP_PSR_SUPPORT,
+ intel_dp-psr_dpcd,
+ sizeof(intel_dp-psr_dpcd));
+ if (is_edp_psr(intel_dp))
+ DRM_DEBUG_KMS(Detected EDP PSR Panel.\n);
if (!(intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT]
DP_DWN_STRM_PORT_PRESENT))
return true; /* native DP sink */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5dfc1a0..d25726d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -487,6 +487,7 @@ struct intel_dp {
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
+ uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
struct i2c_adapter adapter;
struct i2c_algo_dp_aux_data algo;
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/11] drm/i915: split aux_clock_divider logic in a separated function for reuse.
Prep patch for reuse aux_clock_divider with EDP_PSR_AUX_CTL setup.
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 58 +++--
1 file changed, 33 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bf0bfa1..d273e36 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -276,29 +276,12 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool
has_aux_irq)
return status;
}
-static int
-intel_dp_aux_ch(struct intel_dp *intel_dp,
- uint8_t *send, int send_bytes,
- uint8_t *recv, int recv_size)
+static uint32_t get_aux_clock_divider(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- uint32_t ch_ctl = intel_dp-aux_ch_ctl_reg;
- uint32_t ch_data = ch_ctl + 4;
- int i, ret, recv_bytes;
- uint32_t status;
- uint32_t aux_clock_divider;
- int try, precharge;
- bool has_aux_irq = INTEL_INFO(dev)-gen = 5 !IS_VALLEYVIEW(dev);
- /* dp aux is extremely sensitive to irq latency, hence request the
-* lowest possible wakeup latency and so prevent the cpu from going into
-* deep sleep states.
-*/
- pm_qos_update_request(dev_priv-pm_qos, 0);
-
- intel_dp_check_edp(intel_dp);
/* The clock divider is based off the hrawclk,
* and would like to run at 2MHz. So, take the
* hrawclk value and divide by 2 and use that
@@ -307,23 +290,48 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
* clock divider.
*/
if (IS_VALLEYVIEW(dev)) {
- aux_clock_divider = 100;
+ return 100;
} else if (intel_dig_port-port == PORT_A) {
if (HAS_DDI(dev))
- aux_clock_divider = DIV_ROUND_CLOSEST(
+ return DIV_ROUND_CLOSEST(
intel_ddi_get_cdclk_freq(dev_priv), 2000);
else if (IS_GEN6(dev) || IS_GEN7(dev))
- aux_clock_divider = 200; /* SNB IVB eDP input clock
at 400Mhz */
+ return 200; /* SNB IVB eDP input clock at 400Mhz */
else
- aux_clock_divider = 225; /* eDP input clock at 450Mhz */
+ return 225; /* eDP input clock at 450Mhz */
} else if (dev_priv-pch_id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
/* Workaround for non-ULT HSW */
- aux_clock_divider = 74;
+ return 74;
} else if (HAS_PCH_SPLIT(dev)) {
- aux_clock_divider = DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
+ return DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
} else {
- aux_clock_divider = intel_hrawclk(dev) / 2;
+ return intel_hrawclk(dev) / 2;
}
+}
+
+static int
+intel_dp_aux_ch(struct intel_dp *intel_dp,
+ uint8_t *send, int send_bytes,
+ uint8_t *recv, int recv_size)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port-base.base.dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ uint32_t ch_ctl = intel_dp-aux_ch_ctl_reg;
+ uint32_t ch_data = ch_ctl + 4;
+ int i, ret, recv_bytes;
+ uint32_t status;
+ uint32_t aux_clock_divider = get_aux_clock_divider(intel_dp);
+ int try, precharge;
+ bool has_aux_irq = INTEL_INFO(dev)-gen = 5 !IS_VALLEYVIEW(dev);
+
+ /* dp aux is extremely sensitive to irq latency, hence request the
+* lowest possible wakeup latency and so prevent the cpu from going into
+* deep sleep states.
+*/
+ pm_qos_update_request(dev_priv-pm_qos, 0);
+
+ intel_dp_check_edp(intel_dp);
if (IS_GEN6(dev))
precharge = 3;
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/11] drm/i915: Enable/Disable PSR
Adding Enable and Disable PSR functionalities. This includes setting the
PSR configuration over AUX, sending SDP VSC DIP over the eDP PIPE config,
enabling PSR in the sink via DPCD register and finally enabling PSR on
the host.
This patch is based on initial PSR code by Sateesh Kavuri and Kumar Shobhit
but in a different implementation.
v2: * moved functions around and changed its names.
* removed VSC DIP unset from disable.
* remove FBC wa.
* don't mask LSPS anymore.
* incorporate new crtc usage after a rebase.
v3: Make a clear separation between Sink (Panel) and Source (HW) enabling.
v4: Fix identation and other style issues raised by checkpatch (by Paulo).
v5: Changes according to Paulo's review:
static on write_vsc;
avoid using dp_to_dev when already calling dp_to_dig_port;
remove unecessary TP default time setting;
remove unecessary interrupts disabling;
remove unecessary wait_for_vblank when disabling psr;
v6: remove unecessary wait_for_vblank when writing vsc;
v7: adding setup once function to avoid unnecessarily write to vsc
and set debug_ctl every time we enable or disable psr.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Credits-by: Sateesh Kavuri sateesh.kav...@intel.com
Credits-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 42 +++
drivers/gpu/drm/i915/intel_dp.c | 149 +++
drivers/gpu/drm/i915/intel_drv.h | 4 ++
3 files changed, 195 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dc3d6a7..31e4dbb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1779,6 +1779,47 @@
#define BCLRPAT(pipe) _PIPE(pipe, _BCLRPAT_A, _BCLRPAT_B)
#define VSYNCSHIFT(trans) _TRANSCODER(trans, _VSYNCSHIFT_A, _VSYNCSHIFT_B)
+/* HSW eDP PSR registers */
+#define EDP_PSR_CTL0x64800
+#define EDP_PSR_ENABLE (131)
+#define EDP_PSR_LINK_DISABLE (027)
+#define EDP_PSR_LINK_STANDBY (127)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (325)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (025)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (125)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (225)
+#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (325)
+#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
+#define EDP_PSR_SKIP_AUX_EXIT(112)
+#define EDP_PSR_TP1_TP2_SEL (011)
+#define EDP_PSR_TP1_TP3_SEL (111)
+#define EDP_PSR_TP2_TP3_TIME_500us (08)
+#define EDP_PSR_TP2_TP3_TIME_100us (18)
+#define EDP_PSR_TP2_TP3_TIME_2500us (28)
+#define EDP_PSR_TP2_TP3_TIME_0us (38)
+#define EDP_PSR_TP1_TIME_500us (04)
+#define EDP_PSR_TP1_TIME_100us (14)
+#define EDP_PSR_TP1_TIME_2500us (24)
+#define EDP_PSR_TP1_TIME_0us (34)
+#define EDP_PSR_IDLE_FRAME_SHIFT 0
+
+#define EDP_PSR_AUX_CTL0x64810
+#define EDP_PSR_AUX_DATA1 0x64814
+#define EDP_PSR_DPCD_COMMAND 0x8006
+#define EDP_PSR_AUX_DATA2 0x64818
+#define EDP_PSR_DPCD_NORMAL_OPERATION(124)
+#define EDP_PSR_AUX_DATA3 0x6481c
+#define EDP_PSR_AUX_DATA4 0x64820
+#define EDP_PSR_AUX_DATA5 0x64824
+
+#define EDP_PSR_STATUS_CTL 0x64840
+#define EDP_PSR_STATUS_STATE_MASK(729)
+
+#define EDP_PSR_DEBUG_CTL 0x64860
+#define EDP_PSR_DEBUG_MASK_LPSP (127)
+#define EDP_PSR_DEBUG_MASK_MEMUP (126)
+#define EDP_PSR_DEBUG_MASK_HPD (125)
+
/* VGA port control */
#define ADPA 0x61100
#define PCH_ADPA0xe1100
@@ -2048,6 +2089,7 @@
* (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each
byte
* of the infoframe structure specified by CEA-861. */
#define VIDEO_DIP_DATA_SIZE 32
+#define VIDEO_DIP_VSC_DATA_SIZE 36
#define VIDEO_DIP_CTL 0x61170
/* Pre HSW: */
#define VIDEO_DIP_ENABLE (1 31)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d273e36..d4b52a9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1383,6 +1383,153 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED;
}
+static bool intel_edp_is_psr_enabled(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!IS_HASWELL(dev))
+ return false;
+
+ return I915_READ(EDP_PSR_CTL) EDP_PSR_ENABLE;
+}
+
+static void intel_edp_psr_write_vsc(struct intel_dp *intel_dp,
+ struct edp_vsc_psr *vsc_psr)
+{
+ struct
[Intel-gfx] [PATCH 06/11] drm/i915: Match all PSR mode entry conditions before enabling it.
v2: Prefer seq_puts to seq_printf by Paulo Zanoni.
v3: small changes like avoiding calling dp_to_dig_port twice as noticed by
Paulo Zanoni.
v4: Avoiding reading non-existent registers - noticed by Paulo
on first psr debugfs patch.
v5: Accepting more suggestions from Paulo:
* check sw interlace flag instead of i915_read
* introduce PSR_S3D_ENABLED to avoid forgeting it whenever added.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 44 ++
drivers/gpu/drm/i915/i915_drv.h | 13 +++
drivers/gpu/drm/i915/i915_reg.h | 7
drivers/gpu/drm/i915/intel_dp.c | 74 -
4 files changed, 130 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fe3cd5a..e679968 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1948,17 +1948,47 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
struct drm_info_node *node = m-private;
struct drm_device *dev = node-minor-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
- u32 psrctl, psrstat, psrperf;
+ u32 psrstat, psrperf;
- if (!IS_HASWELL(dev)) {
- seq_puts(m, PSR not supported on this platform\n);
+ if (IS_HASWELL(dev) I915_READ(EDP_PSR_CTL) EDP_PSR_ENABLE) {
+ seq_puts(m, PSR enabled\n);
+ } else {
+ seq_puts(m, PSR disabled: );
+ switch (dev_priv-no_psr_reason) {
+ case PSR_NO_SOURCE:
+ seq_puts(m, not supported on this platform);
+ break;
+ case PSR_NO_SINK:
+ seq_puts(m, not supported by panel);
+ break;
+ case PSR_CRTC_NOT_ACTIVE:
+ seq_puts(m, crtc not active);
+ break;
+ case PSR_PWR_WELL_ENABLED:
+ seq_puts(m, power well enabled);
+ break;
+ case PSR_NOT_TILED:
+ seq_puts(m, not tiled);
+ break;
+ case PSR_SPRITE_ENABLED:
+ seq_puts(m, sprite enabled);
+ break;
+ case PSR_S3D_ENABLED:
+ seq_puts(m, stereo 3d enabled);
+ break;
+ case PSR_INTERLACED_ENABLED:
+ seq_puts(m, interlaced enabled);
+ break;
+ case PSR_HSW_NOT_DDIA:
+ seq_puts(m, HSW ties PSR to DDI A (eDP));
+ break;
+ default:
+ seq_puts(m, unknown reason);
+ }
+ seq_puts(m, \n);
return 0;
}
- psrctl = I915_READ(EDP_PSR_CTL);
- seq_printf(m, PSR Enabled: %s\n,
- yesno(psrctl EDP_PSR_ENABLE));
-
psrstat = I915_READ(EDP_PSR_STATUS_CTL);
seq_puts(m, PSR Current State: );
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 842aada..d0b9483 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -560,6 +560,17 @@ struct i915_fbc {
} no_fbc_reason;
};
+enum no_psr_reason {
+ PSR_NO_SOURCE, /* Not supported on platform */
+ PSR_NO_SINK, /* Not supported by panel */
+ PSR_CRTC_NOT_ACTIVE,
+ PSR_PWR_WELL_ENABLED,
+ PSR_NOT_TILED,
+ PSR_SPRITE_ENABLED,
+ PSR_S3D_ENABLED,
+ PSR_INTERLACED_ENABLED,
+ PSR_HSW_NOT_DDIA,
+};
enum intel_pch {
PCH_NONE = 0, /* No PCH present */
@@ -1161,6 +1172,8 @@ typedef struct drm_i915_private {
/* Haswell power well */
struct i915_power_well power_well;
+ enum no_psr_reason no_psr_reason;
+
struct i915_gpu_error gpu_error;
struct drm_i915_gem_object *vlv_pctx;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b328ec6..3bca337 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4150,6 +4150,13 @@
#define HSW_TVIDEO_DIP_VSC_DATA(trans) \
_TRANSCODER(trans, HSW_VIDEO_DIP_VSC_DATA_A, HSW_VIDEO_DIP_VSC_DATA_B)
+#define HSW_STEREO_3D_CTL_A0x70020
+#define S3D_ENABLE (131)
+#define HSW_STEREO_3D_CTL_B0x71020
+
+#define HSW_STEREO_3D_CTL(trans) \
+ _TRANSCODER(trans, HSW_STEREO_3D_CTL_A, HSW_STEREO_3D_CTL_A)
+
#define _PCH_TRANS_HTOTAL_B 0xe1000
#define _PCH_TRANS_HBLANK_B 0xe1004
#define _PCH_TRANS_HSYNC_B 0xe1008
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d4b52a9..c0bd887 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1497,11
[Intel-gfx] [PATCH 05/11] drm/i915: Added debugfs support for PSR Status
Adding support for PSR Status, PSR entry counter and performance counters.
Heavily based on initial work from Shobhit.
v2: Fix PSR Status Link bits by Paulo Zanoni.
v3: Prefer seq_puts to seq_printf by Paulo Zanoni.
v4: Fix identation by Paulo Zanoni.
v5: Return earlier if it isn't Haswell in order to avoid reading non-existing
registers - by Paulo Zanoni.
CC: Paulo Zanoni paulo.r.zan...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Credits-by: Shobhit Kumar shobhit.ku...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 95 +
drivers/gpu/drm/i915/i915_reg.h | 24 ++
2 files changed, 119 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d413812..fe3cd5a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1943,6 +1943,100 @@ static int i915_dpio_info(struct seq_file *m, void
*data)
return 0;
}
+static int i915_edp_psr_status(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 psrctl, psrstat, psrperf;
+
+ if (!IS_HASWELL(dev)) {
+ seq_puts(m, PSR not supported on this platform\n);
+ return 0;
+ }
+
+ psrctl = I915_READ(EDP_PSR_CTL);
+ seq_printf(m, PSR Enabled: %s\n,
+ yesno(psrctl EDP_PSR_ENABLE));
+
+ psrstat = I915_READ(EDP_PSR_STATUS_CTL);
+
+ seq_puts(m, PSR Current State: );
+ switch (psrstat EDP_PSR_STATUS_STATE_MASK) {
+ case EDP_PSR_STATUS_STATE_IDLE:
+ seq_puts(m, Reset state\n);
+ break;
+ case EDP_PSR_STATUS_STATE_SRDONACK:
+ seq_puts(m, Wait for TG/Stream to send on frame of data after
SRD conditions are met\n);
+ break;
+ case EDP_PSR_STATUS_STATE_SRDENT:
+ seq_puts(m, SRD entry\n);
+ break;
+ case EDP_PSR_STATUS_STATE_BUFOFF:
+ seq_puts(m, Wait for buffer turn off\n);
+ break;
+ case EDP_PSR_STATUS_STATE_BUFON:
+ seq_puts(m, Wait for buffer turn on\n);
+ break;
+ case EDP_PSR_STATUS_STATE_AUXACK:
+ seq_puts(m, Wait for AUX to acknowledge on SRD exit\n);
+ break;
+ case EDP_PSR_STATUS_STATE_SRDOFFACK:
+ seq_puts(m, Wait for TG/Stream to acknowledge the SRD VDM
exit\n);
+ break;
+ default:
+ seq_puts(m, Unknown\n);
+ break;
+ }
+
+ seq_puts(m, Link Status: );
+ switch (psrstat EDP_PSR_STATUS_LINK_MASK) {
+ case EDP_PSR_STATUS_LINK_FULL_OFF:
+ seq_puts(m, Link is fully off\n);
+ break;
+ case EDP_PSR_STATUS_LINK_FULL_ON:
+ seq_puts(m, Link is fully on\n);
+ break;
+ case EDP_PSR_STATUS_LINK_STANDBY:
+ seq_puts(m, Link is in standby\n);
+ break;
+ default:
+ seq_puts(m, Unknown\n);
+ break;
+ }
+
+ seq_printf(m, PSR Entry Count: %u\n,
+ psrstat EDP_PSR_STATUS_COUNT_SHIFT
+ EDP_PSR_STATUS_COUNT_MASK);
+
+ seq_printf(m, Max Sleep Timer Counter: %u\n,
+ psrstat EDP_PSR_STATUS_MAX_SLEEP_TIMER_SHIFT
+ EDP_PSR_STATUS_MAX_SLEEP_TIMER_MASK);
+
+ seq_printf(m, Had AUX error: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_AUX_ERROR));
+
+ seq_printf(m, Sending AUX: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_AUX_SENDING));
+
+ seq_printf(m, Sending Idle: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_SENDING_IDLE));
+
+ seq_printf(m, Sending TP2 TP3: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_SENDING_TP2_TP3));
+
+ seq_printf(m, Sending TP1: %s\n,
+ yesno(psrstat EDP_PSR_STATUS_SENDING_TP1));
+
+ seq_printf(m, Idle Count: %u\n,
+ psrstat EDP_PSR_STATUS_IDLE_MASK);
+
+ psrperf = (I915_READ(EDP_PSR_PERF_CNT)) EDP_PSR_PERF_CNT_MASK;
+ seq_printf(m, Performance Counter: %u\n, psrperf);
+
+ return 0;
+}
+
static int
i915_wedged_get(void *data, u64 *val)
{
@@ -2372,6 +2466,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{i915_swizzle_info, i915_swizzle_info, 0},
{i915_ppgtt_info, i915_ppgtt_info, 0},
{i915_dpio, i915_dpio_info, 0},
+ {i915_edp_psr_status, i915_edp_psr_status, 0},
};
#define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 31e4dbb..b328ec6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1814,6 +1814,30 @@
#define
[Intel-gfx] [PATCH 08/11] drm/intel: add enable_psr module option and disable psr by default
v2: prefer seq_puts to seq_printf detected by Paulo Zanoni.
v3: PSR is disabled by default. Without userspace ready it
will cause regression for kde and xdm users
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
drivers/gpu/drm/i915/i915_drv.c | 4
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 6 ++
4 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index e679968..5a2b621 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1961,6 +1961,9 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
case PSR_NO_SINK:
seq_puts(m, not supported by panel);
break;
+ case PSR_MODULE_PARAM:
+ seq_puts(m, disabled by flag);
+ break;
case PSR_CRTC_NOT_ACTIVE:
seq_puts(m, crtc not active);
break;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b07362f..f2c018d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -118,6 +118,10 @@ module_param_named(i915_enable_ppgtt, i915_enable_ppgtt,
int, 0600);
MODULE_PARM_DESC(i915_enable_ppgtt,
Enable PPGTT (default: true));
+int i915_enable_psr __read_mostly = 0;
+module_param_named(enable_psr, i915_enable_psr, int, 0600);
+MODULE_PARM_DESC(enable_psr, Enable PSR (default: false));
+
unsigned int i915_preliminary_hw_support __read_mostly = 0;
module_param_named(preliminary_hw_support, i915_preliminary_hw_support, int,
0600);
MODULE_PARM_DESC(preliminary_hw_support,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d0b9483..1992081 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -563,6 +563,7 @@ struct i915_fbc {
enum no_psr_reason {
PSR_NO_SOURCE, /* Not supported on platform */
PSR_NO_SINK, /* Not supported by panel */
+ PSR_MODULE_PARAM,
PSR_CRTC_NOT_ACTIVE,
PSR_PWR_WELL_ENABLED,
PSR_NOT_TILED,
@@ -1593,6 +1594,7 @@ extern int i915_enable_rc6 __read_mostly;
extern int i915_enable_fbc __read_mostly;
extern bool i915_enable_hangcheck __read_mostly;
extern int i915_enable_ppgtt __read_mostly;
+extern int i915_enable_psr __read_mostly;
extern unsigned int i915_preliminary_hw_support __read_mostly;
extern int i915_disable_power_well __read_mostly;
extern int i915_enable_ips __read_mostly;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c0870a69..c0defaf 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1526,6 +1526,12 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
return false;
}
+ if (!i915_enable_psr) {
+ DRM_DEBUG_KMS(PSR disable by flag\n);
+ dev_priv-no_psr_reason = PSR_MODULE_PARAM;
+ return false;
+ }
+
if (!intel_crtc-active || !crtc-fb || !crtc-mode.clock) {
DRM_DEBUG_KMS(crtc not active for PSR\n);
dev_priv-no_psr_reason = PSR_CRTC_NOT_ACTIVE;
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/11] drm/i915: add update function to disable/enable-back PSR
Required function to disable PSR when going to console mode.
But also can be used whenever PSR mode entry conditions changed.
v2: Add it before PSR Hook. Update function not really been called yet.
v3: Fix coding style detected by checkpatch by Paulo Zanoni.
v4: do_enable must be static as Paulo noticed.
Cc: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/intel_dp.c | 31 ++-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c0bd887..c0870a69 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1568,7 +1568,7 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
return true;
}
-void intel_edp_psr_enable(struct intel_dp *intel_dp)
+static void intel_edp_psr_do_enable(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -1586,6 +1586,15 @@ void intel_edp_psr_enable(struct intel_dp *intel_dp)
intel_edp_psr_enable_source(intel_dp);
}
+void intel_edp_psr_enable(struct intel_dp *intel_dp)
+{
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+
+ if (intel_edp_psr_match_conditions(intel_dp)
+ !intel_edp_is_psr_enabled(dev))
+ intel_edp_psr_do_enable(intel_dp);
+}
+
void intel_edp_psr_disable(struct intel_dp *intel_dp)
{
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -1602,6 +1611,26 @@ void intel_edp_psr_disable(struct intel_dp *intel_dp)
DRM_ERROR(Timed out waiting for PSR Idle State\n);
}
+void intel_edp_psr_update(struct drm_device *dev)
+{
+ struct intel_encoder *encoder;
+ struct intel_dp *intel_dp = NULL;
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
+ if (encoder-type == INTEL_OUTPUT_EDP) {
+ intel_dp = enc_to_intel_dp(encoder-base);
+
+ if (!is_edp_psr(intel_dp))
+ return;
+
+ if (!intel_edp_psr_match_conditions(intel_dp))
+ intel_edp_psr_disable(intel_dp);
+ else
+ if (!intel_edp_is_psr_enabled(dev))
+ intel_edp_psr_do_enable(intel_dp);
+ }
+}
+
static void intel_disable_dp(struct intel_encoder *encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ff36a40..40e955d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -837,5 +837,6 @@ extern bool intel_set_pch_fifo_underrun_reporting(struct
drm_device *dev,
extern void intel_edp_psr_enable(struct intel_dp *intel_dp);
extern void intel_edp_psr_disable(struct intel_dp *intel_dp);
+extern void intel_edp_psr_update(struct drm_device *dev);
#endif /* __INTEL_DRV_H__ */
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/11] drm/i915: Add functions to force psr exit
PSR tracking engine in HSW doesn't detect automagically some directly copy area
operations through scanout so we will have to kick it manually and
reschedule it to come back to normal operation as soon as possible.
v2: Before PSR Hook. Don't force it when busy yet.
v3/v4: Solved small conflict.
v5: setup once function was already added on previous commit.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 46
drivers/gpu/drm/i915/intel_drv.h | 3 +++
3 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3bca337..dc10345 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1840,6 +1840,7 @@
#define EDP_PSR_PERF_CNT_MASK0xff
#define EDP_PSR_DEBUG_CTL 0x64860
+#define EDP_PSR_DEBUG_FORCE_EXIT (330)
#define EDP_PSR_DEBUG_MASK_LPSP (127)
#define EDP_PSR_DEBUG_MASK_MEMUP (126)
#define EDP_PSR_DEBUG_MASK_HPD (125)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3c9473c..cd168e6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1393,6 +1393,48 @@ bool intel_edp_is_psr_enabled(struct drm_device *dev)
return I915_READ(EDP_PSR_CTL) EDP_PSR_ENABLE;
}
+static void intel_edp_psr_delayed_normal_work(struct work_struct *__work)
+{
+ struct intel_dp *intel_dp = container_of(to_delayed_work(__work),
+struct intel_dp,
+edp_psr_delayed_normal_work);
+ struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ mutex_lock(intel_dp-psr_exit_mutex);
+ I915_WRITE(EDP_PSR_DEBUG_CTL, I915_READ(EDP_PSR_DEBUG_CTL)
+ ~EDP_PSR_DEBUG_FORCE_EXIT);
+ mutex_unlock(intel_dp-psr_exit_mutex);
+}
+
+void intel_edp_psr_force_exit(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_encoder *encoder;
+ struct intel_dp *intel_dp = NULL;
+
+ if (!intel_edp_is_psr_enabled(dev))
+ return;
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list, base.head)
+ if (encoder-type == INTEL_OUTPUT_EDP)
+ intel_dp = enc_to_intel_dp(encoder-base);
+
+ if (!intel_dp)
+ return;
+
+ if (WARN_ON(!intel_dp-psr_setup_done))
+ return;
+
+ mutex_lock(intel_dp-psr_exit_mutex);
+ I915_WRITE(EDP_PSR_DEBUG_CTL, I915_READ(EDP_PSR_DEBUG_CTL) |
+ EDP_PSR_DEBUG_FORCE_EXIT);
+ mutex_unlock(intel_dp-psr_exit_mutex);
+
+ schedule_delayed_work(intel_dp-edp_psr_delayed_normal_work,
+ msecs_to_jiffies(100));
+}
+
static void intel_edp_psr_write_vsc(struct intel_dp *intel_dp,
struct edp_vsc_psr *vsc_psr)
{
@@ -1443,6 +1485,10 @@ static void intel_edp_psr_setup(struct intel_dp
*intel_dp)
I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
EDP_PSR_DEBUG_MASK_HPD);
+ INIT_DELAYED_WORK(intel_dp-edp_psr_delayed_normal_work,
+ intel_edp_psr_delayed_normal_work);
+ mutex_init(intel_dp-psr_exit_mutex);
+
intel_dp-psr_setup_done = true;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0f52362..e47f3f3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -499,6 +499,8 @@ struct intel_dp {
int backlight_off_delay;
struct delayed_work panel_vdd_work;
bool want_panel_vdd;
+ struct delayed_work edp_psr_delayed_normal_work;
+ struct mutex psr_exit_mutex;
bool psr_setup_done;
struct intel_connector *attached_connector;
};
@@ -839,5 +841,6 @@ extern void intel_edp_psr_enable(struct intel_dp *intel_dp);
extern void intel_edp_psr_disable(struct intel_dp *intel_dp);
extern void intel_edp_psr_update(struct drm_device *dev);
extern bool intel_edp_is_psr_enabled(struct drm_device *dev);
+extern void intel_edp_psr_force_exit(struct drm_device *dev);
#endif /* __INTEL_DRV_H__ */
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/11] drm/i915: Adding global I915_PARAM for PSR ENABLED.
This global value allows userspace know when PSR is enabled.
This will allow userspace emit more busy_ioctl when doing directly copy_area
operations through scanout allowing forced psr exit.
v2: Check for PSR enabled instead of active. (by Chris Wilson)
v3: Use existing intel_edp_is_psr_enabled function.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6ce9033..1e5dd1c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1000,6 +1000,9 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_HAS_EXEC_HANDLE_LUT:
value = 1;
break;
+ case I915_PARAM_PSR_ENABLED:
+ value = intel_edp_is_psr_enabled(dev);
+ break;
default:
DRM_DEBUG(Unknown parameter %d\n, param-param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c0defaf..3c9473c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1383,7 +1383,7 @@ static bool is_edp_psr(struct intel_dp *intel_dp)
intel_dp-psr_dpcd[0] DP_PSR_IS_SUPPORTED;
}
-static bool intel_edp_is_psr_enabled(struct drm_device *dev)
+bool intel_edp_is_psr_enabled(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 40e955d..0f52362 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -838,5 +838,6 @@ extern bool intel_set_pch_fifo_underrun_reporting(struct
drm_device *dev,
extern void intel_edp_psr_enable(struct intel_dp *intel_dp);
extern void intel_edp_psr_disable(struct intel_dp *intel_dp);
extern void intel_edp_psr_update(struct drm_device *dev);
+extern bool intel_edp_is_psr_enabled(struct drm_device *dev);
#endif /* __INTEL_DRV_H__ */
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 923ed7f..a5db73b 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -310,6 +310,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_PINNED_BATCHES 24
#define I915_PARAM_HAS_EXEC_NO_RELOC25
#define I915_PARAM_HAS_EXEC_HANDLE_LUT 26
+#define I915_PARAM_PSR_ENABLED 27
typedef struct drm_i915_getparam {
int param;
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/11] drm/i915: Hook PSR functionality
PSR must be enabled after transcoder and port are running.
And it is only available for HSW.
v2: move enable/disable to intel_ddi
v3: The spec suggests PSR should be disabled even before backlight (by pzanoni)
v4: also disabling and enabling whenever panel is disabled/enabled.
v5: make it last patch to avoid breaking whenever bisecting. So calling for
update and force exit came to this patch along with enable/disable calls.
v6: Remove unused and unecessary psr_enable/disable calls, as notice by Paulo.
CC: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/intel_ddi.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 46bf7e3..703bc69 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3758,6 +3758,8 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
goto unlock;
}
+ intel_edp_psr_force_exit(dev);
+
/* Count all active objects as busy, even if they are currently not used
* by the gpu. Users of this interface expect objects to eventually
* become non-busy without any further actions, therefore emit any
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 324211a..4211925 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1117,6 +1117,7 @@ static void intel_enable_ddi(struct intel_encoder
*intel_encoder)
intel_dp_stop_link_train(intel_dp);
ironlake_edp_backlight_on(intel_dp);
+ intel_edp_psr_enable(intel_dp);
}
if (intel_crtc-eld_vld type != INTEL_OUTPUT_EDP) {
@@ -1147,6 +1148,7 @@ static void intel_disable_ddi(struct intel_encoder
*intel_encoder)
if (type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ intel_edp_psr_disable(intel_dp);
ironlake_edp_backlight_off(intel_dp);
}
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 10a3629..eb4e49b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2272,6 +2272,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
}
intel_update_fbc(dev);
+ intel_edp_psr_update(dev);
mutex_unlock(dev-struct_mutex);
intel_crtc_update_sarea_pos(crtc, x, y);
--
1.7.11.7
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: remove preliminary_hw_support variable
It's currently unused upstream, and just gets in the way internally. If things are really hosed for some reason on a given platform, users can still pass a bogus param to i915 to disable it (e.g. for installers with half baked hw support). But really, if that happens in practice, we've failed pretty hard to get things out and tested on time... Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/i915/i915_drv.c |5 - drivers/gpu/drm/i915/i915_drv.h |1 - 2 files changed, 6 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 0485f43..53eac49 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -118,11 +118,6 @@ module_param_named(i915_enable_ppgtt, i915_enable_ppgtt, int, 0600); MODULE_PARM_DESC(i915_enable_ppgtt, Enable PPGTT (default: true)); -unsigned int i915_preliminary_hw_support __read_mostly = 0; -module_param_named(preliminary_hw_support, i915_preliminary_hw_support, int, 0600); -MODULE_PARM_DESC(preliminary_hw_support, - Enable preliminary hardware support. (default: false)); - int i915_disable_power_well __read_mostly = 0; module_param_named(disable_power_well, i915_disable_power_well, int, 0600); MODULE_PARM_DESC(disable_power_well, diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 846500a..c1e268f 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1580,7 +1580,6 @@ extern int i915_enable_rc6 __read_mostly; extern int i915_enable_fbc __read_mostly; extern bool i915_enable_hangcheck __read_mostly; extern int i915_enable_ppgtt __read_mostly; -extern unsigned int i915_preliminary_hw_support __read_mostly; extern int i915_disable_power_well __read_mostly; extern int i915_enable_ips __read_mostly; extern bool i915_fastboot __read_mostly; -- 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 01/11] drm/i915: Move gtt and ppgtt under address space umbrella
On Thu, Jul 11, 2013 at 02:14:06PM +0300, Imre Deak wrote:
On Mon, 2013-07-08 at 23:08 -0700, Ben Widawsky wrote:
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions (insert entries), state (LRU lists) and
many of their characteristics (size), can be shared. Do that.
The change itself doesn't actually impact most of the VMA/VM rework
coming up, it just fits in with the grand scheme. GGTT will usually be a
special case where we either know an object must be in the GGTT (dislay
engine, workarounds, etc.).
v2: Drop usage of i915_gtt_vm (Daniel)
Make cleanup also part of the parent class (Ben)
Modified commit msg
Rebased
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_dma.c | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 57 ++---
drivers/gpu/drm/i915/i915_gem.c | 4 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 162
5 files changed, 121 insertions(+), 110 deletions(-)
[...]
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 242d0f9..693115a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -102,7 +102,7 @@ static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
static void gen6_write_pdes(struct i915_hw_ppgtt *ppgtt)
{
- struct drm_i915_private *dev_priv = ppgtt-dev-dev_private;
+ struct drm_i915_private *dev_priv = ppgtt-base.dev-dev_private;
gen6_gtt_pte_t __iomem *pd_addr;
uint32_t pd_entry;
int i;
@@ -181,18 +181,18 @@ static int gen6_ppgtt_enable(struct drm_device *dev)
}
/* PPGTT support for Sandybdrige/Gen6 and later */
-static void gen6_ppgtt_clear_range(struct i915_hw_ppgtt *ppgtt,
+static void gen6_ppgtt_clear_range(struct i915_address_space *vm,
unsigned first_entry,
unsigned num_entries)
{
- struct drm_i915_private *dev_priv = ppgtt-dev-dev_private;
+ struct i915_hw_ppgtt *ppgtt =
+ container_of(vm, struct i915_hw_ppgtt, base);
gen6_gtt_pte_t *pt_vaddr, scratch_pte;
unsigned act_pt = first_entry / I915_PPGTT_PT_ENTRIES;
unsigned first_pte = first_entry % I915_PPGTT_PT_ENTRIES;
unsigned last_pte, i;
- scratch_pte = ppgtt-pte_encode(dev_priv-gtt.scratch.addr,
- I915_CACHE_LLC);
+ scratch_pte = vm-pte_encode(vm-scratch.addr, I915_CACHE_LLC);
I only see ggtt's scratch page being initialized, but can't find the
corresponding init/teardown for ppgtt. Btw, why do we need separate
global/per-process scratch pages? (would be nice to add it to the commit
message)
--Imre
There is indeed a bug here, it existed somewhere, so I've mistakenly dropped
it. Here is my local fix, which is what I had done previously.
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 552e4cb..c8130db 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -295,6 +295,7 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
ppgtt-base.clear_range = gen6_ppgtt_clear_range;
ppgtt-base.bind_object = gen6_ppgtt_bind_object;
ppgtt-base.cleanup = gen6_ppgtt_cleanup;
+ ppgtt-base.scratch = dev_priv-gtt.base.scratch;
ppgtt-pt_pages = kzalloc(sizeof(struct page *)*ppgtt-num_pd_entries,
GFP_KERNEL);
if (!ppgtt-pt_pages)
Not sure what you mean, there should be only 1 scratch page now.
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/11] drm/i915: Create VMAs
On Thu, Jul 11, 2013 at 02:20:50PM +0300, Imre Deak wrote:
On Mon, 2013-07-08 at 23:08 -0700, Ben Widawsky wrote:
Formerly: drm/i915: Create VMAs (part 1)
In a previous patch, the notion of a VM was introduced. A VMA describes
an area of part of the VM address space. A VMA is similar to the concept
in the linux mm. However, instead of representing regular memory, a VMA
is backed by a GEM BO. There may be many VMAs for a given object, one
for each VM the object is to be used in. This may occur through flink,
dma-buf, or a number of other transient states.
Currently the code depends on only 1 VMA per object, for the global GTT
(and aliasing PPGTT). The following patches will address this and make
the rest of the infrastructure more suited
v2: s/i915_obj/i915_gem_obj (Chris)
v3: Only move an object to the now global unbound list if there are no
more VMAs for the object which are bound into a VM (ie. the list is
empty).
v4: killed obj-gtt_space
some reworks due to rebase
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h| 48 ++--
drivers/gpu/drm/i915/i915_gem.c| 57
+-
drivers/gpu/drm/i915/i915_gem_evict.c | 12 ---
drivers/gpu/drm/i915/i915_gem_gtt.c| 5 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 14 ++---
5 files changed, 110 insertions(+), 26 deletions(-)
[...]
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 525aa8f..058ad44 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2578,6 +2578,7 @@ int
i915_gem_object_unbind(struct drm_i915_gem_object *obj)
{
drm_i915_private_t *dev_priv = obj-base.dev-dev_private;
+ struct i915_vma *vma;
int ret;
if (!i915_gem_obj_ggtt_bound(obj))
@@ -2615,11 +2616,20 @@ i915_gem_object_unbind(struct drm_i915_gem_object
*obj)
i915_gem_object_unpin_pages(obj);
list_del(obj-mm_list);
- list_move_tail(obj-global_list, dev_priv-mm.unbound_list);
/* Avoid an unnecessary call to unbind on rebind. */
obj-map_and_fenceable = true;
- drm_mm_remove_node(obj-gtt_space);
+ vma = __i915_gem_obj_to_vma(obj);
+ list_del(vma-vma_link);
+ drm_mm_remove_node(vma-node);
+ i915_gem_vma_destroy(vma);
+
+ /* Since the unbound list is global, only move to that list if
+* no more VMAs exist.
+* NB: Until we have real VMAs there will only ever be one */
+ WARN_ON(!list_empty(obj-vma_list));
+ if (list_empty(obj-vma_list))
+ list_move_tail(obj-global_list, dev_priv-mm.unbound_list);
return 0;
}
@@ -3070,8 +3080,12 @@ i915_gem_object_bind_to_gtt(struct
drm_i915_gem_object *obj,
bool mappable, fenceable;
size_t gtt_max = map_and_fenceable ?
dev_priv-gtt.mappable_end : dev_priv-gtt.base.total;
+ struct i915_vma *vma;
int ret;
+ if (WARN_ON(!list_empty(obj-vma_list)))
+ return -EBUSY;
+
fence_size = i915_gem_get_gtt_size(dev,
obj-base.size,
obj-tiling_mode);
@@ -3110,9 +3124,15 @@ i915_gem_object_bind_to_gtt(struct
drm_i915_gem_object *obj,
i915_gem_object_pin_pages(obj);
+ vma = i915_gem_vma_create(obj, dev_priv-gtt.base);
+ if (vma == NULL) {
+ i915_gem_object_unpin_pages(obj);
+ return -ENOMEM;
+ }
+
search_free:
ret = drm_mm_insert_node_in_range_generic(dev_priv-gtt.base.mm,
- obj-gtt_space,
+ vma-node,
size, alignment,
obj-cache_level, 0, gtt_max);
if (ret) {
@@ -3126,22 +3146,23 @@ search_free:
i915_gem_object_unpin_pages(obj);
return ret;
}
- if (WARN_ON(!i915_gem_valid_gtt_space(dev, obj-gtt_space,
+ if (WARN_ON(!i915_gem_valid_gtt_space(dev, vma-node,
obj-cache_level))) {
i915_gem_object_unpin_pages(obj);
- drm_mm_remove_node(obj-gtt_space);
+ drm_mm_remove_node(vma-node);
return -EINVAL;
}
ret = i915_gem_gtt_prepare_object(obj);
if (ret) {
i915_gem_object_unpin_pages(obj);
- drm_mm_remove_node(obj-gtt_space);
+ drm_mm_remove_node(vma-node);
return ret;
}
Freeing vma on the error path is missing.
With this and the issue in 1/5 addressed things look good to me, so on
1-5:
Reviewed-by: Imre Deak imre.d...@intel.com
--Imre
Nice catch. Rebase fail. I feel no shame in making an excuse that it was
correct in the original series.
--
Ben Widawsky,
