- 06 10月, 2011 8 次提交
-
-
由 Keith Packard 提交于
The return value was unused, so just stop doing that. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
This value doesn't come directly from the VBT, and so is rather specific to the particular DP output. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
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: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
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: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
The DP i2c initialization code does a couple of i2c transactions, which means that an eDP panel must be powered up. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
Talking to the eDP DDC channel requires that the panel be powered up. Wrap both the EDID and modes fetch code with calls to turn the vdd power on and back off. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
On eDP, DDC requires panel power, but turning that on uses the panel power sequencing timing values fetch from the DPCD data. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
If the panel is already off, we'll need to turn VDD on to execute the (useless) DPMS off code. Yes, it would be better to just not do any of this, but correctness, and *then* performance. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 01 10月, 2011 7 次提交
-
-
由 Keith Packard 提交于
The VDD force bit is turned on before touching the panel, but if it was enabled, there was no call to turn it back off. Add a call. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
Cleans up code dealing with eDP a bit. Remove redundant checks in callers Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Avoid any question about locked registers by just writing the unlock pattern with every write to the register. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Verify that the eDP VDD is on, either with the panel being on or with the VDD force-on bit being set. This demonstrates that in many instances, VDD is not on when needed, which leads to failed EDID communications. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
We're going to assume that EDID is more reliable than the VBT tables for eDP panels, which is notably true on MacBook machines where the VBT contains completely bogus data. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
This masks out all interrupts and ack's any pending ones at IRQ uninstall time to make sure we don't receive any unexpected interrupts later on. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
We were relying on the BIOS to set these bits, which doesn't always happen. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 9月, 2011 2 次提交
-
-
由 Keith Packard 提交于
Make the default FBC behaviour chipset specific, allowing us to turn it on by default for Ironlake and older where it has been seen to cause trouble with screen updates. Signed-off-by: NKeith Packard <keithp@keithp.com> Tested-by: NFrancis Moreau <francis.moro@gmail.com>
-
由 Simon Farnsworth 提交于
I was seeing a nasty 5 frame glitch every 10 seconds, caused by the poll for connection on DVI attached by SDVO. As my SDVO DVI supports hotplug detect interrupts, the fix is to enable them, and hook them in to the various bits of driver infrastructure so that they work reliably. Note that this is only tested on single-function DVI-D SDVOs, on two platforms (965GME and 945GSE), and has not been checked against a specification document. With lots of help from Adam Jackson <ajax@redhat.com> on IRC. Signed-off-by: NSimon Farnsworth <simon.farnsworth@onelan.co.uk> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 20 9月, 2011 1 次提交
-
-
由 Keith Packard 提交于
We want to enable dithering on any pipe where the frame buffer has more color resolution than the output device. The previous code was incorrectly clamping the frame buffer bpc to the display bpc, effectively disabling dithering all of the time as the computed frame buffer bpc would never be larger than the display bpc. Signed-off-by: NKeith Packard <keithp@keithp.com> Reported-by: NOliver Hartkopp <socketcan@hartkopp.net> Tested-by: NOliver Hartkopp <socketcan@hartkopp.net>
-
- 26 8月, 2011 1 次提交
-
-
由 Thomas Jarosch 提交于
Otherwise it just contains random memory. Issue detected by cppcheck. Signed-off-by: NThomas Jarosch <thomas.jarosch@intra2net.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 23 8月, 2011 1 次提交
-
-
由 Kamal Mostafa 提交于
The commit "Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support" adds calls to intel_panel_setup_backlight() from intel_{lvds,dp}_init so do not call it again from intel_setup_outputs(). BugLink: http://bugs.launchpad.net/bugs/831542Signed-off-by: NKamal Mostafa <kamal@canonical.com> ACKed-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 20 8月, 2011 1 次提交
-
-
由 Jesse Barnes 提交于
Prior to Ivybridge, the GFX_MODE would default to 0x800, meaning that MI_FLUSH would flush the TLBs in addition to the rest of the caches indicated in the MI_FLUSH command. However starting with Ivybridge, the register defaults to 0x2800 out of reset, meaning that to invalidate the TLB we need to use PIPE_CONTROL. Since we're not doing that yet, go back to the old default so things work. v2: don't forget to actually *clear* the new bit Reviewed-by: NEric Anholt <eric@anholt.net> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Tested-by: NKenneth Graunke <kenneth@whitecape.org> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 16 8月, 2011 3 次提交
-
-
由 Keith Packard 提交于
The clock gating functions are only assigned under KMS, so don't try to call them under UMS. Signed-off-by: NKeith Packard <keithp@keithp.com> Tested-by: NJustin P. Mattock <justinmattock@gmail.com>
-
由 Keith Packard 提交于
Disable this feature when KMS is not running by setting the driver->get_vblank_timestamp function pointer to NULL. Signed-off-by: NKeith Packard <keithp@keithp.com> Tested-by: NJustin P. Mattock <justinmattock@gmail.com>
-
由 Matthew Garrett 提交于
Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: David Airlie <airlied@linux.ie> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NSedat Dilek <sedat.dilek@googlemail.com> Tested-by: NMichel Alexandre Salim <salimma@fedoraproject.org> Tested-by: NKamal Mostafa <kamal@canonical.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 10 8月, 2011 2 次提交
-
-
由 Jesse Barnes 提交于
We ought to be calling this from our DPMS routines as well as global state may change and we need to enable/disable clocks. So split out the code in preparation for further changes. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
IVB uses the same interrupt reg layout as SNB, so add an IS_GEN7 to the interrupt debugfs file. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 09 8月, 2011 4 次提交
-
-
由 Keith Packard 提交于
Just an extra parameter which isn't actually needed. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Keith Packard 提交于
CPT pipe select is different from previous generations (using two bits instead of one). All of the paths from intel_disable_pch_ports were not making this distinction. Mode setting with pipe A turned off would then also force all outputs on pipe B to get turned off as the disable code would mistakenly decide that all of these outputs were on pipe A and turn them off. This is an extension of the CPT DP disable fix (why didn't I fix this then?) Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Keith Packard 提交于
There's no reason to relock them; it just makes operations more complex. This fixes DPMS where the panel registers were locked making the disable not work. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Keith Packard 提交于
During mode setting, check to make sure the panel power sequencing has completed before doing further operations on the device. This uncovered errors with DPMS not turning the device off as it was left locked. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 05 8月, 2011 1 次提交
-
-
由 Dave Airlie 提交于
This reverts commit 4e20fa65. Francesco Allertsen still has a broken configuration. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 04 8月, 2011 5 次提交
-
-
由 Jesse Barnes 提交于
Expose the SNB+ cache sharing policy register in debugfs. The new file, i915_cache_sharing, has 4 values, 0-3, with 0 being "max uncore resources" and 3 being the minimum. Exposing this control should make benchmarking easier and help us choose a good default. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
Set an SPD infoframe if the sink supports it. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
This makes it easier to add support for other infoframes (e.g. SPD, vendor specific). Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Jesse Barnes and I found a couple of issues where incorrect mode setting would cause problems with RC6 enabled. We're hopeful that fixing those will resolve the outstanding issues with a few machines that had trouble before 3.0 with rc6. Cc: Pekka Enberg <penberg@kernel.org> Cc: Francesco Allertsen <fallertsen@gmail.com> Cc: Ted Phelps <phelps@gnusto.com> Cc: Gu Rui <chaos.proton@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38567 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38332Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
This reverts commit 97cdd710. Clearing the dpcd data means that if the fetch fails, any previous data will be lost. On eDP, this is no fun as we only fetch dpcd at init time, so the memset will destroy that the next time through.
-
- 02 8月, 2011 2 次提交
-
-
由 Jesse Barnes 提交于
Before initiating a new read or write on the DP AUX channel, wait for any outstanding activity to complete. This may happen during normal retry behavior. If the wait fails (i.e. after 1ms the AUX channel is still busy) dump a backtrace to make the caller easier to spot. v2: use msleep instead, and timeout after 3ms (only ever saw 1 retry with msleep in testing) v3: fix backtrace check to trigger if the 3ms wait times out Fixes https://bugs.freedesktop.org/show_bug.cgi?id=38136. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
The EDID parser will zero out the bpc value, and the driver needs to handle that case. In our picker, we'll just ignore 0 values as far as bpp picking goes. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39323. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 30 7月, 2011 2 次提交
-
-
由 Adam Jackson 提交于
At least on a Lenovo X220 the HPD bits of this are enabled at boot but cleared after resume, which means plug interrupts stop working. This also happens to fix DP displays re-lighting on resume. I'm quite certain that's an accident: the first DP link train inevitably fails on that machine, and it's only serendipity that we're getting multiple plug interrupts and the second train works. But I shall take my victories where I get them. Signed-off-by: NAdam Jackson <ajax@redhat.com> Tested-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
These bits moved around on SNB and above. v2: again with the git send-email fail v3: add macros for getting per-pipe override & enable bits v4: enable phase sync pointer on SNB and IVB configs as well Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-