summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: export a CPT mode set verification functionJesse Barnes2011-10-203-0/+32
| | | | | | | | | | | | | | | At the point where we check, we can't do much about the failure, but it can aid debugging. Note that the auto-train override bit will be reset as part of normal mode setting with this patch if a pipe ever does get stuck, but that's consistent with the workaround for CPT provided by the hardware team. This patch helped catch the fact that the pipe wasn't running in the !composite sync FDI case on my IVB SDV, so has already shown to be useful. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fix transcoder PLL select maskingJesse Barnes2011-10-201-5/+10
| | | | | | | | | | | | Transcoder A will always use PLL A and transcoder B will use PLL B. But transcoder C could use either, so always mask the select bits off before or'ing in a new value. Reported-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fix IVB cursor supportJesse Barnes2011-10-202-5/+43
| | | | | | | | | | The cursor regs have moved around, add the offsets and new macros for getting at them. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fix debug output for 3 pipe configsJesse Barnes2011-10-201-1/+1
| | | | | | | | | We can have more than just A and B these days. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: add PLL sharing support to handle 3 pipesJesse Barnes2011-10-202-38/+63
| | | | | | | | | | | | | | | | Add two new fields to the intel_crtc struct for 3 pipe support: no_pll and use_pll_a. The no_pll field is only set on the 3rd pipe to indicate that it doesn't have a PLL of its own and so shouldn't try to write the main PLL regs. The use_pll_a field controls which PLL pipe 3 will share, A or B. The core code will try to share PLLs with whichever pipe has the same timings, rejecting the mode set if none is found. This means that pipe 3 must always be set after one of the other pipes has been configured with real PLL settings. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fix PCH PLL assertion check for 3 pipesJesse Barnes2011-10-201-0/+13
| | | | | | | | | | | | | Add a couple of checks now that we're using the 3rd transcoder: 1) make sure the transcoder PLL enable bit is set for the transcoder in question 2) when checking actual PLL enable, use the selected PLL number rather than the transcoder number (they could be different now) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: use transcoder select bits on VGA and HDMI on CPTJesse Barnes2011-10-202-17/+11
| | | | | | | | | Required for 3 pipe functionality. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: split refclk code out of ironlake_crtc_mode_setJesse Barnes2011-10-201-4/+35
| | | | | | | | | Just a cleanup to make the mode_set function more manageable. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: support 3 pipes on IVB+Jesse Barnes2011-10-207-9/+20
| | | | | | | | | | | | Well almost anyway. IVB has 3 planes, pipes, transcoders, and FDI interfaces, but only 2 pipe PLLs. So two of the pipes must use the same pipe timings (e.g. 2 DP plus one other, or two HDMI with the same mode and one other, etc.). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: PLL macro cleanup and pipe assertion checkJesse Barnes2011-10-202-3/+9
| | | | | | | | | | Add a macro for accessing the two pipe PLLs and add a check to make sure we don't access a non-existent one in the enable/disable functions. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-By: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: always set FDI composite sync bitJesse Barnes2011-10-202-0/+3
| | | | | | | | | | It's needed for 3 pipe support as well as just regular functionality (e.g. DisplayPort). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Adam Jackson <ajax@redhat.com> Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Use PIPE_CONTROL for flushing on gen6+.Jesse Barnes2011-10-202-12/+130
| | | | | | | | | | | v2 by danvet: Use a new flag to flush the render target cache on gen6+ (hw reuses the old write flush bit), as suggested by Ben Widawsdy. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [danvet: this seems to fix cairo-perf-trace hangs on my snb] Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Rename PIPE_CONTROL bit defines to be less terse.Kenneth Graunke2011-10-202-10/+12
| | | | | | | | | | | "STALL_AT_SCOREBOARD" is much clearer than "STALL_EN" now that there are several different kinds of stalls. Also, "INSTRUCTION_CACHE_INVALIDATE" is a lot easier to understand at a glance than the terse "IS_FLUSH." Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [danvet: use INVALIDATE for ro cache flags for more consistency] Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Remove implied length of 2 from GFX_OP_PIPE_CONTROL #define.Kenneth Graunke2011-10-202-5/+5
| | | | | | | | | | Not all PIPE_CONTROLs have a length of 2, so remove it from the #define and make each invocation specify the desired length. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [danvet: implement style suggestion from Ben Widawsdy] Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm: Add Panel Self Refresh DP addressesBen Widawsky2011-10-201-0/+36
| | | | | | | | | | | | | | | | | | | Add the addresses and definitions I care about for Panel Self Refresh, as documented in the eDP spec. I'm sending these out before some other patches because this should be a fairly simple one to get upstream and not require too much fuss (where the others may have some fuss). This file is a mess with white spacing. I tried to stay consistent with the surrounding code. v2: had some silly mistakes in v1 which Keith caught Cc: Dave Airlie <airlied@redhat.com> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: ILK + VT-d workaroundBen Widawsky2011-10-203-0/+60
| | | | | | | | | | | Idle the GPU before doing any unmaps. We know if VT-d is in use through an exported variable from iommu code. This should avoid a known HW issue. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Remove early exit on i915_gpu_idleBen Widawsky2011-10-201-6/+0
| | | | | | | | | | | | | [Description from: Daniel Vetter] I've just discussed this quickly with Chris on irc and it's probably best to just kill the list_empty early bailout. gpu_idle isn't a fastpath, so who cares. One candidate where we emit commands to the ring without adding anything onto these lists is e.g. pageflip. There are probably more. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
* intel-iommu: Export a flag indicating that the IOMMU is used for iGFX.David Woodhouse2011-10-201-10/+15
| | | | | | | | | | | | | We really don't want this to work in the general case; device drivers *shouldn't* care whether they are behind an IOMMU or not. But the integrated graphics is a special case, because the IOMMU and the GTT are all kind of smashed into one and generally horrifically buggy, so it's reasonable for the graphics driver to want to know when the IOMMU is active for the graphics hardware. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* intel-iommu: Workaround IOTLB hang on Ironlake GPUDavid Woodhouse2011-10-201-1/+5
| | | | | | | | | | | | To work around a hardware issue, we have to submit IOTLB flushes while the graphics engine is idle. The graphics driver will (we hope) go to great lengths to ensure that it gets that right on the affected chipset(s)... so let's not screw it over by deferring the unmap and doing it later. That wouldn't be very helpful. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: drop KM_USER0 argument to k(un)map_atomicDaniel Vetter2011-10-202-5/+5
| | | | | | Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* io-mapping: ensure io_mapping_map_atomic _is_ atomicDaniel Vetter2011-10-201-0/+4
| | | | | | | | | | | | | | | | | | For the !HAVE_ATOMIC_IOMAP case the stub functions did not call pagefault_disable/_enable. The i915 driver relies on the map actually being atomic, otherwise it can deadlock with it's own pagefault handler in the gtt pwrite fastpath. This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem testsuite. v2: Chris Wilson noted the lack of an include. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115 Cc: stable@kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Defend against userspace creating a gem object with size==0Chris Wilson2011-10-201-0/+2
| | | | | | | | | | | | | | | | We currently only round up the userspace size to the next page. We assume that userspace hasn't made a mistake and requested a zero-length gem object and all through our internal code we then presume that every object is backed by at least a single page. Fix that oversight and report EINVAL back to userspace if they try to create a zero length object. [danvet: This fixes tests/gem_bad_length] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: simplify swapin/out swizzle checking a bitDaniel Vetter2011-10-202-12/+2
| | | | | | | | | Use the helper function already employed by the pwrite/pread functions. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: fix swizzling on gen6+Daniel Vetter2011-10-201-1/+4
| | | | | | | | | Fixes tests/gem_tiled_pread on my snb. I know, mesa doesn't use this on gen6+, but I also hate failing testcases. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: properly cancel rps_work on module unload v2Daniel Vetter2011-10-201-0/+5
| | | | | | | | | | | | | | | The rps disabling code wasn't properly cancelling outstanding work items. Also add a comment that explains why we're not racing with the work item that could unmask interrupts - that piece of code confused me quite a bit. v2: Ben Widawsky pointed out that the first patch would deadlock (and a few lesser problems). All corrected. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: close PM interrupt masking races in the rps work funcDaniel Vetter2011-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch closes the following race: We get a PM interrupt A, mask it, set dev_priv->iir = PM_A and kick of the work item. Scheduler isn't grumpy, so the work queue takes rps_lock, grabs pm_iir = dev_priv->pm_iir and pm_imr = READ(PMIMR). Note that pm_imr == pm_iir because we've just masked the interrupt we've got. Now hw sends out PM interrupt B (not masked), we process it and mask it. Later on the irq handler also clears PMIIR. Then the work item proceeds and at the end clears PMIMR. Because (local) pm_imr == pm_iir we have pm_imr & ~pm_iir == 0 so all interrupts are enabled. Hardware is still interrupt-happy, and sends out a new PM interrupt B. PMIMR doesn't mask B (it does not mask anything), PMIIR is cleared, so we get it and hit the WARN in the interrupt handler (because dev_priv->pm_iir == PM_B). That's why I've moved the WRITE(PMIMR, 0) up under the protection of the rps_lock. And write an uncoditional 0 to PMIMR, because that's what we'll do anyway. This races looks much more likely because we can arbitrarily extend the window by grabing dev->struct mutex right after the irq handler has processed the first PM_B interrupt. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: close PM interrupt masking races in the irq handlerDaniel Vetter2011-10-201-2/+4
| | | | | | | | | | | | | | | | | | | | | | | Quoting Chris Wilson's more concise description: "Ah I think I see the problem. As you point out we only mask the current interrupt received, so that if we have a task pending (and so IMR != 0) we actually unmask the pending interrupt and so could receive it again before the tasklet is finally kicked off by the grumpy scheduler." We need the hw to issue PM interrupts A, B, A while the scheduler is hating us and refuses to run the rps work item. On receiving PM interrupt A we hit the WARN because dev_priv->pm_iir == PM_A | PM_B Also add a posting read as suggested by Chris to ensure proper ordering of the writes to PMIMR and PMIIR. Just in case somebody weakens write ordering. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Remove redundant bit shifting from intel_gmbus_set_speedAdam Jackson2011-10-202-8/+2
| | | | | | Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Rename intel_sdvo_hdmi_sink_detectAdam Jackson2011-10-201-2/+2
| | | | | | | | This is general TMDS detect, not HDMI specifically. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Fix multifunction SDVO detectionAdam Jackson2011-10-201-2/+1
| | | | | | | | | I can't think of any sensible reason to limit this to a mask of 0x0f, ie, SDVO_OUTPUT_{TMDS,RGB,CVBS,SVID}0. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* drm/i915: Remove "i2c_speed" nonsense from child device tableAdam Jackson2011-10-204-14/+8
| | | | | | | | | | I have no evidence for this byte being used this way, and lots of counterexamples. Restore the struct to its empirical definition and patch up gmbus setup to match. Signed-off-by: Adam Jackson <ajax@redhat.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
* Merge branch 'fix-pch-refclk' into fooKeith Packard2011-10-205-60/+115
|\
| * drm/i915: Initialize PCH refclks at modeset init timeKeith Packard2011-09-283-3/+11
| | | | | | | | | | | | | | | | | | | | | | The reference clock configuration must be done before any mode setting can occur as all outputs must be disabled to change anything. Initialize the clocks after turning everything off during the initialization process. Also, re-initialize the refclk at resume time. Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: All PCH refclks are 120MHzKeith Packard2011-09-281-10/+4
| | | | | | | | | | | | | | | | I can't find any reference clocks which run at 96MHz as seems to be indicated from the comments in this code. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
| * drm/i915: Use CK505 as non-SSC source where availableKeith Packard2011-09-281-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When trying to use SSC on Ibex Peak without CK505, any non-SSC outputs (like VGA or TV) get broken. So, do not use SSC on Ibex Peak unless there is a CK505 available (as specified by the VBT). On Cougar Point, all clocking is internal, so SSC can always be used, and there will never be a CK505 available. This eliminates VGA shimmer on some Ironlake machines which have a CK505 clock source. References: https://bugzilla.kernel.org/show_bug.cgi?id=21742 References: https://bugs.freedesktop.org/show_bug.cgi?id=38750 Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
| * drm/i915: Fix PCH SSC reference clock settingsKeith Packard2011-09-271-37/+59
| | | | | | | | | | | | | | | | | | | | | | The PCH refclk settings are global, so we need to look at all of the encoders, not just the current encoder when deciding how to configure it. Also, handle systems with more than one panel (any combination of PCH/non-PCH eDP and LVDS). Disable SSC clocks when no panels are connected. Signed-off-by: Keith Packard <keithp@keithp.com>
| * drm/i915: Allow SSC parameter to override VBT valueKeith Packard2011-09-272-3/+5
| | | | | | | | | | | | | | Allow SSC to be enabled even when the BIOS disables it for testing SSC paths. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
| * drm/i915: Document a few more BDB_GENERAL_FEATURES bits from PCH BIOSKeith Packard2011-09-271-1/+4
| | | | | | | | | | | | | | This includes whether an eDP panel is present, and whether that should use SSC (and at what frequency) Signed-off-by: Keith Packard <keithp@keithp.com>
| * drv/i915: Pull display_clock_mode out of VBT tableKeith Packard2011-09-273-3/+8
| | | | | | | | | | | | | | | | | | This tells the driver whether a CK505 clock source is available on pre-PCH hardware. If so, it should be used as the non-SSC source, leaving the internal clock for use as the SSC source. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wison <chris@chris-wilson.co.uk>
| * drm/i915: Use DRM_DEBUG_KMS for all messages in intel_bios.cKeith Packard2011-09-271-2/+7
| | | | | | | | | | | | | | | | These are all KMS related anyways, so don't hide them under other debug levels. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
| * drm/i915: broken copyright encoding in intel_bios.cKeith Packard2011-09-261-1/+1
| | | | | | | | Signed-off-by: Keith Packard <keithp@keithp.com>
* | Merge branch 'edp-training-fixes' into drm-intel-nextKeith Packard2011-10-205-122/+414
|\ \ | | | | | | | | | | | | | | | | | | Conflicts: drivers/gpu/drm/i915/intel_dp.c Just whitespace change conflicts
| * | drm/i915: No need to wait for eDP power off delay if panel is onKeith Packard2011-10-121-0/+9
| | | | | | | | | | | | | | | | | | | | | If the panel is powered up, there's no need to delay for the 'off' interval when turning the panel on. Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915: Restrict ILK-specific eDP power hack to ILKKeith Packard2011-10-121-22/+34
| | | | | | | | | | | | | | | | | | | | | | | | This eliminates a fairly long delay when power sequencing newer hardware Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Disable eDP VDD in a delayed work proc instead of synchronouslyKeith Packard2011-10-061-25/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no good reason to turn off the eDP force VDD bit synchronously while probing devices; that just sticks a huge delay into all mode setting paths. Instead, queue a delayed work proc to disable the VDD force bit and then remember when that fires to ensure that the appropriate delay is respected before trying to turn it back on. Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915: Create helper functions to determine eDP power stateKeith Packard2011-10-061-13/+26
| | | | | | | | | | | | | | | | | | | | | We need to check eDP VDD force and panel on in several places, so create some simple helper functions to avoid duplicating code. Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915: edp_panel_on does not need to return a boolKeith Packard2011-10-061-4/+2
| | | | | | | | | | | | | | | | | | | | | The return value was unused, so just stop doing that. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Move eDP panel fixed mode from dev_priv to intel_dpKeith Packard2011-10-062-20/+16
| | | | | | | | | | | | | | | | | | | | | | | | This value doesn't come directly from the VBT, and so is rather specific to the particular DP output. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Correct eDP panel power sequencing delay computationsKeith Packard2011-10-064-40/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Store the panel power sequencing delays in the dp private structure, rather than the global device structure. Who knows, maybe we'll get more than one eDP device in the future. From the eDP spec, we need the following numbers: T1 + T3 Power on to Aux Channel operation (panel_power_up_delay) This marks how long it takes the panel to boot up and get ready to receive aux channel communications. T8 Video signal to backlight on (backlight_on_delay) Once a valid video signal is being sent to the device, it can take a while before the panel is actuall showing useful data. This delay allows the panel to get something reasonable up before the backlight is turned on. T9 Backlight off to video off (backlight_off_delay) Turning the backlight off can take a moment, so this delay makes sure there is still valid video data on the screen. T10 Video off to power off (panel_power_down_delay) Presumably this delay allows the panel to perform an orderly shutdown of the display. T11 + T12 Power off to power on (panel_power_cycle_delay) So, once you turn the panel off, you have to wait a while before you can turn it back on. This delay is usually the longest in the entire sequence. Neither the VBIOS source code nor the hardware documentation has a clear mapping between the delay values they provide and those required by the eDP spec. The VBIOS code actually uses two different labels for the delay values in the five words of the relevant VBT table. **** MORE LATER *** Look at both the current hardware register settings and the VBT specified panel power sequencing timings. Use the maximum of the two delays, to make sure things work reliably. If there is no VBT data, then those values will be initialized to zero, so we'll just use the values as programmed in the hardware. Note that the BIOS just fetches delays from the VBT table to place in the hardware registers, so we should get the same values from both places, except for rounding. VBT doesn't provide any values for T1 or T2, so we'll always just use the hardware value for that. The panel power up delay is thus T1 + T2 + T3, which should be sufficient in all cases. The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy for T11, which isn't available anywhere. For the backlight delays, the eDP spec says T6 + T8 is the delay from the end of link training to backlight on and T9 is the delay from backlight off until video off. The hardware provides a 'backlight on' delay, which I'm taking to be T6 + T8 while the VBT provides something called 'T7', which I'm assuming is s On the macbook air I'm testing with, this yields a power-up delay of over 200ms and a power-down delay of over 600ms. It all works now, but we're frobbing these power controls several times during mode setting, making the whole process take an awfully long time. Signed-off-by: Keith Packard <keithp@keithp.com>
| * | drm/i915: Ensure eDP powered up during DP_SET_POWER operation in dp_prepareKeith Packard2011-10-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Any call to intel_dp_sink_dpms must ensure that the panel has power so that the DP_SET_POWER operation will be correctly received. The only one missing this was in intel_dp_prepare. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud