- 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 5 次提交
-
-
由 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>
-
- 16 8月, 2011 1 次提交
-
-
由 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>
-
- 04 8月, 2011 1 次提交
-
-
由 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 1 次提交
-
-
由 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>
-
- 29 7月, 2011 4 次提交
-
-
由 Keith Packard 提交于
This reverts commit 885a5014. We actually *do* need to track DPMS state so that on hotplug, we don't retrain the link until DPMS is disabled. However, that code had avery small bug -- it wouldn't set the dpms_mode at mode set time, and so link retraining would not actually occur on monitor hotplug until the monitor had gone through a DPMS off/DPMS on cycle. Signed-off-by: NKeith Packard <keithp@keithp.com> Tested-by: NAndrew Lutomirski <luto@mit.edu>
-
由 Keith Packard 提交于
Eliminates an open-coded read and also gains the retry behaviour of intel_dp_get_dpcd, which seems like a good idea. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAdam Jackson <ajax@redhat.com>
-
由 Keith Packard 提交于
This describes the function better, allowing it to be used where the DPCD value is relevant. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAdam Jackson <ajax@redhat.com>
-
由 Keith Packard 提交于
This uses the common dpcd reading routine, i915_dp_detect_common, instead of open-coding a call to intel_dp_aux_native_read. Besides reducing duplicated code, this also gains the read retries which may be necessary when a cable is first plugged back in and the link needs to be retrained. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAdam Jackson <ajax@redhat.com>
-
- 26 7月, 2011 8 次提交
-
-
由 Adam Jackson 提交于
The docs say the port has to come on in training pattern 1; at this point, though, ->DP is in normal mode. The intent here is to wait until the port is in fact sending data, but that doesn't happen since we've broken the sequence the hardware expects, and the vblank wait will time out and kvetch in the log. Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
The DP spec says training patterns 1 and 2 are to be sent non-scrambled, and the GPU docs claim that happens (or at least, there's no explicit scrambling control). But the sink may be confused if we don't explicitly tell it what we're doing, so play it safe. Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
It's not clear what a sink would do if you wrote zero to this register - which I guess would mean "I don't support any channel encodings, good luck" - but let's not find out. Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
%hx alone prints 0 as "0", not "00". Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
For parity with radeon and nouveau, and also because I suspect we're going to need it to get format-conversion dongles right. Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
No reason not to see this on g4x, after all. Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 08 7月, 2011 9 次提交
-
-
由 Jesse Barnes 提交于
On sinks with a DPCD rev of 1.1 or greater, we can send sink power management commands to address 0x600 per section 5.1.5 of the DisplayPort 1.1a spec. 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 提交于
When checking link status during a hot plug event or detecting sink presence, we need to retry 3 times per the spec (section 9.1 of the 1.1a DisplayPort spec). Consolidate the retry code into a native_aux_read_retry function for use by get_link_status and _detect. 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 提交于
We currently use this when a hot plug event is received, only checking the link status and re-training if we had previously configured a link. However if we want to preserve the DP configuration across both hot plug and DPMS events (which we do for userspace apps that don't respond to hot plug uevents), we need to unconditionally check the link and try to bring it up on hot plug. 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 提交于
If ->detect is called too soon after a hot plug event, the sink may not be ready yet. So try up to 3 times with 1ms sleeps in between tries to get the data (spec dictates that receivers must be ready to respond within 1ms and that sources should try 3 times). See section 9.1 of the 1.1a DisplayPort spec. 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 提交于
When a hotplug event is received, we need to check the receiver cap bits in case they've changed (as they might with a hub or chain config). 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 提交于
Makes it easier to search for DP related constants. Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
Especially after a hotplug or power status change, the sink may not reply immediately to a link status query. So retry 3 times per the spec to really make sure nothing is there. See section 9.1 of the 1.1a DisplayPort spec. 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 提交于
Now that we track bpp on a per-pipe basis, we can use the actual value rather than assuming 24bpp. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Jesse Barnes 提交于
The pipe may be driving various bpp values depending on the display configuration, so take that into account when calculating link bandwidth requirements. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 05 6月, 2011 1 次提交
-
-
由 Chris Wilson 提交于
Make the audio property creation routine common and share the single property between the connectors. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 05 5月, 2011 1 次提交
-
-
由 Chris Wilson 提交于
Given that the hardware may be left in a random condition by the BIOS, it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit without us ever enabling/attaching the DP encoder to a pipe. Thus causing a NULL deference when we attempt to wait for a vblank on that crtc. Reported-and-tested-by: NBryan Christ <bryan.christ@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36314Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36456Reported-and-tested-by: NBo Wang <bo.b.wang@intel.com> Cc: stable@kernel.org Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 31 3月, 2011 1 次提交
-
-
由 Lucas De Marchi 提交于
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
-