Re: [Intel-gfx] [PATCH 03/17] drm/i915: Pin pages whilst mapping the dma-buf
On Fri, Aug 30, 2013 at 03:27:47PM +0100, Damien Lespiau wrote:
On Mon, Aug 26, 2013 at 07:50:55PM -0300, Rodrigo Vivi wrote:
From: Chris Wilson ch...@chris-wilson.co.uk
As we attempt to kmalloc after calling get_pages, there is a possibility
that the shrinker may reap the pages we just acquired. To prevent this
we need to increment the pages_pin_count early, so rearrange the code
and error paths to make it so.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
I've merged the three reviewed patches to dinq, thanks.
-Daniel
--
Damien
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 41
++
1 file changed, 22 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index e918b05..7d5752f 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -42,27 +42,24 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
ret = i915_mutex_lock_interruptible(obj-base.dev);
if (ret)
- return ERR_PTR(ret);
+ goto err;
ret = i915_gem_object_get_pages(obj);
- if (ret) {
- st = ERR_PTR(ret);
- goto out;
- }
+ if (ret)
+ goto err_unlock;
+
+ i915_gem_object_pin_pages(obj);
/* Copy sg so that we make an independent mapping */
st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
if (st == NULL) {
- st = ERR_PTR(-ENOMEM);
- goto out;
+ ret = -ENOMEM;
+ goto err_unpin;
}
ret = sg_alloc_table(st, obj-pages-nents, GFP_KERNEL);
- if (ret) {
- kfree(st);
- st = ERR_PTR(ret);
- goto out;
- }
+ if (ret)
+ goto err_free;
src = obj-pages-sgl;
dst = st-sgl;
@@ -73,17 +70,23 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
}
if (!dma_map_sg(attachment-dev, st-sgl, st-nents, dir)) {
- sg_free_table(st);
- kfree(st);
- st = ERR_PTR(-ENOMEM);
- goto out;
+ ret =-ENOMEM;
+ goto err_free_sg;
}
- i915_gem_object_pin_pages(obj);
-
-out:
mutex_unlock(obj-base.dev-struct_mutex);
return st;
+
+err_free_sg:
+ sg_free_table(st);
+err_free:
+ kfree(st);
+err_unpin:
+ i915_gem_object_unpin_pages(obj);
+err_unlock:
+ mutex_unlock(obj-base.dev-struct_mutex);
+err:
+ return ERR_PTR(ret);
}
static void i915_gem_unmap_dma_buf(struct dma_buf_attachment *attachment,
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 02/19] drm/i915: Call intel_update_watermarks() in specific place during modeset
On Fri, Aug 30, 2013 at 11:49:52PM +0300, Ville Syrjälä wrote: On Fri, Aug 30, 2013 at 05:26:29PM -0300, Paulo Zanoni wrote: 2013/8/30 ville.syrj...@linux.intel.com: From: Ville Syrjälä ville.syrj...@linux.intel.com Make the call to intel_update_watermarks() just once or twice during modeset. Ideally it should happen independently when each plane gets enabled/disabled, but for now it seems better to keep it in central place. We can improve things when we get all the planes sorted out in a better way. When enabling set up the watermarks just before the pipe is enabled. And when disabling we need to wait until we've marked the crtc as inactive. Why do we need to wait until we've marked the CRTC as inactive? (Daniel/Ville should put the answer in the commit message) Because the watermark compute code looks at intel_crtc-active. If we compute the watermarks before, the code thinks the pipe is active. Hmm. BTW now that I look at intel_crtc_active() I start to wonder why it looks at the clock in the user specified mode. In fact most (maybe all?) of the pre-hsw watermark code is fscked up and it looks at the wrong mode. Sigh. Suppose I need to make a quick for all that as well... That was a fallout from the partial modeset state recovery on boot-up - we've ended up doing divide-by-zeros since the pipe was marked as active but we've lacked the dotclock required to compute the new watermarks. So for those we've just skipped this. Since hsw still has no dotclock readout support we need to keep onto this hack for a while longer. But adding an XXX comment here would be useful. -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 0/2] vgaarb: Fixes for partial VGA opt-out
On Fri, Aug 30, 2013 at 03:41:19PM +0300, Ville Syrjälä wrote: On Thu, Aug 15, 2013 at 04:37:47PM -0600, Alex Williamson wrote: I'm trying to add support for VGA arbitration on newer Intel graphics devices. The existing code attempts to do this, but appear to have not been updated since GMCH devices roamed the Earth. On newer devices like Haswell, we can disable VGA memory through an MSR on the device, but we rely on the VGA arbiter to manage VGA IO using the PCI COMMAND register. In trying to unregister legacy VGA memory, I found that the VGA arbiter still wanted to disable both memory and IO on the device and that it forgot to actually program the device to disable IO when the decoding is updated. This series attempts to fix both of those. Thanks, The series looks good to me. Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com Merged to dinq with Dave's irc-ack. I'll shuffle my tree a bit so that this will be part of my 3.12 latecomers pull request to Dave. -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: Don't call sg_free_table() if sg_alloc_table() fails
On Fri, Aug 30, 2013 at 05:00:55PM +0100, Chris Wilson wrote: On Fri, Aug 30, 2013 at 03:39:26PM +0100, Damien Lespiau wrote: One needs to call __sg_free_table() if __sg_alloc_table() fails, but sg_alloc_table() does that for us already. Signed-off-by: Damien Lespiau damien.lesp...@intel.com Reviewd-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: It's its!
On Fri, Aug 30, 2013 at 03:26:30PM -0700, Ben Widawsky wrote: On Fri, Aug 30, 2013 at 02:40:26PM +0100, Damien Lespiau wrote: Signed-off-by: Damien Lespiau damien.lesp...@intel.com --- drivers/gpu/drm/i915/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 403309c..e038513 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -73,7 +73,7 @@ * * There are two confusing terms used above: * The current context means the context which is currently running on the - * GPU. The GPU has loaded it's state already and has stored away the gtt + * GPU. The GPU has loaded its state already and has stored away the gtt * offset of the BO. The GPU is not actively referencing the data at this * offset, but it will on the next context switch. The only way to avoid this * is to do a GPU reset. Acked-by: Ben Widawsky b...@bwidawsk.net Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Avoid i915 flip unpin/HPD event handler deadlock.
On Sat, Aug 31, 2013 at 10:15:25AM +0100, Chris Wilson wrote:
On Fri, Aug 30, 2013 at 06:30:55PM -0700, Stuart Abercrombie wrote:
Both of these were taking the mode_config mutex but executed from the
same work queue. If intel_crtc_page_flip happened to flush a work queue
containing an HPD event handler work item, deadlock resulted, since the
mutex required by the HPD handler was taken before the flush. Instead
use a separate work queue for the flip unpin work.
Signed-off-by: sabercrom...@chromium.org
Reviewed-by: marc...@chromium.org
It would be possible to rearrange the flip to drop the lock around the
flush (which is a regression from the kernel/workqueue.c refacting...).
However, this looks much simpler. In the long run being strict on
calling flush_workqueue() unlocked is likely to be safer though.
Reviewed-by; Chris Wilson ch...@chris-wilson.co.uk
Actually this is a regression from
commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Oct 23 18:23:34 2012 +
drm: run the hpd irq event code directly
and the fix is a bit simpler.
-Daniel
---
drivers/gpu/drm/i915/i915_dma.c | 21 -
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 4 ++--
3 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
index 4f129bb..9215360 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1558,6 +1558,22 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags)
goto out_mtrrfree;
}
+ /* intel_crtc_page_flip runs with the mode_config mutex having been
+* taken in the DRM layer. It synchronously waits for pending unpin
+* work items while holding this mutex. Therefore this queue cannot
+* contain work items that take this mutex, such as HPD event
+* handling, or we deadlock. There is also no reason for flipping to
+* wait on such events. Therefore put flip unpinning in its own
+* work queue.
+*/
+ dev_priv-flip_unpin_wq = alloc_ordered_workqueue(i915, 0);
+ if (dev_priv-flip_unpin_wq == NULL) {
+ DRM_ERROR(Failed to create flip unpin workqueue.\n);
+ destroy_workqueue(dev_priv-wq);
+ ret = -ENOMEM;
+ goto out_mtrrfree;
+ }
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev);
@@ -1628,6 +1644,7 @@ out_gem_unload:
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
destroy_workqueue(dev_priv-wq);
+ destroy_workqueue(dev_priv-flip_unpin_wq);
To be consistent, flip_wq then wq. In case we get ordering issues later.
-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
--
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] BUG: i830 flickering for horizontal panning
On Sat, Aug 31, 2013 at 05:40:09PM +0200, Thomas Richter wrote: Dear intel-gfx developers, panning on i830 based graphics seem to be working only half-ways. Vertical panning works fine, but horizontal panning flickers at about 60Hz frequency at specific pixel positions. The problem persists throughout kernel 3.10.9, and potentially later. How to reproduce: Enable panning, e.g. by xrandr --fb 2048x1536 xrandr --output DVI1 --panning 2048x1536 then scroll with the mouse slowly to the right. The affected hardware is *at least* this one: 00:02.0 VGA compatible controller: Intel Corporation 82830M/MG Integrated Graphics Controller (rev 04) as it is found in the Fujitsu-Siemens S2475 lifebook. The IBM Thinkpad R31 is also affected, it also contains a 830GM chipset graphics, but a different DVO. There is no specific output when flickering. The screen contents seems to be flickering between a dark frame and a frame that is half the way shifted correctly (left) and half the way a copy of the leftmost pixels of the screen on the right hand side. The kernel uses the i915 driver for this hardware. I currently don't see where precisely panning in the i915 sources is handled, thus I cannot really say what is necessary to support this correctly. Is this a regression? For your other bug reports we know that the modesetting support for i830M chipsets is a bit in a sorry state of affairs, search for 830 at bugs.freedesktop.org. Unfortunately time to really dig into this issues is hard to come by :( -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] [git pull] drm fixes
On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote: Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems to never come back. Sleep as in dpms off ($ xset dpms force off) or sleep as in system suspend? Any known issues with DVI on Haswell (it seems to show up as HDMI1 as the output, but it's a DVI cable)? I need to get a DP cable anyway (right now I'm driving my 2560x1440 display at 32Hz due to DVI crap) and maybe that will fix things, but this happens even if I don't force that odd mode (so it maxes out at 1920x1200 or whatever). I doubt this is new, but I've only ever run current -git on this machine, so who knows.. The machine ends up being kind of unusable. I guess I can just turn off power save. Hm, doesn't ring a bell here. Adding Paulo, our residential hsw display expert. Aside hsw hdmi ports support 300MHz dotclocks, but still only single-link. So I guess your dvi screen is still out of luck since it likely wants a dual-link dvi signal. But if you have a hdmi port it should work a bit better (hdmi pumped up the max dotclock a bit already a while ago ...). Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid flicker with horizontal panning on 830GM
On Sun, Sep 01, 2013 at 07:01:49PM +0200, Thomas Richter wrote: Dear intel-gfx developers, When panning is enabled on the 830GM, horizontal panning creates a lot of flickering on specific pixel positions. After testing, I found that the reason for this is that panning works by altering the frame origin pointer, which, however, has certain alignment restrictions. If the pointer is not aligned correctly, the screen starts to flicker as, probably, DMA fails. The following patch against drm/i915/intel_display.c fixes the issue by ensuring correct alignment. As result, horizontal panning works correctly, but is a bit jumpy. Unclear whether the problem affects any other chipset revisions, thus the patch is currently only enabled for rev.2. I've just looked at the docs and they only mention that the base address must be pixel aligned. But it could very well be that the watermarks are a bit off for your chipset. The below quick hack should test this theory. -Daniel diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dfdc7ad..990b1f4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1673,7 +1673,7 @@ static void i830_update_wm(struct drm_device *dev) dev_priv-display.get_fifo_size(dev, 0), 4, latency_ns); fwater_lo = I915_READ(FW_BLC) ~0xfff; - fwater_lo |= (38) | planea_wm; + fwater_lo |= (38) | 0; DRM_DEBUG_KMS(Setting FIFO watermarks - A: %d\n, planea_wm); -- 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 5/7] intel_gtt: Properly support gen6+ GTT PTEs
On Sun, Sep 01, 2013 at 12:51:24PM -0700, Ben Widawsky wrote:
This finishes the objective in the last patch which was to actually deal
with physical addresses, and not the PTEs.
GEN6+ Provided support for physical addresses above 4GB. I'm not
actually sure what Ironlake supported, and don't feel like firing up the
timemachine.
Haswell caveat is coming up next.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
gen4/5 and pnv/g33 simply have
+ pae = (phys 0xf0) 28;
+
+ return (phys | pae) ~0xfff;
Cheers, Daniel
---
tools/intel_gtt.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/tools/intel_gtt.c b/tools/intel_gtt.c
index 32a6618..874a4f6 100644
--- a/tools/intel_gtt.c
+++ b/tools/intel_gtt.c
@@ -25,6 +25,8 @@
*
*/
+#define __STDC_FORMAT_MACROS
+#include inttypes.h
#include stdio.h
#include stdlib.h
#include string.h
@@ -37,18 +39,26 @@
#define KB(x) ((x) * 1024)
#define MB(x) ((x) * 1024 * 1024)
unsigned char *gtt;
+uint32_t devid;
#define INGTT(offset) (*(volatile uint32_t *)(gtt + (offset) / (KB(4) / 4)))
static uint64_t get_phys(uint32_t pt_offset)
{
- return INGTT(pt_offset);
+ uint64_t pae = 0;
+ uint64_t phys = INGTT(pt_offset);
+
+ if (intel_gen(devid) 6)
+ return phys;
+
+ pae = (phys 0xff0) 28;
+
+ return (phys | pae) ~0xfff;
}
int main(int argc, char **argv)
{
struct pci_device *pci_dev;
int start, aper_size;
- uint32_t devid;
int flag[] = {
PCI_DEV_MAP_FLAG_WRITE_COMBINE,
PCI_DEV_MAP_FLAG_WRITABLE,
@@ -94,14 +104,14 @@ int main(int argc, char **argv)
aper_size = pci_dev-regions[2].size;
for (start = 0; start aper_size; start += KB(4)) {
- uint32_t start_phys = INGTT(start);
+ uint64_t start_phys = get_phys(start);
uint32_t end;
int constant_length = 0;
int linear_length = 0;
/* Check if it's a linear sequence */
for (end = start + KB(4); end aper_size; end += KB(4)) {
- uint32_t end_phys = INGTT(end);
+ uint64_t end_phys = get_phys(end);
if (end_phys == start_phys + (end - start))
linear_length++;
else
@@ -109,7 +119,7 @@ int main(int argc, char **argv)
}
if (linear_length 0) {
printf(0x%08x - 0x%08x: linear from
-0x%08x to 0x%08x\n,
+0x% PRIx64 to 0x% PRIx64 \n,
start, end - KB(4),
start_phys, start_phys + (end - start) - KB(4));
start = end - KB(4);
@@ -118,20 +128,20 @@ int main(int argc, char **argv)
/* Check if it's a constant sequence */
for (end = start + KB(4); end aper_size; end += KB(4)) {
- uint32_t end_phys = INGTT(end);
+ uint64_t end_phys = get_phys(end);
if (end_phys == start_phys)
constant_length++;
else
break;
}
if (constant_length 0) {
- printf(0x%08x - 0x%08x: constant 0x%08x\n,
+ printf(0x%08x - 0x%08x: constant 0x% PRIx64 \n,
start, end - KB(4), start_phys);
start = end - KB(4);
continue;
}
- printf(0x%08x: 0x%08x\n, start, start_phys);
+ printf(0x%08x: 0x% PRIx64 \n, start, start_phys);
}
return 0;
--
1.8.4
___
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 v(N+1)] drm/i915: add plumbing for SWSCI
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and
filters out any calls that shouldn't happen. This way the callers don't
need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set PCI_SWSCI bit 0 to trigger interrupt (Mengdong Lin)
v4: remove an extra #define (Jesse)
v5: spec says s/w is responsible for clearing PCI_SWSCI bit 0 too
v6: per Paulo's review and more:
- fix sub-function mask
- add exit parameter
- add define for set panel details call
- return more errors from swsci
- clean up the supported/requested callbacks bit masks mess
- use DSLP for timeout
- fix build for CONFIG_ACPI=n
v7: tiny adjustment of requested vs. supported SBCB callbacks handling (Paulo)
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_opregion.c | 199 -
2 files changed, 198 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0602c4b..67673e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -225,6 +225,8 @@ struct intel_opregion {
struct opregion_header __iomem *header;
struct opregion_acpi __iomem *acpi;
struct opregion_swsci __iomem *swsci;
+ u32 swsci_gbda_sub_functions;
+ u32 swsci_sbcb_sub_functions;
struct opregion_asle __iomem *asle;
void __iomem *vbt;
u32 __iomem *lid_state;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cfb8fb6..c45fec5 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -36,8 +36,11 @@
#include i915_drv.h
#include intel_drv.h
-#define PCI_ASLE 0xe4
-#define PCI_ASLS 0xfc
+#define PCI_ASLE 0xe4
+#define PCI_ASLS 0xfc
+#define PCI_SWSCI 0xe8
+#define PCI_SWSCI_SCISEL (1 15)
+#define PCI_SWSCI_GSSCIE (1 0)
#define OPREGION_HEADER_OFFSET 0
#define OPREGION_ACPI_OFFSET 0x100
@@ -151,6 +154,51 @@ struct opregion_asle {
#define ASLE_CBLV_VALID (131)
+/* Software System Control Interrupt (SWSCI) */
+#define SWSCI_SCIC_INDICATOR (1 0)
+#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
+#define SWSCI_SCIC_MAIN_FUNCTION_MASK (0xf 1)
+#define SWSCI_SCIC_SUB_FUNCTION_SHIFT 8
+#define SWSCI_SCIC_SUB_FUNCTION_MASK (0xff 8)
+#define SWSCI_SCIC_EXIT_PARAMETER_SHIFT8
+#define SWSCI_SCIC_EXIT_PARAMETER_MASK (0xff 8)
+#define SWSCI_SCIC_EXIT_STATUS_SHIFT 5
+#define SWSCI_SCIC_EXIT_STATUS_MASK(7 5)
+#define SWSCI_SCIC_EXIT_STATUS_SUCCESS 1
+
+#define SWSCI_FUNCTION_CODE(main, sub) \
+ ((main) SWSCI_SCIC_MAIN_FUNCTION_SHIFT | \
+(sub) SWSCI_SCIC_SUB_FUNCTION_SHIFT)
+
+/* SWSCI: Get BIOS Data (GBDA) */
+#define SWSCI_GBDA 4
+#define SWSCI_GBDA_SUPPORTED_CALLS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 0)
+#define SWSCI_GBDA_REQUESTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 1)
+#define SWSCI_GBDA_BOOT_DISPLAY_PREF SWSCI_FUNCTION_CODE(SWSCI_GBDA, 4)
+#define SWSCI_GBDA_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 5)
+#define SWSCI_GBDA_TV_STANDARD SWSCI_FUNCTION_CODE(SWSCI_GBDA, 6)
+#define SWSCI_GBDA_INTERNAL_GRAPHICS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 7)
+#define SWSCI_GBDA_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_GBDA, 10)
+
+/* SWSCI: System BIOS Callbacks (SBCB) */
+#define SWSCI_SBCB 6
+#define SWSCI_SBCB_SUPPORTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 0)
+#define SWSCI_SBCB_INIT_COMPLETION SWSCI_FUNCTION_CODE(SWSCI_SBCB, 1)
+#define SWSCI_SBCB_PRE_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 3)
+#define SWSCI_SBCB_POST_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 4)
+#define SWSCI_SBCB_DISPLAY_SWITCH SWSCI_FUNCTION_CODE(SWSCI_SBCB, 5)
+#define SWSCI_SBCB_SET_TV_FORMAT SWSCI_FUNCTION_CODE(SWSCI_SBCB, 6)
+#define SWSCI_SBCB_ADAPTER_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 7)
+#define SWSCI_SBCB_DISPLAY_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 8)
+#define SWSCI_SBCB_SET_BOOT_DISPLAYSWSCI_FUNCTION_CODE(SWSCI_SBCB, 9)
+#define SWSCI_SBCB_SET_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 10)
+#define SWSCI_SBCB_SET_INTERNAL_GFXSWSCI_FUNCTION_CODE(SWSCI_SBCB, 11)
+#define SWSCI_SBCB_POST_HIRES_TO_DOS_FSSWSCI_FUNCTION_CODE(SWSCI_SBCB,
16)
+#define SWSCI_SBCB_SUSPEND_RESUME SWSCI_FUNCTION_CODE(SWSCI_SBCB, 17)
+#define SWSCI_SBCB_SET_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 18)
+#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19)
+#define SWSCI_SBCB_ENABLE_DISABLE_AUDIOSWSCI_FUNCTION_CODE(SWSCI_SBCB,
21)
+
#define ACPI_OTHER_OUTPUT (08)
#define ACPI_VGA_OUTPUT (18)
#define ACPI_TV_OUTPUT (28)
@@ -158,6 +206,91 @@ struct opregion_asle {
#define ACPI_LVDS_OUTPUT (48)
#ifdef CONFIG_ACPI
+static
Re: [Intel-gfx] [PATCH] drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock
On Mon, Sep 02, 2013 at 08:49:01AM +0200, Daniel Vetter wrote: Historically we've run our own driver hotplug handling in our own work-queue, which then launched the drm core hotplug handling in the system workqueue. This is important since we flush our own driver workqueue in the pageflip code while hodling modeset locks, and only the drm hotplug code grabbed these locks. But with commit 69787f7da6b2adc4054357a661aaa1701a9ca76f Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Oct 23 18:23:34 2012 + drm: run the hpd irq event code directly this was changed and now we could deadlock in our flip handler if there's a hotplug work blocking the progress of the crucial unpin works. So this broke the careful deadlock avoidance implemented in commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Nov 1 09:26:26 2012 + drm/i915: Flush outstanding unpin tasks before pageflipping Since the rule thus far has been that work items on our own workqueue may never grab modeset locks simply restore that rule again. Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Stuart Abercrombie sabercrom...@chromium.org Reported-by: Stuart Abercrombie sabercrom...@chromium.org References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239 Cc: sta...@vger.kernel.org Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch That wins for simplicity, and it is indeed the only caller that requires mode_config.lock, so Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Bonus would a reminder in i915_drv.h to say that we cannot put items that require mode_config.lock onto the wq, and that they should go onto the global workqueue instead. -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 6/8] drm/i915: Add bind/unbind object functions to VM
On Fri, Aug 30, 2013 at 04:43:59PM -0700, Ben Widawsky wrote:
From: Ben Widawsky b...@bwidawsk.net
As we plumb the code with more VM information, it has become more
obvious that the easiest way to deal with bind and unbind is to simply
put the function pointers in the vm, and let those choose the correct
way to handle the page table updates. This change allows many places in
the code to simply be vm-bind, and not have to worry about
distinguishing PPGTT vs GGTT.
Notice that this patch has no impact on functionality. I've decided to
save the actual change until the next patch because I think it's easier
to review that way. I'm happy to squash the two, or let Daniel do it on
merge.
v2:
Make ggtt handle the quirky aliasing ppgtt
Add flags to bind object to support above
Don't ever call bind/unbind directly for PPGTT until we have real, full
PPGTT (use NULLs to assert this)
Make sure we rebind the ggtt if there already is a ggtt binding. This
happens on set cache levels
Use VMA for bind/unbind (Daniel, Ben)
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 69 +---
drivers/gpu/drm/i915/i915_gem_gtt.c | 101
2 files changed, 140 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9ed77a..377ca63 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -461,6 +461,36 @@ enum i915_cache_level {
typedef uint32_t gen6_gtt_pte_t;
+/**
+ * A VMA represents a GEM BO that is bound into an address space. Therefore,
a
+ * VMA's presence cannot be guaranteed before binding, or after unbinding the
+ * object into/from the address space.
+ *
+ * To make things as simple as possible (ie. no refcounting), a VMA's
lifetime
+ * will always be = an objects lifetime. So object refcounting should cover
us.
+ */
+struct i915_vma {
+ struct drm_mm_node node;
+ struct drm_i915_gem_object *obj;
+ struct i915_address_space *vm;
+
+ /** This object's place on the active/inactive lists */
+ struct list_head mm_list;
+
+ struct list_head vma_link; /* Link in the object's VMA list */
+
+ /** This vma's place in the batchbuffer or on the eviction list */
+ struct list_head exec_list;
+
+ /**
+ * Used for performing relocations during execbuffer insertion.
+ */
+ struct hlist_node exec_node;
+ unsigned long exec_handle;
+ struct drm_i915_gem_exec_object2 *exec_entry;
+
+};
+
struct i915_address_space {
struct drm_mm mm;
struct drm_device *dev;
@@ -499,9 +529,18 @@ struct i915_address_space {
/* FIXME: Need a more generic return type */
gen6_gtt_pte_t (*pte_encode)(dma_addr_t addr,
enum i915_cache_level level);
+
+ /** Unmap an object from an address space. This usually consists of
+ * setting the valid PTE entries to a reserved scratch page. */
+ void (*unbind_vma)(struct i915_vma *vma);
void (*clear_range)(struct i915_address_space *vm,
unsigned int first_entry,
unsigned int num_entries);
+ /* Map an object into an address space with the given cache flags. */
+#define GLOBAL_BIND (10)
+ void (*bind_vma)(struct i915_vma *vma,
+ enum i915_cache_level cache_level,
+ u32 flags);
void (*insert_entries)(struct i915_address_space *vm,
struct sg_table *st,
unsigned int first_entry,
@@ -548,36 +587,6 @@ struct i915_hw_ppgtt {
int (*enable)(struct drm_device *dev);
};
-/**
- * A VMA represents a GEM BO that is bound into an address space. Therefore,
a
- * VMA's presence cannot be guaranteed before binding, or after unbinding the
- * object into/from the address space.
- *
- * To make things as simple as possible (ie. no refcounting), a VMA's
lifetime
- * will always be = an objects lifetime. So object refcounting should cover
us.
- */
-struct i915_vma {
- struct drm_mm_node node;
- struct drm_i915_gem_object *obj;
- struct i915_address_space *vm;
-
- /** This object's place on the active/inactive lists */
- struct list_head mm_list;
-
- struct list_head vma_link; /* Link in the object's VMA list */
-
- /** This vma's place in the batchbuffer or on the eviction list */
- struct list_head exec_list;
-
- /**
- * Used for performing relocations during execbuffer insertion.
- */
- struct hlist_node exec_node;
- unsigned long exec_handle;
- struct drm_i915_gem_exec_object2 *exec_entry;
-
-};
-
struct i915_ctx_hang_stats {
/* This context had batch pending when hang was declared */
unsigned batch_pending;
diff --git
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Synchronize pread/pwrite with wait_rendering
On Mon, Sep 02, 2013 at 08:32:24AM +0200, Daniel Vetter wrote: On Fri, Aug 30, 2013 at 08:39:46PM -0700, Ben Widawsky wrote: On Sat, Aug 31, 2013 at 12:50:30AM +0100, Chris Wilson wrote: On Fri, Aug 30, 2013 at 04:43:54PM -0700, Ben Widawsky wrote: lifted from Daniel: pread/pwrite isn't about the object's domain at all, but purely about synchronizing for outstanding rendering. Replacing the call to set_to_gtt_domain with a wait_rendering would imo improve code readability. Furthermore we could pimp pread to only block for outstanding writes and not for reads. Since you're not the first one to trip over this: Can I volunteer you for a follow-up patch to fix this? Recommended-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Ben Widawsky b...@bwidawsk.net This should fail i-g-t... -Chris Daniel, how have I failed your plan? It should work ... Since the enclosing if-block checks for !cpu domain (for either reads or writes) that implies that going into the gtt domain is a noop (or better should be) wrt clflushing and we only wait for outstanding gpu rendering. wait_rendering is an interface that's been added afterwards. Unfortunately I've failed to explain this trickery in either a comment or the commit message. Bad me ;-) The issue is that in the patch pwrite is not waiting for any outstanding GPU reads. -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: Avoid flicker with horizontal panning on 830GM
Hi Daniel, I've just looked at the docs and they only mention that the base address must be pixel aligned. But it could very well be that the watermarks are a bit off for your chipset. The below quick hack should test this theory. -Daniel diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dfdc7ad..990b1f4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1673,7 +1673,7 @@ static void i830_update_wm(struct drm_device *dev) dev_priv-display.get_fifo_size(dev, 0), 4, latency_ns); fwater_lo = I915_READ(FW_BLC) ~0xfff; - fwater_lo |= (38) | planea_wm; + fwater_lo |= (38) | 0; DRM_DEBUG_KMS(Setting FIFO watermarks - A: %d\n, planea_wm); Checked with the above modifications. Unfortunately, the result is negative. With the above modifications and my changes commented out, the screen flickers in normal state (without panning) but in a different way: With the above enabled, you get a rather irregular almost pseudo-random flicker, and not the 60/30Hz flicker I see when panning horizontally. If I add horizontal panning, then I also get this irregular flicker, except when scrolling to the forbidden positions at which I get the regular hi-frequency flicker again. However, now that I checked closer, I found that my patch has also a drawback, namely the hardware scroll position and the requested scroll position disagrees, i.e. the mouse pointer is not exactly where it should be, i.e. the mouse pointer hot-spot is off. Is there a way to indicate the calling method what the actual panning/scroll position is if it is different from the requested position? Is there a different method to scroll the screen than to adjust the screen origin? Old hardware had not only a screen pointer, but also a pixel-offset (horizontal scroll) register. Is there something like this on the 830M to work around the observed trouble? Greetings, Thomas PS: A closer inspection shows that the screen flickers if the panning position x has the property that (x mod 16) != 0. Strange enough. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v(N+1)] drm/i915: add plumbing for SWSCI
2013/9/2 Jani Nikula jani.nik...@intel.com:
SWSCI is a driver to bios call interface.
This checks for SWSCI availability and bios requested callbacks, and
filters out any calls that shouldn't happen. This way the callers don't
need to do the checks all over the place.
v2: silence some checkpatch nagging
v3: set PCI_SWSCI bit 0 to trigger interrupt (Mengdong Lin)
v4: remove an extra #define (Jesse)
v5: spec says s/w is responsible for clearing PCI_SWSCI bit 0 too
v6: per Paulo's review and more:
- fix sub-function mask
- add exit parameter
- add define for set panel details call
- return more errors from swsci
- clean up the supported/requested callbacks bit masks mess
- use DSLP for timeout
- fix build for CONFIG_ACPI=n
v7: tiny adjustment of requested vs. supported SBCB callbacks handling (Paulo)
Signed-off-by: Jani Nikula jani.nik...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h |2 +
drivers/gpu/drm/i915/intel_opregion.c | 199
-
2 files changed, 198 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0602c4b..67673e2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -225,6 +225,8 @@ struct intel_opregion {
struct opregion_header __iomem *header;
struct opregion_acpi __iomem *acpi;
struct opregion_swsci __iomem *swsci;
+ u32 swsci_gbda_sub_functions;
+ u32 swsci_sbcb_sub_functions;
struct opregion_asle __iomem *asle;
void __iomem *vbt;
u32 __iomem *lid_state;
diff --git a/drivers/gpu/drm/i915/intel_opregion.c
b/drivers/gpu/drm/i915/intel_opregion.c
index cfb8fb6..c45fec5 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -36,8 +36,11 @@
#include i915_drv.h
#include intel_drv.h
-#define PCI_ASLE 0xe4
-#define PCI_ASLS 0xfc
+#define PCI_ASLE 0xe4
+#define PCI_ASLS 0xfc
+#define PCI_SWSCI 0xe8
+#define PCI_SWSCI_SCISEL (1 15)
+#define PCI_SWSCI_GSSCIE (1 0)
#define OPREGION_HEADER_OFFSET 0
#define OPREGION_ACPI_OFFSET 0x100
@@ -151,6 +154,51 @@ struct opregion_asle {
#define ASLE_CBLV_VALID (131)
+/* Software System Control Interrupt (SWSCI) */
+#define SWSCI_SCIC_INDICATOR (1 0)
+#define SWSCI_SCIC_MAIN_FUNCTION_SHIFT 1
+#define SWSCI_SCIC_MAIN_FUNCTION_MASK (0xf 1)
+#define SWSCI_SCIC_SUB_FUNCTION_SHIFT 8
+#define SWSCI_SCIC_SUB_FUNCTION_MASK (0xff 8)
+#define SWSCI_SCIC_EXIT_PARAMETER_SHIFT8
+#define SWSCI_SCIC_EXIT_PARAMETER_MASK (0xff 8)
+#define SWSCI_SCIC_EXIT_STATUS_SHIFT 5
+#define SWSCI_SCIC_EXIT_STATUS_MASK(7 5)
+#define SWSCI_SCIC_EXIT_STATUS_SUCCESS 1
+
+#define SWSCI_FUNCTION_CODE(main, sub) \
+ ((main) SWSCI_SCIC_MAIN_FUNCTION_SHIFT | \
+(sub) SWSCI_SCIC_SUB_FUNCTION_SHIFT)
+
+/* SWSCI: Get BIOS Data (GBDA) */
+#define SWSCI_GBDA 4
+#define SWSCI_GBDA_SUPPORTED_CALLS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 0)
+#define SWSCI_GBDA_REQUESTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 1)
+#define SWSCI_GBDA_BOOT_DISPLAY_PREF SWSCI_FUNCTION_CODE(SWSCI_GBDA, 4)
+#define SWSCI_GBDA_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 5)
+#define SWSCI_GBDA_TV_STANDARD SWSCI_FUNCTION_CODE(SWSCI_GBDA, 6)
+#define SWSCI_GBDA_INTERNAL_GRAPHICS SWSCI_FUNCTION_CODE(SWSCI_GBDA, 7)
+#define SWSCI_GBDA_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_GBDA, 10)
+
+/* SWSCI: System BIOS Callbacks (SBCB) */
+#define SWSCI_SBCB 6
+#define SWSCI_SBCB_SUPPORTED_CALLBACKS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 0)
+#define SWSCI_SBCB_INIT_COMPLETION SWSCI_FUNCTION_CODE(SWSCI_SBCB, 1)
+#define SWSCI_SBCB_PRE_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 3)
+#define SWSCI_SBCB_POST_HIRES_SET_MODE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 4)
+#define SWSCI_SBCB_DISPLAY_SWITCH SWSCI_FUNCTION_CODE(SWSCI_SBCB, 5)
+#define SWSCI_SBCB_SET_TV_FORMAT SWSCI_FUNCTION_CODE(SWSCI_SBCB, 6)
+#define SWSCI_SBCB_ADAPTER_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 7)
+#define SWSCI_SBCB_DISPLAY_POWER_STATE SWSCI_FUNCTION_CODE(SWSCI_SBCB, 8)
+#define SWSCI_SBCB_SET_BOOT_DISPLAYSWSCI_FUNCTION_CODE(SWSCI_SBCB, 9)
+#define SWSCI_SBCB_SET_PANEL_DETAILS SWSCI_FUNCTION_CODE(SWSCI_SBCB, 10)
+#define SWSCI_SBCB_SET_INTERNAL_GFXSWSCI_FUNCTION_CODE(SWSCI_SBCB, 11)
+#define SWSCI_SBCB_POST_HIRES_TO_DOS_FS
SWSCI_FUNCTION_CODE(SWSCI_SBCB, 16)
+#define SWSCI_SBCB_SUSPEND_RESUME SWSCI_FUNCTION_CODE(SWSCI_SBCB, 17)
+#define SWSCI_SBCB_SET_SPREAD_SPECTRUM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 18)
+#define SWSCI_SBCB_POST_VBE_PM SWSCI_FUNCTION_CODE(SWSCI_SBCB, 19)
+#define SWSCI_SBCB_ENABLE_DISABLE_AUDIO
SWSCI_FUNCTION_CODE(SWSCI_SBCB, 21)
Re: [Intel-gfx] [PATCH 1/6] drm/i915: expose intel_ddi_get_encoder_port()
On Fri, Aug 30, 2013 at 07:40:28PM +0300, Jani Nikula wrote:
In preparation for followup work.
Signed-off-by: Jani Nikula jani.nik...@intel.com
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com
Maintainer-bikeshed: I don't really see the value of export foo patches
since there's not much to judge them by. I prefer them squashed into the
first patch that starts to use it, maybe with a short note in the commit
message saying that something had to be exported.
-Daniel
---
drivers/gpu/drm/i915/intel_ddi.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index 63aca49..060ea50 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -58,7 +58,7 @@ static const u32 hsw_ddi_translations_fdi[] = {
0x00FF, 0x00040006 /* HDMI parameters */
};
-static enum port intel_ddi_get_encoder_port(struct intel_encoder
*intel_encoder)
+enum port intel_ddi_get_encoder_port(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = intel_encoder-base;
int type = intel_encoder-type;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index a38f5b2..5efb844 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -712,6 +712,7 @@ extern void intel_write_eld(struct drm_encoder *encoder,
extern void intel_prepare_ddi(struct drm_device *dev);
extern void hsw_fdi_link_train(struct drm_crtc *crtc);
extern void intel_ddi_init(struct drm_device *dev, enum port port);
+extern enum port intel_ddi_get_encoder_port(struct intel_encoder
*intel_encoder);
/* For use by IVB LP watermark workaround in intel_sprite.c */
extern void intel_update_watermarks(struct drm_device *dev);
--
1.7.10.4
___
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 5/6] drm/i915: do display power state notification on crtc enable/disable
On Fri, Aug 30, 2013 at 04:51:09PM -0300, Paulo Zanoni wrote: 2013/8/30 Jani Nikula jani.nik...@intel.com: The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference. Signed-off-by: Jani Nikula jani.nik...@intel.com Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com --- Paulo, still okay with the r-b? Yes :) Ok I've merged the first 6 patches from this series to dinq. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid flicker with horizontal panning on 830GM
On Mon, Sep 02, 2013 at 09:10:22AM +0200, Daniel Vetter wrote: On Sun, Sep 01, 2013 at 07:01:49PM +0200, Thomas Richter wrote: Dear intel-gfx developers, When panning is enabled on the 830GM, horizontal panning creates a lot of flickering on specific pixel positions. After testing, I found that the reason for this is that panning works by altering the frame origin pointer, which, however, has certain alignment restrictions. If the pointer is not aligned correctly, the screen starts to flicker as, probably, DMA fails. The following patch against drm/i915/intel_display.c fixes the issue by ensuring correct alignment. As result, horizontal panning works correctly, but is a bit jumpy. Unclear whether the problem affects any other chipset revisions, thus the patch is currently only enabled for rev.2. I've just looked at the docs and they only mention that the base address must be pixel aligned. I first thought this might be some issue w/ double wide mode (if it's enabled, not sure) but I don't see any relevant restrictions for double wide. But that investigation spurred me to write pipe config support for double wide mode. I'll post those after a quick smoke test. BTW my 855 isn't affected by this issue. First I though I was seeing something similar but it turns out I had set the fb size too big, so the ddx had to resort to copying. Another idea that I had was that I think 830 has a bit of wonkiness w/ the double buffered registers (latching happens regardless of DSPADDR writes, and reads use the the active set of registers). But I don't think that can explain your issue especially since DSPCNTR is the only register we read in set_base. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Synchronize pread/pwrite with wait_rendering
On Mon, Sep 02, 2013 at 02:14:12PM +0100, Chris Wilson wrote: On Mon, Sep 02, 2013 at 08:32:24AM +0200, Daniel Vetter wrote: On Fri, Aug 30, 2013 at 08:39:46PM -0700, Ben Widawsky wrote: On Sat, Aug 31, 2013 at 12:50:30AM +0100, Chris Wilson wrote: On Fri, Aug 30, 2013 at 04:43:54PM -0700, Ben Widawsky wrote: lifted from Daniel: pread/pwrite isn't about the object's domain at all, but purely about synchronizing for outstanding rendering. Replacing the call to set_to_gtt_domain with a wait_rendering would imo improve code readability. Furthermore we could pimp pread to only block for outstanding writes and not for reads. Since you're not the first one to trip over this: Can I volunteer you for a follow-up patch to fix this? Recommended-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Ben Widawsky b...@bwidawsk.net This should fail i-g-t... -Chris Daniel, how have I failed your plan? It should work ... Since the enclosing if-block checks for !cpu domain (for either reads or writes) that implies that going into the gtt domain is a noop (or better should be) wrt clflushing and we only wait for outstanding gpu rendering. wait_rendering is an interface that's been added afterwards. Unfortunately I've failed to explain this trickery in either a comment or the commit message. Bad me ;-) The issue is that in the patch pwrite is not waiting for any outstanding GPU reads. Oh right, silly me didn't spot the s/true/false/ switch Ben sneaked in. This /should/ have been caught by the gem_concurrent_blt subtests that exercise pwrites ... Ben can you please check that this indeed blew up on igt? Should fail on any platform, no special caching mode required. -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: Avoid flicker with horizontal panning on 830GM
On Mon, Sep 02, 2013 at 03:58:59PM +0200, Thomas Richter wrote: Hi Daniel, I've just looked at the docs and they only mention that the base address must be pixel aligned. But it could very well be that the watermarks are a bit off for your chipset. The below quick hack should test this theory. -Daniel diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dfdc7ad..990b1f4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1673,7 +1673,7 @@ static void i830_update_wm(struct drm_device *dev) dev_priv-display.get_fifo_size(dev, 0), 4, latency_ns); fwater_lo = I915_READ(FW_BLC) ~0xfff; -fwater_lo |= (38) | planea_wm; +fwater_lo |= (38) | 0; DRM_DEBUG_KMS(Setting FIFO watermarks - A: %d\n, planea_wm); Checked with the above modifications. Unfortunately, the result is negative. With the above modifications and my changes commented out, the screen flickers in normal state (without panning) but in a different way: With the above enabled, you get a rather irregular almost pseudo-random flicker, and not the 60/30Hz flicker I see when panning horizontally. If I add horizontal panning, then I also get this irregular flicker, except when scrolling to the forbidden positions at which I get the regular hi-frequency flicker again. Hm, I've probably botched the watermarks again. Can you please retest with the below diff? diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dfdc7ad..b667ff0 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1064,6 +1064,8 @@ static unsigned long intel_calculate_wm(unsigned long clock_in_khz, DRM_DEBUG_KMS(FIFO watermark level: %ld\n, wm_size); + wm_size = 0; + /* Don't promote wm_size to unsigned... */ if (wm_size (long)wm-max_wm) wm_size = wm-max_wm; However, now that I checked closer, I found that my patch has also a drawback, namely the hardware scroll position and the requested scroll position disagrees, i.e. the mouse pointer is not exactly where it should be, i.e. the mouse pointer hot-spot is off. Is there a way to indicate the calling method what the actual panning/scroll position is if it is different from the requested position? Is there a different method to scroll the screen than to adjust the screen origin? Old hardware had not only a screen pointer, but also a pixel-offset (horizontal scroll) register. Is there something like this on the 830M to work around the observed trouble? The kms api doesn't really allow for such information to be passed around. And since current userspace expects this to Just Work we need to be rather careful with such hacks. Since the docs don't mention any such requirement I think we should try a bit and figure out whether changing the watermarks fixes this. -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: Avoid flicker with horizontal panning on 830GM
On Mon, Sep 02, 2013 at 03:58:59PM +0200, Thomas Richter wrote: Hi Daniel, I've just looked at the docs and they only mention that the base address must be pixel aligned. But it could very well be that the watermarks are a bit off for your chipset. The below quick hack should test this theory. -Daniel diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dfdc7ad..990b1f4 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1673,7 +1673,7 @@ static void i830_update_wm(struct drm_device *dev) dev_priv-display.get_fifo_size(dev, 0), 4, latency_ns); fwater_lo = I915_READ(FW_BLC) ~0xfff; - fwater_lo |= (38) | planea_wm; + fwater_lo |= (38) | 0; DRM_DEBUG_KMS(Setting FIFO watermarks - A: %d\n, planea_wm); Checked with the above modifications. Unfortunately, the result is negative. With the above modifications and my changes commented out, the screen flickers in normal state (without panning) but in a different way: With the above enabled, you get a rather irregular almost pseudo-random flicker, and not the 60/30Hz flicker I see when panning horizontally. If I add horizontal panning, then I also get this irregular flicker, except when scrolling to the forbidden positions at which I get the regular hi-frequency flicker again. However, now that I checked closer, I found that my patch has also a drawback, namely the hardware scroll position and the requested scroll position disagrees, i.e. the mouse pointer is not exactly where it should be, i.e. the mouse pointer hot-spot is off. I suppose you could fix up the cursor position in the kernel to take into account the adjustment. But that's a bit iffy in my opinion since that makes big assumptions about what the user is intending to do with the the cursor. Ie. the user could just want to use the cursor to show some overlay at a fixed position on the display. Is there a way to indicate the calling method what the actual panning/scroll position is if it is different from the requested position? I guess you could update the crtc-x/y info and user space could then read them out after each setcrtc ioctl. Or you could simply hardcode the knowledge of this restriction to the ddx. Or maybe you could just return an error for setcrtc when the alignment is off. Not sure how the userspace will react to that though. It might still set the cursor to the wrong position. Is there a different method to scroll the screen than to adjust the screen origin? Old hardware had not only a screen pointer, but also a pixel-offset (horizontal scroll) register. Is there something like this on the 830M to work around the observed trouble? DSPADDR is the only register for this purpose. Greetings, Thomas PS: A closer inspection shows that the screen flickers if the panning position x has the property that (x mod 16) != 0. Strange enough. Does it depend on the bpp? -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock
Historically we've run our own driver hotplug handling in our own
work-queue, which then launched the drm core hotplug handling in the
system workqueue. This is important since we flush our own driver
workqueue in the pageflip code while hodling modeset locks, and only
the drm hotplug code grabbed these locks. But with
commit 69787f7da6b2adc4054357a661aaa1701a9ca76f
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Tue Oct 23 18:23:34 2012 +
drm: run the hpd irq event code directly
this was changed and now we could deadlock in our flip handler if
there's a hotplug work blocking the progress of the crucial unpin
works. So this broke the careful deadlock avoidance implemented in
commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Nov 1 09:26:26 2012 +
drm/i915: Flush outstanding unpin tasks before pageflipping
Since the rule thus far has been that work items on our own workqueue
may never grab modeset locks simply restore that rule again.
v2: Add a comment to the declaration of dev_priv-wq to warn readers
about the tricky implications of using it. Suggested by Chris Wilson.
Cc: Chris Wilson ch...@chris-wilson.co.uk
Cc: Stuart Abercrombie sabercrom...@chromium.org
Reported-by: Stuart Abercrombie sabercrom...@chromium.org
References:
http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/i915_irq.c | 3 +--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4da1f86..7bd1370 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1248,6 +1248,13 @@ typedef struct drm_i915_private {
unsigned int fsb_freq, mem_freq, is_ddr3;
+ /**
+* wq - Driver workqueue for GEM.
+*
+* NOTE: Work items scheduled here are not allowed to grab any modeset
+* locks, for otherwise the flushing done in the pageflip code will
+* result in deadlocks.
+*/
struct workqueue_struct *wq;
/* Display functions */
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4c6853f..39e4dd0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1027,8 +1027,7 @@ static inline void intel_hpd_irq_handler(struct
drm_device *dev,
dev_priv-display.hpd_irq_setup(dev);
spin_unlock(dev_priv-irq_lock);
- queue_work(dev_priv-wq,
- dev_priv-hotplug_work);
+ schedule_work(dev_priv-hotplug_work);
}
static void gmbus_irq_handler(struct drm_device *dev)
--
1.8.4.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid flicker with horizontal panning on 830GM
On 02.09.2013 16:18, Daniel Vetter wrote: Checked with the above modifications. Unfortunately, the result is negative. With the above modifications and my changes commented out, the screen flickers in normal state (without panning) but in a different way: With the above enabled, you get a rather irregular almost pseudo-random flicker, and not the 60/30Hz flicker I see when panning horizontally. If I add horizontal panning, then I also get this irregular flicker, except when scrolling to the forbidden positions at which I get the regular hi-frequency flicker again. Hm, I've probably botched the watermarks again. Can you please retest with the below diff? diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index dfdc7ad..b667ff0 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1064,6 +1064,8 @@ static unsigned long intel_calculate_wm(unsigned long clock_in_khz, DRM_DEBUG_KMS(FIFO watermark level: %ld\n, wm_size); + wm_size = 0; + /* Don't promote wm_size to unsigned... */ if (wm_size (long)wm-max_wm) wm_size = wm-max_wm; Not much difference, probably in the type of flicker. Very unstable, pseudo-random flicker at offset = 0, which gets a bit better for somewhat larger positions, but still the high-frequency flicker at forbidden positions. The flicker type definitely depends on the scroll position, but the high-freq flicker at (x 16) != 0 does not go away neither did it change in any way. )-: Only the flicker frequency at positions (x 16) == 0 did change, and then depends on (x 15). The kms api doesn't really allow for such information to be passed around. And since current userspace expects this to Just Work we need to be rather careful with such hacks. Since the docs don't mention any such requirement I think we should try a bit and figure out whether changing the watermarks fixes this. Is there anything I could do to confirm that the high-freq flicker is really due to watermarks? Since the above modifications do not really seem to work. It might also be that the amount of prefetch the FIFO requires depends on the memory alignment as in prefetch must occur starting from first 256-bit aligned position or something? Greetings, Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [git pull] drm fixes
On Sun, Sep 1, 2013 at 11:54 PM, Daniel Vetter dan...@ffwll.ch wrote: On Sat, Aug 31, 2013 at 04:02:16PM -0700, Linus Torvalds wrote: Hmm. I just updated my machine to a i7-4770S (kept everything else the same, just switched out motherboards), and now when my display goes to sleep, it seems to never come back. Sleep as in dpms off ($ xset dpms force off) or sleep as in system suspend? Just dpms off. Aside hsw hdmi ports support 300MHz dotclocks, but still only single-link. So I guess your dvi screen is still out of luck since it likely wants a dual-link dvi signal. But if you have a hdmi port it should work a bit better (hdmi pumped up the max dotclock a bit already a while ago ...). Well, with DP everything works without playing with refresh rates, and dpms off works too. So it's DVI-specific (I haven't tested an actual hdmi cable, I don't think I have any around), and it also happens even if I *don't* set odd refresh rates. But if others haven't seen it, it's probably not universal, I can't imagine that I'm the only one still using DVI (well, up until yesterday). This is a bog-standard micro-atx Intel motherboard: DH87RL with a i7-4770S CPU. Everything else seems to be just peachy. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/12] drm/i915: pipe_config, adjusted_mode vs. requested_mode, etc.
Currently parts of our code are really confused about which mode structure they should be looking at. A lot of the code never got converted to look at the pipe config modes, and for example the watermark code still managed to look at the wrong mode (crtc-mode, not even crtc-hwmode which would have been a bit better). So let's convert everything over to pipe config, and let's pretend the modes in drm_crtc don't even exist. Also in the pipe config conversion some bits of code were made to look at the requested_mode. If we have a fixed mode panel, requested_mode may contain all kinds of garbage and the only two things in it we should be looking at are hdisplay and vdisplay. Everything else should be interested in the adjusted_mode only. (S)DVO is a minor exception here as is wants to program the output timings with the requested_mode. I've left that stuff alone for now since it's essentially correct as is. In the end I decided that digging out hdisplay/vdisplay from requested_mode is just confusing. Instead I added explicit pipe source width/height members to pipe config. I was also considering adding primary plane size to make it clear which one we actually want in different places. But I opted not to do that. It should get sorted out when we move to drm_planes. After this there is no real need to poke around requested_mode anymore, so we could even consider removing it, or rather rename it to indicate that it's only relevant for (S)DVO. I also found some bugs in LVDS adjusted_mode vs. fixed_mode handling. It was causing the pipe config sanity checks to fail on my 855. So I ended up fixing that stuff as well. One extra idea that occured to me, is that we never actually update adjusted_mode-clock with the real clock value after we've found the PLL settings. I think that's something we should be doing since the PLL might not be able to give an exact match, and we use the clock to compute watermarks and check various hardware limits. But that's a patch for another day. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] drm/i915: Grab the pixel clock from adjusted_mode not requested_mode
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_crtc_compute_config() and i9xx_set_pipeconf() attempt to get
the current pixel clock from requested_mode. requested_mode.clock may
be totally bogus, so the clock should come from adjusted_mode.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ecb8b52..cab1319 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4124,8 +4124,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
if (HAS_PCH_SPLIT(dev)) {
/* FDI link clock is fixed at 2.7G */
- if (pipe_config-requested_mode.clock * 3
-IRONLAKE_FDI_FREQ * 4)
+ if (adjusted_mode-clock * 3 IRONLAKE_FDI_FREQ * 4)
return -EINVAL;
}
@@ -4812,7 +4811,7 @@ static void i9xx_set_pipeconf(struct intel_crtc
*intel_crtc)
* XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
* pipe == 0 check?
*/
- if (intel_crtc-config.requested_mode.clock
+ if (intel_crtc-config.adjusted_mode.clock
dev_priv-display.get_display_clock_speed(dev) * 9 / 10)
pipeconf |= PIPECONF_DOUBLE_WIDE;
}
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/12] drm/i915: Use adjusted_mode-clock in lpt_program_iclkip
From: Ville Syrjälä ville.syrj...@linux.intel.com
lpt_program_iclkip() wants to know the pixel clock. It should get that
information from adjusted_mode, not crtc-mode.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index cab1319..19b203c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2893,6 +2893,7 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
+ int clock = to_intel_crtc(crtc)-config.adjusted_mode.clock;
u32 divsel, phaseinc, auxdiv, phasedir = 0;
u32 temp;
@@ -2910,13 +2911,13 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
SBI_ICLK);
/* 20MHz is a corner case which is out of range for the 7-bit divisor */
- if (crtc-mode.clock == 2) {
+ if (clock == 2) {
auxdiv = 1;
divsel = 0x41;
phaseinc = 0x20;
} else {
/* The iCLK virtual clock root frequency is in MHz,
-* but the crtc-mode.clock in in KHz. To get the divisors,
+* but the adjusted_mode-clock in in KHz. To get the divisors,
* it is necessary to divide one by another, so we
* convert the virtual clock precision to KHz here for higher
* precision.
@@ -2925,7 +2926,7 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
u32 iclk_pi_range = 64;
u32 desired_divisor, msb_divisor_value, pi_value;
- desired_divisor = (iclk_virtual_root_freq / crtc-mode.clock);
+ desired_divisor = (iclk_virtual_root_freq / clock);
msb_divisor_value = desired_divisor / iclk_pi_range;
pi_value = desired_divisor % iclk_pi_range;
@@ -2941,7 +2942,7 @@ static void lpt_program_iclkip(struct drm_crtc *crtc)
~SBI_SSCDIVINTPHASE_INCVAL_MASK);
DRM_DEBUG_KMS(iCLKIP clock: found settings for %dKHz refresh rate:
auxdiv=%x, divsel=%x, phasedir=%x, phaseinc=%x\n,
- crtc-mode.clock,
+ clock,
auxdiv,
divsel,
phasedir,
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/12] drm/i915: Use adjusted_mode in intel_update_fbc()
From: Ville Syrjälä ville.syrj...@linux.intel.com
Check the mode flags from the adjusted_mode, not user requested mode.
The hdisplay/vdisplay check actually checkes the primary plane size,
so those still need to come from the user requested mode.
Extract both modes from pipe config instead of the drm_crtc.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0c115cc..af1f4de 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -458,6 +458,8 @@ void intel_update_fbc(struct drm_device *dev)
struct drm_framebuffer *fb;
struct intel_framebuffer *intel_fb;
struct drm_i915_gem_object *obj;
+ const struct drm_display_mode *mode;
+ const struct drm_display_mode *adjusted_mode;
unsigned int max_hdisplay, max_vdisplay;
if (!I915_HAS_FBC(dev)) {
@@ -502,6 +504,8 @@ void intel_update_fbc(struct drm_device *dev)
fb = crtc-fb;
intel_fb = to_intel_framebuffer(fb);
obj = intel_fb-obj;
+ mode = intel_crtc-config.requested_mode;
+ adjusted_mode = intel_crtc-config.adjusted_mode;
if (i915_enable_fbc 0
INTEL_INFO(dev)-gen = 7 !IS_HASWELL(dev)) {
@@ -514,8 +518,8 @@ void intel_update_fbc(struct drm_device *dev)
DRM_DEBUG_KMS(fbc disabled per module param\n);
goto out_disable;
}
- if ((crtc-mode.flags DRM_MODE_FLAG_INTERLACE) ||
- (crtc-mode.flags DRM_MODE_FLAG_DBLSCAN)) {
+ if ((adjusted_mode-flags DRM_MODE_FLAG_INTERLACE) ||
+ (adjusted_mode-flags DRM_MODE_FLAG_DBLSCAN)) {
if (set_no_fbc_reason(dev_priv, FBC_UNSUPPORTED_MODE))
DRM_DEBUG_KMS(mode incompatible with compression,
disabling\n);
@@ -529,8 +533,8 @@ void intel_update_fbc(struct drm_device *dev)
max_hdisplay = 2048;
max_vdisplay = 1536;
}
- if ((crtc-mode.hdisplay max_hdisplay) ||
- (crtc-mode.vdisplay max_vdisplay)) {
+ if ((mode-hdisplay max_hdisplay) ||
+ (mode-vdisplay max_vdisplay)) {
if (set_no_fbc_reason(dev_priv, FBC_MODE_TOO_LARGE))
DRM_DEBUG_KMS(mode too large for compression,
disabling\n);
goto out_disable;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/12] drm/i915: Use adjusted_mode in HDMI 12bpc clock check
From: Ville Syrjälä ville.syrj...@linux.intel.com The pixel clock should come from adjusted_mode not requested_mode. In this case the two should be the same as we don't currently overwrite the clock in the case of HDMI. But let's make the code safe against such things happening in the future. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 4148cc8..48e3b32 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -862,7 +862,7 @@ bool intel_hdmi_compute_config(struct intel_encoder *encoder, struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder-base); struct drm_device *dev = encoder-base.dev; struct drm_display_mode *adjusted_mode = pipe_config-adjusted_mode; - int clock_12bpc = pipe_config-requested_mode.clock * 3 / 2; + int clock_12bpc = pipe_config-adjusted_mode.clock * 3 / 2; int portclock_limit = hdmi_portclock_limit(intel_hdmi); int desired_bpp; -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/12] drm/i915: Use adjusted_mode appropriately when computing watermarks
From: Ville Syrjälä ville.syrj...@linux.intel.com
Currently most of the watermark code looks at crtc-mode which is the
user requested mode. The only piece of information there that is
relevant is hdisplay, the rest must come from adjusted_mode. Convert
all of the code to use requested_mode and adjusted_mode from
pipe config appropriately.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 55 -
1 file changed, 33 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index af1f4de..48d93d3 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1109,7 +1109,7 @@ static void pineview_update_wm(struct drm_device *dev)
crtc = single_enabled_crtc(dev);
if (crtc) {
- int clock = crtc-mode.clock;
+ int clock = to_intel_crtc(crtc)-config.adjusted_mode.clock;
int pixel_size = crtc-fb-bits_per_pixel / 8;
/* Display SR */
@@ -1170,6 +1170,7 @@ static bool g4x_compute_wm0(struct drm_device *dev,
int *cursor_wm)
{
struct drm_crtc *crtc;
+ const struct drm_display_mode *adjusted_mode;
int htotal, hdisplay, clock, pixel_size;
int line_time_us, line_count;
int entries, tlb_miss;
@@ -1181,9 +1182,10 @@ static bool g4x_compute_wm0(struct drm_device *dev,
return false;
}
- htotal = crtc-mode.htotal;
- hdisplay = crtc-mode.hdisplay;
- clock = crtc-mode.clock;
+ adjusted_mode = to_intel_crtc(crtc)-config.adjusted_mode;
+ clock = adjusted_mode-clock;
+ htotal = adjusted_mode-htotal;
+ hdisplay = to_intel_crtc(crtc)-config.requested_mode.hdisplay;
pixel_size = crtc-fb-bits_per_pixel / 8;
/* Use the small buffer method to calculate plane watermark */
@@ -1254,6 +1256,7 @@ static bool g4x_compute_srwm(struct drm_device *dev,
int *display_wm, int *cursor_wm)
{
struct drm_crtc *crtc;
+ const struct drm_display_mode *adjusted_mode;
int hdisplay, htotal, pixel_size, clock;
unsigned long line_time_us;
int line_count, line_size;
@@ -1266,9 +1269,10 @@ static bool g4x_compute_srwm(struct drm_device *dev,
}
crtc = intel_get_crtc_for_plane(dev, plane);
- hdisplay = crtc-mode.hdisplay;
- htotal = crtc-mode.htotal;
- clock = crtc-mode.clock;
+ adjusted_mode = to_intel_crtc(crtc)-config.adjusted_mode;
+ clock = adjusted_mode-clock;
+ htotal = adjusted_mode-htotal;
+ hdisplay = to_intel_crtc(crtc)-config.requested_mode.hdisplay;
pixel_size = crtc-fb-bits_per_pixel / 8;
line_time_us = (htotal * 1000) / clock;
@@ -1307,7 +1311,7 @@ static bool vlv_compute_drain_latency(struct drm_device
*dev,
if (!intel_crtc_active(crtc))
return false;
- clock = crtc-mode.clock; /* VESA DOT Clock */
+ clock = to_intel_crtc(crtc)-config.adjusted_mode.clock;
pixel_size = crtc-fb-bits_per_pixel / 8; /* BPP */
entries = (clock / 1000) * pixel_size;
@@ -1492,9 +1496,11 @@ static void i965_update_wm(struct drm_device *dev)
if (crtc) {
/* self-refresh has much higher latency */
static const int sr_latency_ns = 12000;
- int clock = crtc-mode.clock;
- int htotal = crtc-mode.htotal;
- int hdisplay = crtc-mode.hdisplay;
+ const struct drm_display_mode *adjusted_mode =
+ to_intel_crtc(crtc)-config.adjusted_mode;
+ int clock = adjusted_mode-clock;
+ int htotal = adjusted_mode-htotal;
+ int hdisplay =
to_intel_crtc(crtc)-config.requested_mode.hdisplay;
int pixel_size = crtc-fb-bits_per_pixel / 8;
unsigned long line_time_us;
int entries;
@@ -1570,7 +1576,7 @@ static void i9xx_update_wm(struct drm_device *dev)
if (IS_GEN2(dev))
cpp = 4;
- planea_wm = intel_calculate_wm(crtc-mode.clock,
+ planea_wm =
intel_calculate_wm(to_intel_crtc(crtc)-config.adjusted_mode.clock,
wm_info, fifo_size, cpp,
latency_ns);
enabled = crtc;
@@ -1584,7 +1590,7 @@ static void i9xx_update_wm(struct drm_device *dev)
if (IS_GEN2(dev))
cpp = 4;
- planeb_wm = intel_calculate_wm(crtc-mode.clock,
+ planeb_wm =
intel_calculate_wm(to_intel_crtc(crtc)-config.adjusted_mode.clock,
wm_info, fifo_size, cpp,
latency_ns);
if (enabled == NULL)
@@
[Intel-gfx] [PATCH 06/12] drm/i915: Check the clock from adjusted mode in intel_crtc_active()
From: Ville Syrjälä ville.syrj...@linux.intel.com
The clock in crtc-mode doesn't necessarily mean anything. Let's look
at the clock in adjusted_mode instead.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 48d93d3..397628b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -45,10 +45,13 @@
static bool intel_crtc_active(struct drm_crtc *crtc)
{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
/* Be paranoid as we can arrive here with only partial
* state retrieved from the hardware during setup.
*/
- return to_intel_crtc(crtc)-active crtc-fb crtc-mode.clock;
+ return intel_crtc-active crtc-fb
+ intel_crtc-config.adjusted_mode.clock;
}
static void i8xx_disable_fbc(struct drm_device *dev)
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/12] drm/i915: Use adjusted_mode when checking conditions for PSR
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_edp_psr_match_conditions() currently looks at crtc-mode
when it really needs to look at adjusted_mode. Fix it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2151d13..e2cb650 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1555,7 +1555,8 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
}
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc-active || !crtc-fb || !crtc-mode.clock) {
+ if (!intel_crtc-active || !crtc-fb ||
+ !intel_crtc-config.adjusted_mode.clock) {
DRM_DEBUG_KMS(crtc not active for PSR\n);
dev_priv-no_psr_reason = PSR_CRTC_NOT_ACTIVE;
return false;
@@ -1582,7 +1583,7 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
return false;
}
- if (crtc-mode.flags DRM_MODE_FLAG_INTERLACE) {
+ if (intel_crtc-config.adjusted_mode.flags DRM_MODE_FLAG_INTERLACE) {
DRM_DEBUG_KMS(PSR condition failed: Interlaced is Enabled\n);
dev_priv-no_psr_reason = PSR_INTERLACED_ENABLED;
return false;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/12] drm/i915: Use adjusted_mode in DSI PLL calculations
From: Ville Syrjälä ville.syrj...@linux.intel.com
adjusted_mode contains our real timings, not requested_mode. Use the
correct thing in DSI PLL code.
Also constify adjusted_mode since we don't change it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dsi_pll.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_pll.c
b/drivers/gpu/drm/i915/intel_dsi_pll.c
index 582f626..44279b2 100644
--- a/drivers/gpu/drm/i915/intel_dsi_pll.c
+++ b/drivers/gpu/drm/i915/intel_dsi_pll.c
@@ -50,7 +50,7 @@ static const u32 lfsr_converts[] = {
71, 35 /* 91 - 92 */
};
-static u32 dsi_rr_formula(struct drm_display_mode *mode,
+static u32 dsi_rr_formula(const struct drm_display_mode *mode,
int pixel_format, int video_mode_format,
int lane_count, bool eotp)
{
@@ -245,7 +245,7 @@ static void vlv_configure_dsi_pll(struct intel_encoder
*encoder)
{
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder-base.crtc);
- struct drm_display_mode *mode = intel_crtc-config.requested_mode;
+ const struct drm_display_mode *mode = intel_crtc-config.adjusted_mode;
struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder-base);
int ret;
struct dsi_mnp dsi_mnp;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/12] drm/i915: Make intel_crtc_active() available outside intel_pm.c
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move intel_crtc_active() to intel_display.c and make it available
elsewhere as well.
intel_edp_psr_match_conditions() already has one open coded copy,
so replace that one with a call to intel_crtc_active().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
drivers/gpu/drm/i915/intel_dp.c | 3 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 11 ---
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 19b203c..f49dbe8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -751,6 +751,17 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct
drm_crtc *crtc,
return true;
}
+bool intel_crtc_active(struct drm_crtc *crtc)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+ /* Be paranoid as we can arrive here with only partial
+* state retrieved from the hardware during setup.
+*/
+ return intel_crtc-active crtc-fb
+ intel_crtc-config.adjusted_mode.clock;
+}
+
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e2cb650..5ce5968 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1555,8 +1555,7 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
}
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc-active || !crtc-fb ||
- !intel_crtc-config.adjusted_mode.clock) {
+ if (!intel_crtc_active(crtc)) {
DRM_DEBUG_KMS(crtc not active for PSR\n);
dev_priv-no_psr_reason = PSR_CRTC_NOT_ACTIVE;
return false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5efb844..e017c30 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -798,5 +798,6 @@ extern void hsw_pc8_disable_interrupts(struct drm_device
*dev);
extern void hsw_pc8_restore_interrupts(struct drm_device *dev);
extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
+extern bool intel_crtc_active(struct drm_crtc *crtc);
#endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 397628b..3ba412c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -43,17 +43,6 @@
* i915.i915_enable_fbc parameter
*/
-static bool intel_crtc_active(struct drm_crtc *crtc)
-{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
- /* Be paranoid as we can arrive here with only partial
-* state retrieved from the hardware during setup.
-*/
- return intel_crtc-active crtc-fb
- intel_crtc-config.adjusted_mode.clock;
-}
-
static void i8xx_disable_fbc(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/12] drm/i915: Add explicit pipe src size to pipe config
From: Ville Syrjälä ville.syrj...@linux.intel.com Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 26 +++-- drivers/gpu/drm/i915/intel_drv.h | 3 ++ drivers/gpu/drm/i915/intel_panel.c | 56 +--- drivers/gpu/drm/i915/intel_pm.c | 33 ++--- drivers/gpu/drm/i915/intel_sprite.c | 4 +-- 5 files changed, 64 insertions(+), 58 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f49dbe8..17fe7ed 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4692,7 +4692,6 @@ static void intel_set_pipe_timings(struct intel_crtc *intel_crtc) enum transcoder cpu_transcoder = intel_crtc-config.cpu_transcoder; struct drm_display_mode *adjusted_mode = intel_crtc-config.adjusted_mode; - struct drm_display_mode *mode = intel_crtc-config.requested_mode; uint32_t vsyncshift, crtc_vtotal, crtc_vblank_end; /* We need to be careful not to changed the adjusted mode, for otherwise @@ -4745,7 +4744,8 @@ static void intel_set_pipe_timings(struct intel_crtc *intel_crtc) * always be the user's requested size. */ I915_WRITE(PIPESRC(pipe), - ((mode-hdisplay - 1) 16) | (mode-vdisplay - 1)); + ((intel_crtc-config.pipe_src_w - 1) 16) | + (intel_crtc-config.pipe_src_h - 1)); } static void intel_get_pipe_timings(struct intel_crtc *crtc, @@ -4783,8 +4783,11 @@ static void intel_get_pipe_timings(struct intel_crtc *crtc, } tmp = I915_READ(PIPESRC(crtc-pipe)); - pipe_config-requested_mode.vdisplay = (tmp 0x) + 1; - pipe_config-requested_mode.hdisplay = ((tmp 16) 0x) + 1; + pipe_config-pipe_src_h = (tmp 0x) + 1; + pipe_config-pipe_src_w = ((tmp 16) 0x) + 1; + + pipe_config-requested_mode.vdisplay = pipe_config-pipe_src_h; + pipe_config-requested_mode.hdisplay = pipe_config-pipe_src_w; } static void intel_crtc_mode_from_pipe_config(struct intel_crtc *intel_crtc, @@ -4880,7 +4883,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - struct drm_display_mode *mode = intel_crtc-config.requested_mode; int pipe = intel_crtc-pipe; int plane = intel_crtc-plane; int refclk, num_connectors = 0; @@ -4978,8 +4980,8 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, * which should always be the user's requested size. */ I915_WRITE(DSPSIZE(plane), - ((mode-vdisplay - 1) 16) | - (mode-hdisplay - 1)); + ((intel_crtc-config.pipe_src_h - 1) 16) | + (intel_crtc-config.pipe_src_w - 1)); I915_WRITE(DSPPOS(plane), 0); i9xx_set_pipeconf(intel_crtc); @@ -8255,6 +8257,8 @@ static void intel_dump_pipe_config(struct intel_crtc *crtc, drm_mode_debug_printmodeline(pipe_config-requested_mode); DRM_DEBUG_KMS(adjusted mode:\n); drm_mode_debug_printmodeline(pipe_config-adjusted_mode); + DRM_DEBUG_KMS(pipe src size: %dx%d\n, + pipe_config-pipe_src_w, pipe_config-pipe_src_h); DRM_DEBUG_KMS(gmch pfit: control: 0x%08x, ratios: 0x%08x, lvds border: 0x%08x\n, pipe_config-gmch_pfit.control, pipe_config-gmch_pfit.pgm_ratios, @@ -8306,6 +8310,10 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, drm_mode_copy(pipe_config-adjusted_mode, mode); drm_mode_copy(pipe_config-requested_mode, mode); + + pipe_config-pipe_src_w = mode-hdisplay; + pipe_config-pipe_src_h = mode-vdisplay; + pipe_config-cpu_transcoder = (enum transcoder) to_intel_crtc(crtc)-pipe; pipe_config-shared_dpll = DPLL_ID_PRIVATE; @@ -8649,8 +8657,8 @@ intel_pipe_config_compare(struct drm_device *dev, DRM_MODE_FLAG_NVSYNC); } - PIPE_CONF_CHECK_I(requested_mode.hdisplay); - PIPE_CONF_CHECK_I(requested_mode.vdisplay); + PIPE_CONF_CHECK_I(pipe_src_w); + PIPE_CONF_CHECK_I(pipe_src_h); PIPE_CONF_CHECK_I(gmch_pfit.control); /* pfit ratios are autocomputed by the hw on gen4+ */ diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index e017c30..594d9f4 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@
[Intel-gfx] [PATCH 09/12] drm/i915: Use pipe config in sprite code
From: Ville Syrjälä ville.syrj...@linux.intel.com
Rather than dig up the pipe source size from crtc-mode, use
intel_crtc-config.requested_mode.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index ad6ec4b..753cef3 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -652,8 +652,8 @@ intel_update_plane(struct drm_plane *plane, struct drm_crtc
*crtc,
.y2 = crtc_y + crtc_h,
};
const struct drm_rect clip = {
- .x2 = crtc-mode.hdisplay,
- .y2 = crtc-mode.vdisplay,
+ .x2 = intel_crtc-config.requested_mode.hdisplay,
+ .y2 = intel_crtc-config.requested_mode.vdisplay,
};
intel_fb = to_intel_framebuffer(fb);
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/12] drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode
only partially. Notably it forgot to copy over the sync flags. The LVDS
code however programmed the hardware with the sync flags from fixed
mode, and then later the pipe config comparison obviously failed as we
filled out the adjusted_mode in get_config from the real registers.
Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the
whole thing, and then just use adjusted_mode in the LVDS code to figure
out which sync settings the hardware needs.
Also constify the fixed_mode argument to intel_fixed_panel_mode().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_lvds.c | 8
drivers/gpu/drm/i915/intel_panel.c | 14 ++
3 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 594d9f4..a71b47c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -559,7 +559,7 @@ extern int intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *fixed_mode);
extern void intel_panel_fini(struct intel_panel *panel);
-extern void intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
+extern void intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode);
extern void intel_pch_panel_fitting(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config,
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 4d33278..831a5c0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -128,8 +128,8 @@ static void intel_pre_enable_lvds(struct intel_encoder
*encoder)
struct drm_device *dev = encoder-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc = to_intel_crtc(encoder-base.crtc);
- struct drm_display_mode *fixed_mode =
- lvds_encoder-attached_connector-base.panel.fixed_mode;
+ const struct drm_display_mode *adjusted_mode =
+ crtc-config.adjusted_mode;
int pipe = crtc-pipe;
u32 temp;
@@ -183,9 +183,9 @@ static void intel_pre_enable_lvds(struct intel_encoder
*encoder)
temp = ~LVDS_ENABLE_DITHER;
}
temp = ~(LVDS_HSYNC_POLARITY | LVDS_VSYNC_POLARITY);
- if (fixed_mode-flags DRM_MODE_FLAG_NHSYNC)
+ if (adjusted_mode-flags DRM_MODE_FLAG_NHSYNC)
temp |= LVDS_HSYNC_POLARITY;
- if (fixed_mode-flags DRM_MODE_FLAG_NVSYNC)
+ if (adjusted_mode-flags DRM_MODE_FLAG_NVSYNC)
temp |= LVDS_VSYNC_POLARITY;
I915_WRITE(lvds_encoder-reg, temp);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index c361f04..c9dba46 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -36,20 +36,10 @@
#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
void
-intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
+intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
{
- adjusted_mode-hdisplay = fixed_mode-hdisplay;
- adjusted_mode-hsync_start = fixed_mode-hsync_start;
- adjusted_mode-hsync_end = fixed_mode-hsync_end;
- adjusted_mode-htotal = fixed_mode-htotal;
-
- adjusted_mode-vdisplay = fixed_mode-vdisplay;
- adjusted_mode-vsync_start = fixed_mode-vsync_start;
- adjusted_mode-vsync_end = fixed_mode-vsync_end;
- adjusted_mode-vtotal = fixed_mode-vtotal;
-
- adjusted_mode-clock = fixed_mode-clock;
+ drm_mode_copy(adjusted_mode, fixed_mode);
drm_mode_set_crtcinfo(adjusted_mode, 0);
}
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Fix cursor visibility check with negative coordinates
From: Ville Syrjälä ville.syrj...@linux.intel.com
When the cursor x coordinate is exactly -cursor_width, the cursor is
invisible. And obviously the same holds for the y coordinate and
cursor_height.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.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 17fe7ed..42e65ce 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6857,7 +6857,7 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
base = 0;
if (x 0) {
- if (x + intel_crtc-cursor_width 0)
+ if (x + intel_crtc-cursor_width = 0)
base = 0;
pos |= CURSOR_POS_SIGN CURSOR_X_SHIFT;
@@ -6866,7 +6866,7 @@ static void intel_crtc_update_cursor(struct drm_crtc
*crtc,
pos |= x CURSOR_X_SHIFT;
if (y 0) {
- if (y + intel_crtc-cursor_height 0)
+ if (y + intel_crtc-cursor_height = 0)
base = 0;
pos |= CURSOR_POS_SIGN CURSOR_Y_SHIFT;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] drm/i915: Double wide pipe config
I was suspecting double wide to be the cause of a bug report, and so started digging a bit. Sadly it looks like that bug is caused by something else, but I did end up fixing a double wide related bug anyway. The resulting series is here. It needs to be applied after the pipe config fixes seried I just posted since I'm using the new pipe_src_w in this series. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Move double wide mode handling into pipe_config
From: Ville Syrjälä ville.syrj...@linux.intel.com
Determine the need for double wide mode already in compute_config
stage as we need that information to figure out if horizontal
coordinates need to be adjusted.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 31 ---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 42e65ce..563c0bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4140,6 +4140,23 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
return -EINVAL;
}
+ if (INTEL_INFO(dev)-gen 4) {
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ int clock_limit =
+ dev_priv-display.get_display_clock_speed(dev);
+
+ /*
+* Enable pixel doubling when the dot clock
+* is 90% of the (display) core speed.
+*
+* XXX: No double-wide on 915GM pipe B. Is that
+* the only reason for the pipe == PIPE_A check?
+*/
+ if (crtc-pipe == PIPE_A
+ adjusted_mode-clock clock_limit * 9 / 10)
+ pipe_config-double_wide = true;
+ }
+
/* Cantiga+ cannot handle modes with a hsync front porch of 0.
* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
*/
@@ -4819,17 +4836,8 @@ static void i9xx_set_pipeconf(struct intel_crtc
*intel_crtc)
pipeconf = 0;
- if (intel_crtc-pipe == 0 INTEL_INFO(dev)-gen 4) {
- /* Enable pixel doubling when the dot clock is 90% of the
(display)
-* core speed.
-*
-* XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
-* pipe == 0 check?
-*/
- if (intel_crtc-config.adjusted_mode.clock
- dev_priv-display.get_display_clock_speed(dev) * 9 / 10)
- pipeconf |= PIPECONF_DOUBLE_WIDE;
- }
+ if (intel_crtc-config.double_wide)
+ pipeconf |= PIPECONF_DOUBLE_WIDE;
/* only g4x and later have fancy bpc/dither controls */
if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
@@ -8267,6 +8275,7 @@ static void intel_dump_pipe_config(struct intel_crtc
*crtc,
pipe_config-pch_pfit.pos,
pipe_config-pch_pfit.size);
DRM_DEBUG_KMS(ips: %i\n, pipe_config-ips_enabled);
+ DRM_DEBUG_KMS(double wide: %i\n, pipe_config-double_wide);
}
static bool check_encoder_cloning(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a71b47c..512dccd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -294,6 +294,8 @@ struct intel_crtc_config {
struct intel_link_m_n fdi_m_n;
bool ips_enabled;
+
+ bool double_wide;
};
struct intel_crtc {
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Add double_wide readout and checking
From: Ville Syrjälä ville.syrj...@linux.intel.com Read the double wide pipe information from hardware in i9xx_get_pipe_config(), and check it in intel_pipe_config_compare() For gen4+ double_wide is always false so the comparison can be done on all platforms. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 563c0bc..ea33468 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -5045,6 +5045,9 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc, if (!(tmp PIPECONF_ENABLE)) return false; + if (INTEL_INFO(dev)-gen 4) + pipe_config-double_wide = tmp PIPECONF_DOUBLE_WIDE; + intel_get_pipe_timings(crtc, pipe_config); i9xx_get_pfit_config(crtc, pipe_config); @@ -8679,6 +8682,8 @@ intel_pipe_config_compare(struct drm_device *dev, PIPE_CONF_CHECK_I(ips_enabled); + PIPE_CONF_CHECK_I(double_wide); + PIPE_CONF_CHECK_I(shared_dpll); PIPE_CONF_CHECK_X(dpll_hw_state.dpll); PIPE_CONF_CHECK_X(dpll_hw_state.dpll_md); -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4
From: Ville Syrjälä ville.syrj...@linux.intel.com
We don't want to try to push the hardware beyond it's capabilities,
so check the pixel clock against the display core clock limit. Do
it for pre-gen4 for now since that's where we alread have the double
wide pixel clock limit check.
Let's assume that when double wide mode is enabled the max
pixel clock limit is also doubled.
FIXME: panel fitter downscaling probably affects the limit on
non-pch platforms too, so we'd need another version of
ilk_pipe_pixel_rate() to figure that out.
FIXME: should check the limits on all platforms. Also sprites
affect the max allowed pixel rate on some platforms, so we need
to eventually tie all the planes and pipes into one check in
the future. But we need plane state pre-compute before that can
happen.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ea33468..040e0ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
return -EINVAL;
}
+ /* FIXME should check pixel clock limits on all platforms */
if (INTEL_INFO(dev)-gen 4) {
struct drm_i915_private *dev_priv = dev-dev_private;
int clock_limit =
@@ -4153,8 +4154,13 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* the only reason for the pipe == PIPE_A check?
*/
if (crtc-pipe == PIPE_A
- adjusted_mode-clock clock_limit * 9 / 10)
+ adjusted_mode-clock clock_limit * 9 / 10) {
+ clock_limit *= 2;
pipe_config-double_wide = true;
+ }
+
+ if (adjusted_mode-clock clock_limit * 9 / 10)
+ return -EINVAL;
}
/* Cantiga+ cannot handle modes with a hsync front porch of 0.
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: pipe_src_w must be even in LVDS dual channel, DVO ganged, and double wide mode
From: Ville Syrjälä ville.syrj...@linux.intel.com Pipe horizontal source size must be even when either LVDS dual channel mode, DVO ganged mode, or pipe double wide mode is used. We must round it down since we can never increase the user specified viewport size. The actual error from an odd pipe source width looks like a diagonal shift, like you might get from a bad stride. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 040e0ef..ee777a7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4163,6 +4163,16 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc, return -EINVAL; } + /* +* Pipe horizontal size must be even in: +* - DVO ganaged mode +* - LVDS dual channel mode +* - Double wide pipe +*/ + if ((intel_pipe_has_type(crtc-base, INTEL_OUTPUT_LVDS) +intel_is_dual_link_lvds(dev)) || pipe_config-double_wide) + pipe_config-pipe_src_w = ~1; + /* Cantiga+ cannot handle modes with a hsync front porch of 0. * WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw. */ -- 1.8.1.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Fix up pipe vs. double wide confusion
From: Ville Syrjälä ville.syrj...@linux.intel.com
Double wide mode is only available on pipe A, except on GDG where
pipe B is also double wide capable.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ee777a7..70f9fc2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4150,10 +4150,10 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* Enable pixel doubling when the dot clock
* is 90% of the (display) core speed.
*
-* XXX: No double-wide on 915GM pipe B. Is that
-* the only reason for the pipe == PIPE_A check?
+* GDG double wide on either pipe,
+* otherwise pipe A only.
*/
- if (crtc-pipe == PIPE_A
+ if ((crtc-pipe == PIPE_A || IS_I915G(dev))
adjusted_mode-clock clock_limit * 9 / 10) {
clock_limit *= 2;
pipe_config-double_wide = true;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/12] drm/i915: Grab the pixel clock from adjusted_mode not requested_mode
On Mon, Sep 02, 2013 at 09:13:28PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_crtc_compute_config() and i9xx_set_pipeconf() attempt to get
the current pixel clock from requested_mode. requested_mode.clock may
be totally bogus, so the clock should come from adjusted_mode.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ecb8b52..cab1319 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4124,8 +4124,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
if (HAS_PCH_SPLIT(dev)) {
/* FDI link clock is fixed at 2.7G */
- if (pipe_config-requested_mode.clock * 3
- IRONLAKE_FDI_FREQ * 4)
+ if (adjusted_mode-clock * 3 IRONLAKE_FDI_FREQ * 4)
Note quite: The fdi dotclock is the adjusted mode's clock but with the
pixel multiplier _not_ taken into account. See
ironlake_fdi_compute_config. Maybe we need a fdi_dotclock_from_pipe_config
helper function?o
Otoh the ironlake_fdi_compute_config will do the right thing no matter
what and even takes into account things like cpu edp or shared fdi b/c
lanes. So I think we should just ditch this check here ;-)
-Daniel
return -EINVAL;
}
@@ -4812,7 +4811,7 @@ static void i9xx_set_pipeconf(struct intel_crtc
*intel_crtc)
* XXX: No double-wide on 915GM pipe B. Is that the only reason
for the
* pipe == 0 check?
*/
- if (intel_crtc-config.requested_mode.clock
+ if (intel_crtc-config.adjusted_mode.clock
dev_priv-display.get_display_clock_speed(dev) * 9 / 10)
pipeconf |= PIPECONF_DOUBLE_WIDE;
}
--
1.8.1.5
___
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 03/12] drm/i915: Use adjusted_mode in HDMI 12bpc clock check
On Mon, Sep 02, 2013 at 09:13:30PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com The pixel clock should come from adjusted_mode not requested_mode. In this case the two should be the same as we don't currently overwrite the clock in the case of HDMI. But let's make the code safe against such things happening in the future. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Atm only the encoder overrides the adjusted_mode at all, so I think I prefer the current code flow as clearer ... -Daniel --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 4148cc8..48e3b32 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -862,7 +862,7 @@ bool intel_hdmi_compute_config(struct intel_encoder *encoder, struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder-base); struct drm_device *dev = encoder-base.dev; struct drm_display_mode *adjusted_mode = pipe_config-adjusted_mode; - int clock_12bpc = pipe_config-requested_mode.clock * 3 / 2; + int clock_12bpc = pipe_config-adjusted_mode.clock * 3 / 2; int portclock_limit = hdmi_portclock_limit(intel_hdmi); int desired_bpp; -- 1.8.1.5 ___ 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 08/12] drm/i915: Make intel_crtc_active() available outside intel_pm.c
On Mon, Sep 02, 2013 at 09:13:35PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move intel_crtc_active() to intel_display.c and make it available
elsewhere as well.
intel_edp_psr_match_conditions() already has one open coded copy,
so replace that one with a call to intel_crtc_active().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 11 +++
drivers/gpu/drm/i915/intel_dp.c | 3 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 11 ---
4 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 19b203c..f49dbe8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -751,6 +751,17 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct
drm_crtc *crtc,
return true;
}
+bool intel_crtc_active(struct drm_crtc *crtc)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+ /* Be paranoid as we can arrive here with only partial
+ * state retrieved from the hardware during setup.
+ */
+ return intel_crtc-active crtc-fb
+ intel_crtc-config.adjusted_mode.clock;
If you touch this can you please add a big comment explaining that we can
ditch the adjusted_mode.clock check as soon as Haswell has gained clock
readout/fastboot support and that we can ditch the crtc-fb check as soon
as we can properly reconstruct framebuffers?
Thanks, Daniel
+}
+
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private
*dev_priv,
enum pipe pipe)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e2cb650..5ce5968 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1555,8 +1555,7 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
}
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc-active || !crtc-fb ||
- !intel_crtc-config.adjusted_mode.clock) {
+ if (!intel_crtc_active(crtc)) {
DRM_DEBUG_KMS(crtc not active for PSR\n);
dev_priv-no_psr_reason = PSR_CRTC_NOT_ACTIVE;
return false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 5efb844..e017c30 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -798,5 +798,6 @@ extern void hsw_pc8_disable_interrupts(struct drm_device
*dev);
extern void hsw_pc8_restore_interrupts(struct drm_device *dev);
extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
+extern bool intel_crtc_active(struct drm_crtc *crtc);
#endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 397628b..3ba412c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -43,17 +43,6 @@
* i915.i915_enable_fbc parameter
*/
-static bool intel_crtc_active(struct drm_crtc *crtc)
-{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
- /* Be paranoid as we can arrive here with only partial
- * state retrieved from the hardware during setup.
- */
- return intel_crtc-active crtc-fb
- intel_crtc-config.adjusted_mode.clock;
-}
-
static void i8xx_disable_fbc(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.8.1.5
___
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 12/12] drm/i915: Fix pipe config warnings when dealing with LVDS fixed mode
On Mon, Sep 02, 2013 at 09:13:39PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode
only partially. Notably it forgot to copy over the sync flags. The LVDS
code however programmed the hardware with the sync flags from fixed
mode, and then later the pipe config comparison obviously failed as we
filled out the adjusted_mode in get_config from the real registers.
Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the
whole thing, and then just use adjusted_mode in the LVDS code to figure
out which sync settings the hardware needs.
Also constify the fixed_mode argument to intel_fixed_panel_mode().
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Makes too much sense, so merged right away to dinq ;-)
Thanks, Daniel
---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_lvds.c | 8
drivers/gpu/drm/i915/intel_panel.c | 14 ++
3 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index 594d9f4..a71b47c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -559,7 +559,7 @@ extern int intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *fixed_mode);
extern void intel_panel_fini(struct intel_panel *panel);
-extern void intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
+extern void intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode);
extern void intel_pch_panel_fitting(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config,
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 4d33278..831a5c0 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -128,8 +128,8 @@ static void intel_pre_enable_lvds(struct intel_encoder
*encoder)
struct drm_device *dev = encoder-base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *crtc = to_intel_crtc(encoder-base.crtc);
- struct drm_display_mode *fixed_mode =
- lvds_encoder-attached_connector-base.panel.fixed_mode;
+ const struct drm_display_mode *adjusted_mode =
+ crtc-config.adjusted_mode;
int pipe = crtc-pipe;
u32 temp;
@@ -183,9 +183,9 @@ static void intel_pre_enable_lvds(struct intel_encoder
*encoder)
temp = ~LVDS_ENABLE_DITHER;
}
temp = ~(LVDS_HSYNC_POLARITY | LVDS_VSYNC_POLARITY);
- if (fixed_mode-flags DRM_MODE_FLAG_NHSYNC)
+ if (adjusted_mode-flags DRM_MODE_FLAG_NHSYNC)
temp |= LVDS_HSYNC_POLARITY;
- if (fixed_mode-flags DRM_MODE_FLAG_NVSYNC)
+ if (adjusted_mode-flags DRM_MODE_FLAG_NVSYNC)
temp |= LVDS_VSYNC_POLARITY;
I915_WRITE(lvds_encoder-reg, temp);
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index c361f04..c9dba46 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -36,20 +36,10 @@
#define PCI_LBPC 0xf4 /* legacy/combination backlight modes */
void
-intel_fixed_panel_mode(struct drm_display_mode *fixed_mode,
+intel_fixed_panel_mode(const struct drm_display_mode *fixed_mode,
struct drm_display_mode *adjusted_mode)
{
- adjusted_mode-hdisplay = fixed_mode-hdisplay;
- adjusted_mode-hsync_start = fixed_mode-hsync_start;
- adjusted_mode-hsync_end = fixed_mode-hsync_end;
- adjusted_mode-htotal = fixed_mode-htotal;
-
- adjusted_mode-vdisplay = fixed_mode-vdisplay;
- adjusted_mode-vsync_start = fixed_mode-vsync_start;
- adjusted_mode-vsync_end = fixed_mode-vsync_end;
- adjusted_mode-vtotal = fixed_mode-vtotal;
-
- adjusted_mode-clock = fixed_mode-clock;
+ drm_mode_copy(adjusted_mode, fixed_mode);
drm_mode_set_crtcinfo(adjusted_mode, 0);
}
--
1.8.1.5
___
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 11/12] drm/i915: Add explicit pipe src size to pipe config
On Mon, Sep 02, 2013 at 09:13:38PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Not sold on this - imo it makes more sense to keep track of this in a new plane config structure or something similar which ties the fb + metadata to the crtc. Then we could move a bunch of things we currently have in the pipe config or someplaces else even (fbc, ips, ...) over there. So I'm voting for keeping the mess a bit longer until we can do the real thing ... -Daniel --- drivers/gpu/drm/i915/intel_display.c | 26 +++-- drivers/gpu/drm/i915/intel_drv.h | 3 ++ drivers/gpu/drm/i915/intel_panel.c | 56 +--- drivers/gpu/drm/i915/intel_pm.c | 33 ++--- drivers/gpu/drm/i915/intel_sprite.c | 4 +-- 5 files changed, 64 insertions(+), 58 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f49dbe8..17fe7ed 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4692,7 +4692,6 @@ static void intel_set_pipe_timings(struct intel_crtc *intel_crtc) enum transcoder cpu_transcoder = intel_crtc-config.cpu_transcoder; struct drm_display_mode *adjusted_mode = intel_crtc-config.adjusted_mode; - struct drm_display_mode *mode = intel_crtc-config.requested_mode; uint32_t vsyncshift, crtc_vtotal, crtc_vblank_end; /* We need to be careful not to changed the adjusted mode, for otherwise @@ -4745,7 +4744,8 @@ static void intel_set_pipe_timings(struct intel_crtc *intel_crtc) * always be the user's requested size. */ I915_WRITE(PIPESRC(pipe), -((mode-hdisplay - 1) 16) | (mode-vdisplay - 1)); +((intel_crtc-config.pipe_src_w - 1) 16) | +(intel_crtc-config.pipe_src_h - 1)); } static void intel_get_pipe_timings(struct intel_crtc *crtc, @@ -4783,8 +4783,11 @@ static void intel_get_pipe_timings(struct intel_crtc *crtc, } tmp = I915_READ(PIPESRC(crtc-pipe)); - pipe_config-requested_mode.vdisplay = (tmp 0x) + 1; - pipe_config-requested_mode.hdisplay = ((tmp 16) 0x) + 1; + pipe_config-pipe_src_h = (tmp 0x) + 1; + pipe_config-pipe_src_w = ((tmp 16) 0x) + 1; + + pipe_config-requested_mode.vdisplay = pipe_config-pipe_src_h; + pipe_config-requested_mode.hdisplay = pipe_config-pipe_src_w; } static void intel_crtc_mode_from_pipe_config(struct intel_crtc *intel_crtc, @@ -4880,7 +4883,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - struct drm_display_mode *mode = intel_crtc-config.requested_mode; int pipe = intel_crtc-pipe; int plane = intel_crtc-plane; int refclk, num_connectors = 0; @@ -4978,8 +4980,8 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, * which should always be the user's requested size. */ I915_WRITE(DSPSIZE(plane), -((mode-vdisplay - 1) 16) | -(mode-hdisplay - 1)); +((intel_crtc-config.pipe_src_h - 1) 16) | +(intel_crtc-config.pipe_src_w - 1)); I915_WRITE(DSPPOS(plane), 0); i9xx_set_pipeconf(intel_crtc); @@ -8255,6 +8257,8 @@ static void intel_dump_pipe_config(struct intel_crtc *crtc, drm_mode_debug_printmodeline(pipe_config-requested_mode); DRM_DEBUG_KMS(adjusted mode:\n); drm_mode_debug_printmodeline(pipe_config-adjusted_mode); + DRM_DEBUG_KMS(pipe src size: %dx%d\n, + pipe_config-pipe_src_w, pipe_config-pipe_src_h); DRM_DEBUG_KMS(gmch pfit: control: 0x%08x, ratios: 0x%08x, lvds border: 0x%08x\n, pipe_config-gmch_pfit.control, pipe_config-gmch_pfit.pgm_ratios, @@ -8306,6 +8310,10 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, drm_mode_copy(pipe_config-adjusted_mode, mode); drm_mode_copy(pipe_config-requested_mode, mode); + + pipe_config-pipe_src_w = mode-hdisplay; + pipe_config-pipe_src_h = mode-vdisplay; + pipe_config-cpu_transcoder = (enum transcoder) to_intel_crtc(crtc)-pipe; pipe_config-shared_dpll = DPLL_ID_PRIVATE; @@ -8649,8 +8657,8 @@ intel_pipe_config_compare(struct drm_device *dev, DRM_MODE_FLAG_NVSYNC); } -
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4
On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We don't want to try to push the hardware beyond it's capabilities,
so check the pixel clock against the display core clock limit. Do
it for pre-gen4 for now since that's where we alread have the double
wide pixel clock limit check.
Let's assume that when double wide mode is enabled the max
pixel clock limit is also doubled.
FIXME: panel fitter downscaling probably affects the limit on
non-pch platforms too, so we'd need another version of
ilk_pipe_pixel_rate() to figure that out.
FIXME: should check the limits on all platforms. Also sprites
affect the max allowed pixel rate on some platforms, so we need
to eventually tie all the planes and pipes into one check in
the future. But we need plane state pre-compute before that can
happen.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ea33468..040e0ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
return -EINVAL;
}
+ /* FIXME should check pixel clock limits on all platforms */
We do by failing to find the pll. The fun is to move all that code into
the pipe computation stage. The second part of the fun is that on newer
platforms dotclock limits are all encoder specific, so we need to shovel
them into encoder callbacks anyway.
I don't know whether there are any additional pixel clock limits on top of
what the plls can handle, but at least I haven't spotted them yet ...
-Daniel
if (INTEL_INFO(dev)-gen 4) {
struct drm_i915_private *dev_priv = dev-dev_private;
int clock_limit =
@@ -4153,8 +4154,13 @@ static int intel_crtc_compute_config(struct intel_crtc
*crtc,
* the only reason for the pipe == PIPE_A check?
*/
if (crtc-pipe == PIPE_A
- adjusted_mode-clock clock_limit * 9 / 10)
+ adjusted_mode-clock clock_limit * 9 / 10) {
+ clock_limit *= 2;
pipe_config-double_wide = true;
+ }
+
+ if (adjusted_mode-clock clock_limit * 9 / 10)
+ return -EINVAL;
}
/* Cantiga+ cannot handle modes with a hsync front porch of 0.
--
1.8.1.5
___
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 0/5] drm/i915: Double wide pipe config
On Mon, Sep 02, 2013 at 09:24:23PM +0300, ville.syrj...@linux.intel.com wrote: I was suspecting double wide to be the cause of a bug report, and so started digging a bit. Sadly it looks like that bug is caused by something else, but I did end up fixing a double wide related bug anyway. The resulting series is here. It needs to be applied after the pipe config fixes seried I just posted since I'm using the new pipe_src_w in this series. There's also the DOUBLE_WIDE check in intel_overlay I've hoped you'd convert ;-) -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] [PATCH] drm/i915: fix up the relocate_entry refactoring
Somehow we've lost the error handling in the patch split-up between the internal and external patch. This regression has been introduced in commit 5032d871f7d300aee10c309ea004eb4f851553fe Author: Rafael Barbalho rafael.barba...@intel.com Date: Wed Aug 21 17:10:51 2013 +0100 drm/i915: Cleaning up the relocate entry function Cc: Rafael Barbalho rafael.barba...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c index ea4bacb..e519f9f 100644 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c @@ -349,6 +349,9 @@ i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj, else ret = relocate_entry_gtt(obj, reloc); + if (ret) + return ret; + /* and update the user's relocation entry */ reloc-presumed_offset = target_offset; -- 1.8.4.rc3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock
On Mon, Sep 02, 2013 at 12:52:05PM +0100, Chris Wilson wrote: On Mon, Sep 02, 2013 at 08:49:01AM +0200, Daniel Vetter wrote: Historically we've run our own driver hotplug handling in our own work-queue, which then launched the drm core hotplug handling in the system workqueue. This is important since we flush our own driver workqueue in the pageflip code while hodling modeset locks, and only the drm hotplug code grabbed these locks. But with commit 69787f7da6b2adc4054357a661aaa1701a9ca76f Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Oct 23 18:23:34 2012 + drm: run the hpd irq event code directly this was changed and now we could deadlock in our flip handler if there's a hotplug work blocking the progress of the crucial unpin works. So this broke the careful deadlock avoidance implemented in commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Nov 1 09:26:26 2012 + drm/i915: Flush outstanding unpin tasks before pageflipping Since the rule thus far has been that work items on our own workqueue may never grab modeset locks simply restore that rule again. Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: Stuart Abercrombie sabercrom...@chromium.org Reported-by: Stuart Abercrombie sabercrom...@chromium.org References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239 Cc: sta...@vger.kernel.org Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch That wins for simplicity, and it is indeed the only caller that requires mode_config.lock, so Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Bonus would a reminder in i915_drv.h to say that we cannot put items that require mode_config.lock onto the wq, and that they should go onto the global workqueue instead. I've merged the updated version, thanks for your review. -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 11/12] drm/i915: Add explicit pipe src size to pipe config
On Mon, Sep 02, 2013 at 08:46:19PM +0200, Daniel Vetter wrote: On Mon, Sep 02, 2013 at 09:13:38PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Not sold on this - imo it makes more sense to keep track of this in a new plane config structure or something similar which ties the fb + metadata to the crtc. Then we could move a bunch of things we currently have in the pipe config or someplaces else even (fbc, ips, ...) over there. This size isn't the plane size. It's the pipe size. Two different things. So I'm voting for keeping the mess a bit longer until we can do the real thing ... -Daniel --- drivers/gpu/drm/i915/intel_display.c | 26 +++-- drivers/gpu/drm/i915/intel_drv.h | 3 ++ drivers/gpu/drm/i915/intel_panel.c | 56 +--- drivers/gpu/drm/i915/intel_pm.c | 33 ++--- drivers/gpu/drm/i915/intel_sprite.c | 4 +-- 5 files changed, 64 insertions(+), 58 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index f49dbe8..17fe7ed 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4692,7 +4692,6 @@ static void intel_set_pipe_timings(struct intel_crtc *intel_crtc) enum transcoder cpu_transcoder = intel_crtc-config.cpu_transcoder; struct drm_display_mode *adjusted_mode = intel_crtc-config.adjusted_mode; - struct drm_display_mode *mode = intel_crtc-config.requested_mode; uint32_t vsyncshift, crtc_vtotal, crtc_vblank_end; /* We need to be careful not to changed the adjusted mode, for otherwise @@ -4745,7 +4744,8 @@ static void intel_set_pipe_timings(struct intel_crtc *intel_crtc) * always be the user's requested size. */ I915_WRITE(PIPESRC(pipe), - ((mode-hdisplay - 1) 16) | (mode-vdisplay - 1)); + ((intel_crtc-config.pipe_src_w - 1) 16) | + (intel_crtc-config.pipe_src_h - 1)); } static void intel_get_pipe_timings(struct intel_crtc *crtc, @@ -4783,8 +4783,11 @@ static void intel_get_pipe_timings(struct intel_crtc *crtc, } tmp = I915_READ(PIPESRC(crtc-pipe)); - pipe_config-requested_mode.vdisplay = (tmp 0x) + 1; - pipe_config-requested_mode.hdisplay = ((tmp 16) 0x) + 1; + pipe_config-pipe_src_h = (tmp 0x) + 1; + pipe_config-pipe_src_w = ((tmp 16) 0x) + 1; + + pipe_config-requested_mode.vdisplay = pipe_config-pipe_src_h; + pipe_config-requested_mode.hdisplay = pipe_config-pipe_src_w; } static void intel_crtc_mode_from_pipe_config(struct intel_crtc *intel_crtc, @@ -4880,7 +4883,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, struct drm_device *dev = crtc-dev; struct drm_i915_private *dev_priv = dev-dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); - struct drm_display_mode *mode = intel_crtc-config.requested_mode; int pipe = intel_crtc-pipe; int plane = intel_crtc-plane; int refclk, num_connectors = 0; @@ -4978,8 +4980,8 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc, * which should always be the user's requested size. */ I915_WRITE(DSPSIZE(plane), - ((mode-vdisplay - 1) 16) | - (mode-hdisplay - 1)); + ((intel_crtc-config.pipe_src_h - 1) 16) | + (intel_crtc-config.pipe_src_w - 1)); I915_WRITE(DSPPOS(plane), 0); i9xx_set_pipeconf(intel_crtc); @@ -8255,6 +8257,8 @@ static void intel_dump_pipe_config(struct intel_crtc *crtc, drm_mode_debug_printmodeline(pipe_config-requested_mode); DRM_DEBUG_KMS(adjusted mode:\n); drm_mode_debug_printmodeline(pipe_config-adjusted_mode); + DRM_DEBUG_KMS(pipe src size: %dx%d\n, + pipe_config-pipe_src_w, pipe_config-pipe_src_h); DRM_DEBUG_KMS(gmch pfit: control: 0x%08x, ratios: 0x%08x, lvds border: 0x%08x\n, pipe_config-gmch_pfit.control, pipe_config-gmch_pfit.pgm_ratios, @@ -8306,6 +8310,10 @@ intel_modeset_pipe_config(struct drm_crtc *crtc, drm_mode_copy(pipe_config-adjusted_mode, mode); drm_mode_copy(pipe_config-requested_mode, mode); + + pipe_config-pipe_src_w = mode-hdisplay; + pipe_config-pipe_src_h = mode-vdisplay; + pipe_config-cpu_transcoder = (enum transcoder) to_intel_crtc(crtc)-pipe; pipe_config-shared_dpll = DPLL_ID_PRIVATE; @@ -8649,8 +8657,8 @@
Re: [Intel-gfx] [PATCH 03/12] drm/i915: Use adjusted_mode in HDMI 12bpc clock check
On Mon, Sep 02, 2013 at 08:39:45PM +0200, Daniel Vetter wrote: On Mon, Sep 02, 2013 at 09:13:30PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com The pixel clock should come from adjusted_mode not requested_mode. In this case the two should be the same as we don't currently overwrite the clock in the case of HDMI. But let's make the code safe against such things happening in the future. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Atm only the encoder overrides the adjusted_mode at all, so I think I prefer the current code flow as clearer ... And I'd atually prefer to kill requested_mode. It's confusing. Only hdisplay/vdisplay are always valid. Well even that's not true as can be seen from my double wide series. The clock and timings can be trusted only at the very beginning of the compute config step. And at that point adjusted_mode contains the exact same information. Also apart from the clock, we never use the other timings from requested_mode, so keeping the whole thing around seems more or less pointless. -Daniel --- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 4148cc8..48e3b32 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -862,7 +862,7 @@ bool intel_hdmi_compute_config(struct intel_encoder *encoder, struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder-base); struct drm_device *dev = encoder-base.dev; struct drm_display_mode *adjusted_mode = pipe_config-adjusted_mode; - int clock_12bpc = pipe_config-requested_mode.clock * 3 / 2; + int clock_12bpc = pipe_config-adjusted_mode.clock * 3 / 2; int portclock_limit = hdmi_portclock_limit(intel_hdmi); int desired_bpp; -- 1.8.1.5 ___ 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 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4
On Mon, Sep 02, 2013 at 08:51:41PM +0200, Daniel Vetter wrote: On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä ville.syrj...@linux.intel.com We don't want to try to push the hardware beyond it's capabilities, so check the pixel clock against the display core clock limit. Do it for pre-gen4 for now since that's where we alread have the double wide pixel clock limit check. Let's assume that when double wide mode is enabled the max pixel clock limit is also doubled. FIXME: panel fitter downscaling probably affects the limit on non-pch platforms too, so we'd need another version of ilk_pipe_pixel_rate() to figure that out. FIXME: should check the limits on all platforms. Also sprites affect the max allowed pixel rate on some platforms, so we need to eventually tie all the planes and pipes into one check in the future. But we need plane state pre-compute before that can happen. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/i915/intel_display.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index ea33468..040e0ef 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc, return -EINVAL; } + /* FIXME should check pixel clock limits on all platforms */ We do by failing to find the pll. The fun is to move all that code into the pipe computation stage. Are you 100% sure the PLL algorithm can never give you a clock that exceeds the display core clock? Looking at the functions to calculate the core clock, there is an awful lot of variation there already, and we don't even have those functions filled out for modern platforms. The second part of the fun is that on newer platforms dotclock limits are all encoder specific, so we need to shovel them into encoder callbacks anyway. I don't know whether there are any additional pixel clock limits on top of what the plls can handle, but at least I haven't spotted them yet ... The display core clock is the big one. We have to check it for other platforms too eventually since the limit depends on a bunch of factors. For example on ILK/SNB we need to check whether there's one or two sprites enabled, are they using RGB or YUV, are they scaled, and if so by how much? Obviouly we can't do all that until we can pre-compute the state of all planes. So actually we may need some more steps in the process. Something like this: 1) adjust timings 2) calculate PLL settings to get the real clock 3) check double wide etc. that depends on the clock 4) compute plane config 5) check core clock and other plane related global limits But I don't mind dropping this one now, and revisiting the issue with a bigger hammer in the future. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/5] drm/i915: Double wide pipe config
On Mon, Sep 02, 2013 at 08:53:01PM +0200, Daniel Vetter wrote: On Mon, Sep 02, 2013 at 09:24:23PM +0300, ville.syrj...@linux.intel.com wrote: I was suspecting double wide to be the cause of a bug report, and so started digging a bit. Sadly it looks like that bug is caused by something else, but I did end up fixing a double wide related bug anyway. The resulting series is here. It needs to be applied after the pipe config fixes seried I just posted since I'm using the new pipe_src_w in this series. There's also the DOUBLE_WIDE check in intel_overlay I've hoped you'd convert ;-) Now how did I miss that. I'm going to blame cscope :) -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Convert overlay double wide check over to pipe config
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_overlay.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index ddfd0ae..8d6d0a1 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -821,14 +821,11 @@ int intel_overlay_switch_off(struct intel_overlay
*overlay)
static int check_overlay_possible_on_crtc(struct intel_overlay *overlay,
struct intel_crtc *crtc)
{
- drm_i915_private_t *dev_priv = overlay-dev-dev_private;
-
if (!crtc-active)
return -EINVAL;
/* can't use the overlay with double wide pipe */
- if (INTEL_INFO(overlay-dev)-gen 4
- (I915_READ(PIPECONF(crtc-pipe)) (PIPECONF_DOUBLE_WIDE |
PIPECONF_ENABLE)) != PIPECONF_ENABLE)
+ if (crtc-config.double_wide)
return -EINVAL;
return 0;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Make intel_crtc_active() available outside intel_pm.c
From: Ville Syrjälä ville.syrj...@linux.intel.com
Move intel_crtc_active() to intel_display.c and make it available
elsewhere as well.
intel_edp_psr_match_conditions() already has one open coded copy,
so replace that one with a call to intel_crtc_active().
v2: Copy paste a big comment from danvet's mail explaining
when we can ditch the extra checks
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 17 +
drivers/gpu/drm/i915/intel_dp.c | 3 +--
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 11 ---
4 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 19b203c..265b813 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -751,6 +751,23 @@ vlv_find_best_dpll(const intel_limit_t *limit, struct
drm_crtc *crtc,
return true;
}
+bool intel_crtc_active(struct drm_crtc *crtc)
+{
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+ /* Be paranoid as we can arrive here with only partial
+* state retrieved from the hardware during setup.
+*
+* We can ditch the adjusted_mode.clock check as soon
+* as Haswell has gained clock readout/fastboot support.
+*
+* We can ditch the crtc-fb check as soon as we can
+* properly reconstruct framebuffers.
+*/
+ return intel_crtc-active crtc-fb
+ intel_crtc-config.adjusted_mode.clock;
+}
+
enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv,
enum pipe pipe)
{
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e2cb650..5ce5968 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1555,8 +1555,7 @@ static bool intel_edp_psr_match_conditions(struct
intel_dp *intel_dp)
}
intel_crtc = to_intel_crtc(crtc);
- if (!intel_crtc-active || !crtc-fb ||
- !intel_crtc-config.adjusted_mode.clock) {
+ if (!intel_crtc_active(crtc)) {
DRM_DEBUG_KMS(crtc not active for PSR\n);
dev_priv-no_psr_reason = PSR_CRTC_NOT_ACTIVE;
return false;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5efb844..e017c30 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -798,5 +798,6 @@ extern void hsw_pc8_disable_interrupts(struct drm_device
*dev);
extern void hsw_pc8_restore_interrupts(struct drm_device *dev);
extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
+extern bool intel_crtc_active(struct drm_crtc *crtc);
#endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 397628b..3ba412c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -43,17 +43,6 @@
* i915.i915_enable_fbc parameter
*/
-static bool intel_crtc_active(struct drm_crtc *crtc)
-{
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
- /* Be paranoid as we can arrive here with only partial
-* state retrieved from the hardware during setup.
-*/
- return intel_crtc-active crtc-fb
- intel_crtc-config.adjusted_mode.clock;
-}
-
static void i8xx_disable_fbc(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
--
1.8.1.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Modify DP set clock to accomodate more eDP timings v2
eDP 1.4 supports 4-5 extra link rates in additional to current 2 link
rate. Create a structure to store the DPLL divisor data to improve
readability.
v2: Fix the gen4_dpll/pch_dpll initialization to C99
designated initializers, and use a single loop for all platforms. (Jani and
Daniel)
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 65 ++-
1 files changed, 37 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2151d13..fd09058 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -38,6 +38,27 @@
#define DP_LINK_CHECK_TIMEOUT (10 * 1000)
+struct dp_link_dpll {
+ int link_bw;
+ struct dpll dpll;
+};
+
+static const struct dp_link_dpll gen4_dpll[] =
+{
+ { DP_LINK_BW_1_62,
+ { .p1 = 2, .p2 = 10, .n = 2, .m1 = 23, .m2 = 8 }},
+ { DP_LINK_BW_2_7,
+ { .p1 = 1, .p2 = 10, .n = 1, .m1 = 14, .m2 = 2 }}
+};
+
+static const struct dp_link_dpll pch_dpll[] =
+{
+ { DP_LINK_BW_1_62,
+ { .p1 = 2, .p2 = 10, .n = 1, .m1 = 12, .m2 = 9 }},
+ { DP_LINK_BW_2_7,
+ { .p1 = 1, .p2 = 10, .n = 2, .m1 = 14, .m2 = 8 }}
+};
+
/**
* is_edp - is the given port attached to an eDP panel (either CPU or PCH)
* @intel_dp: DP struct
@@ -649,42 +670,30 @@ intel_dp_set_clock(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config, int link_bw)
{
struct drm_device *dev = encoder-base.dev;
+ const struct dp_link_dpll *divisor = NULL;
+ int i, count = 0;
if (IS_G4X(dev)) {
- if (link_bw == DP_LINK_BW_1_62) {
- pipe_config-dpll.p1 = 2;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.n = 2;
- pipe_config-dpll.m1 = 23;
- pipe_config-dpll.m2 = 8;
- } else {
- pipe_config-dpll.p1 = 1;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.n = 1;
- pipe_config-dpll.m1 = 14;
- pipe_config-dpll.m2 = 2;
- }
- pipe_config-clock_set = true;
+ divisor = gen4_dpll;
+ count = ARRAY_SIZE(gen4_dpll);
} else if (IS_HASWELL(dev)) {
/* Haswell has special-purpose DP DDI clocks. */
} else if (HAS_PCH_SPLIT(dev)) {
- if (link_bw == DP_LINK_BW_1_62) {
- pipe_config-dpll.n = 1;
- pipe_config-dpll.p1 = 2;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.m1 = 12;
- pipe_config-dpll.m2 = 9;
- } else {
- pipe_config-dpll.n = 2;
- pipe_config-dpll.p1 = 1;
- pipe_config-dpll.p2 = 10;
- pipe_config-dpll.m1 = 14;
- pipe_config-dpll.m2 = 8;
- }
- pipe_config-clock_set = true;
+ divisor = pch_dpll;
+ count = ARRAY_SIZE(pch_dpll);
} else if (IS_VALLEYVIEW(dev)) {
/* FIXME: Need to figure out optimized DP clocks for vlv. */
}
+
+ if (divisor count) {
+ for (i = 0; i count; i++) {
+ if (link_bw == divisor[i].link_bw) {
+ pipe_config-dpll = divisor[i].dpll;
+ pipe_config-clock_set = true;
+ break;
+ }
+ }
+ }
}
bool
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Move Valleyview DP DPLL divisor calc to intel_dp_set_clock v2
For DP pll settings, there is only two golden configs. Instead of
running through the algorithm to determine it, hardcode the value and get it
determine in intel_dp_set_clock.
v2: Rework on the intel_limit compiler warning. (Jani)
Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 20 +++-
drivers/gpu/drm/i915/intel_dp.c | 11 ++-
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f526ea9..1a567d2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -339,19 +339,6 @@ static const intel_limit_t intel_limits_vlv_hdmi = {
.p2_slow = 2, .p2_fast = 20 },
};
-static const intel_limit_t intel_limits_vlv_dp = {
- .dot = { .min = 25000, .max = 27 },
- .vco = { .min = 400, .max = 600 },
- .n = { .min = 1, .max = 7 },
- .m = { .min = 22, .max = 450 },
- .m1 = { .min = 2, .max = 3 },
- .m2 = { .min = 11, .max = 156 },
- .p = { .min = 10, .max = 30 },
- .p1 = { .min = 1, .max = 3 },
- .p2 = { .dot_limit = 27,
- .p2_slow = 2, .p2_fast = 20 },
-};
-
static const intel_limit_t *intel_ironlake_limit(struct drm_crtc *crtc,
int refclk)
{
@@ -414,10 +401,8 @@ static const intel_limit_t *intel_limit(struct drm_crtc
*crtc, int refclk)
} else if (IS_VALLEYVIEW(dev)) {
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_ANALOG))
limit = intel_limits_vlv_dac;
- else if (intel_pipe_has_type(crtc, INTEL_OUTPUT_HDMI))
- limit = intel_limits_vlv_hdmi;
else
- limit = intel_limits_vlv_dp;
+ limit = intel_limits_vlv_hdmi;
} else if (!IS_GEN2(dev)) {
if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS))
limit = intel_limits_i9xx_lvds;
@@ -4890,7 +4875,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
refclk = i9xx_get_refclk(crtc, num_connectors);
- if (!is_dsi) {
+ if (!is_dsi !intel_crtc-config.clock_set) {
/*
* Returns a set of divisors for the desired target clock with
* the given refclk, or FALSE. The returned values represent
@@ -4917,6 +4902,7 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
* by using the FP0/FP1. In such case we will disable the LVDS
* downclock feature.
*/
+ limit = intel_limit(crtc, refclk);
has_reduced_clock =
dev_priv-display.find_dpll(limit, crtc,
dev_priv-lvds_downclock,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fd09058..76b4372 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,14 @@ static const struct dp_link_dpll pch_dpll[] =
{ .p1 = 1, .p2 = 10, .n = 2, .m1 = 14, .m2 = 8 }}
};
+static const struct dp_link_dpll vlv_dpll[] =
+{
+ { DP_LINK_BW_1_62,
+ { .p1 = 3, .p2 = 2, .n = 5, .m1 = 5, .m2 = 3 }},
+ { DP_LINK_BW_2_7,
+ { .p1 = 2, .p2 = 2, .n = 1, .m1 = 2, .m2 = 27 }}
+};
+
/**
* is_edp - is the given port attached to an eDP panel (either CPU or PCH)
* @intel_dp: DP struct
@@ -682,7 +690,8 @@ intel_dp_set_clock(struct intel_encoder *encoder,
divisor = pch_dpll;
count = ARRAY_SIZE(pch_dpll);
} else if (IS_VALLEYVIEW(dev)) {
- /* FIXME: Need to figure out optimized DP clocks for vlv. */
+ divisor = vlv_dpll;
+ count = ARRAY_SIZE(vlv_dpll);
}
if (divisor count) {
--
1.7.7.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
