- 08 3月, 2014 2 次提交
-
-
由 Imre Deak 提交于
Since the encoder is tied to its port, we need to make sure the power domain for that port is on before reading out the encoder HW state. Note that this also covers also all connector get_hw_state handlers, since all those just call the corresponding encoder get_hw_state handler, which checks - after this change - for all power domains the connector needs. v2: - no change v3: - push down the power domain checks into the specific encoder get_hw_state handlers (Daniel) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The connector detect and get_mode handlers need to access the port specific HW blocks to read the EDID etc. Get/put the port power domains around these handlers. v2: - get port power domain for HDMI too (Ville) - get port power domain for the DP,HDMI audio detect handlers (Jesse) - Leave the intel_runtime_pm_get/put in the DP detect function in place. Instead of just removing them, these should be moved to the appropriate power_well enable/disable handlers. We can do this after Paulo's 'Merge PC8 with runtime PM, v2' patchset. v3: - rebased on latest -nightly Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 3月, 2014 2 次提交
-
-
由 Daniel Vetter 提交于
... it's this time of the year again. Originally we've frobbed this to fix up some regressions, but maybe our DP code improved sufficiently now that we can dare to do again what the spec recommends. This reverts commit 2514bc51 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 21 15:13:50 2012 -0700 drm/i915: prefer wide & slow to fast & narrow in DP configs I'm pretty sure I'll regret this patch, but otoh I expect we won't make progress here without poking the devil occasionally. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694 Cc: peter@colberg.org Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: NItai BEN YAACOV <candeb@free.fr> Tested-by: NDavid En <d.engraf@arcor.de> Reported-and-Tested-by: NMarcus Bergner <marcusbergner@gmail.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Patrik Jakobsson 提交于
This patch fixes the blank screen bug introduced in 3.14-rc1 on the MacBook Air 6,2. The comments state that we need to force edp vdd so lets put it back. The regression was introduced by the following commit: commit dff392db Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel v2: Wrap intel_disable_dp() with _vdd_on and _vdd_off Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 2月, 2014 2 次提交
-
-
由 Imre Deak 提交于
Atm we set the parent of the dp i2c device to be the correspondig connector device. During driver cleanup we first remove the connector device through intel_modeset_cleanup()->drm_sysfs_connector_remove() and only after that the i2c device through the encoder's destroy callback. This order is not supported by the device core and we'll get a warning, see the below bugzilla ticket. The proper order is to remove first any child device and only then the parent device. The first part of the fix changes the i2c device's parent to be the drm device. Its logical owner is not the connector anyway, but the encoder. Since the encoder doesn't have a device object, the next best choice is the drm device. This is the same what we do in the case of the sdvo i2c device and what the nouveau driver does. The second part creates a symlink in the connector's sysfs directory pointing to the i2c device. This is so, that we keep the current ABI, which also makes sense in case someone wants to look up the i2c device belonging to a specific connector. Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038782.html Reference: http://lists.freedesktop.org/archives/intel-gfx/2014-February/039427.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70523Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
Since commit d9255d57 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 13 2月, 2014 3 次提交
-
-
由 Jani Nikula 提交于
Retrying indefinitely places too much trust on the aux implementation of the sink devices. Reported-by: NDaniel Martin <consume.noise@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267Signed-off-by: NJani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Tested-by: NTheodore Ts'o <tytso@mit.edu> Tested-by: NSree Harsha Totakura <freedesktop@h.totakura.in> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Give more slack to sink devices before retrying on native aux defer. AFAICT the 100 us timeout was not based on the DP spec. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org (on Jani's request) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Instead of modifying intel_panel in lvds_init_connector/dsi_init/ edp_init_connector, making changes to move intel_panel->downclock_mode initialization to intel_panel_init() v2: Jani's review comments incorporated Removed downclock_mode local variable in dsi_init and edp_init_connector Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Signed-off-by: NPradeep Bhat <pradeep.bhat@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 2月, 2014 1 次提交
-
-
由 Daniel Vetter 提交于
Apparently it's broken in the exact same way as the gmbus irq. For reference of the full story see commit c12aba5a Author: Jiri Kosina <jkosina@suse.cz> Date: Tue Mar 19 09:56:57 2013 +0100 drm/i915: stop using GMBUS IRQs on Gen4 chips The effect is that we have a storm of unclaimed interrupts on the legacy irq line. If that one is used by a different device then the kernel will complain and rather quickly kill the irq source. Which breaks any device trying to actually use the legacy irq line. This regression has been introduced commit 4aeebd74 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 31 09:53:36 2013 +0100 drm/i915: dp aux irq support for g4x/vlv Note that disabling MSI works around the issue, but we can't do that since apparently then the hw will miss interrupts. At least if relevant comments in i915_irq.c are accurate. v2: Cross-reference dp aux and gmbus gen4 comments. v3: Consolidate harder into i915_drv.h as suggested by Chris. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: NJiri Kosina <jkosina@suse.cz> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 31 1月, 2014 1 次提交
-
-
由 Imre Deak 提交于
Atm we setup the HW panel power sequencer logic both for eDP and DP ports. On eDP we then go on and start the power on sequence and commence with link training when it's ready. On DP we don't do the power on sequencing but do the link training immediately. At this point the DP PHY block gets stuck, since - supposedly - it is waiting for the power on sequence to finish. The actual register write that seems to hold off the PHY is PIPEX_PP_ON_DELAYS[Panel Control Port Select]. Writing here a non-0 value eventually sets PIPEX_PP_STATUS[Require Asset Status] to 1 and blocks the PHY until the panel power on is ready. Fix this by not doing any PP sequencing setup for DP ports. Thanks to Ville Syrjälä, Jesse Barnes and Todd Previte for the help in tracking this down. Note that on older gmch platforms (where we have lvds instead of edp) we've hacked around this by writing the magic ABCD unlock key to PP registers, which disables the hw sanity checks. For edp all platforms thus far had the pch split, with the edp port in the north display complex and the PP registers on the pch the hw sanity checks (expressed through the "Require Asset Status" bit) was never functional, hence never a real issue. This regression has been introduce in commit bf13e81b Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 6 07:40:05 2013 +0300 drm/i915: add support for per-pipe power sequencing on vlv Signed-off-by: NImre Deak <imre.deak@intel.com> [danvet: Add note about the bigger story here.] Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 1月, 2014 1 次提交
-
-
由 Imre Deak 提交于
The initial jiffies value can be non-0, so set the inital panel power sequencer timestamps accordingly. This didn't cause a problem on 64 bit machines but on 32 bit jiffies is initially -300*HZ, so if the panel power is initally off in the call from edp_panel_vdd_on()-> wait_panel_power_cycle() we'd wait up to ~300 sec more than needed. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 28 1月, 2014 1 次提交
-
-
由 Jani Nikula 提交于
With 20+ module parameters, I think referring to them via a struct improves clarity over just having a bunch of globals. While at it, move the parameter initialization and definitions into a new file i915_params.c to reduce clutter in i915_drv.c. Apart from the ill-named i915_enable_rc6, i915_enable_fbc and i915_enable_ppgtt parameters, for which we lose the "i915_" prefix internally, the module parameters now look the same both on the kernel command line and in code. For example, "i915.modeset". The downsides of the change are losing static on a couple of variables and not having the initialization and module_param_named() right next to each other. On the other hand, all module parameters are now defined in one place at i915_params.c. Plus you can do this to find all module parameter references: $ git grep "i915\." -- drivers/gpu/drm/i915 v2: - move the definitions into a new file - s/i915_params/i915/ - make i915_try_reset i915.reset, for consistency Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 1月, 2014 1 次提交
-
-
由 Rodrigo Vivi 提交于
This debugfs interface will allow intel-gpu-tools test case to verify if screen has been updated properly on cases like PSR. v2: Accepted all Daniel's suggestions: * grab modeset lock * loop over connector and check DPMS on * return errors * use _eDP1 suffix for easy future extension * don't cache crc_supported neither latest crc * return crc as a full array and read it at once with aux. * use 0 to turn TEST_SINK off. * split the drm_helpers definitions in another patch. v3: Accepted 2 Damien's suggestion: remove h from printf hexa and return ENODEV when eDP not present instead of EAGAIN. v4: Accepted 2 Jani' s suggestion: 1 path for unlock and remove _retry from aux read. v5: removing last missing useless _retry (by Damien) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 25 1月, 2014 11 次提交
-
-
由 Damien Lespiau 提交于
We need a bit more flexibility here in the future, bits get shuffled around. v2: more descriptive commit message (Jani Nikula) Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
So it's easier to compare what we program with the documentation, not having to jump at all. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Also, move that computation outside of the for loop that tries 5 times, this value doesn't change between tries. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
A tiny clean-up to allow better code separation between platforms. v2: Fix comment placement (put in in i9xx_get_aux_clock_divider()) and nuke the outdated PCH eDP comment (Jani Nikula) Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Todd Previte 提交于
For HSW+ platforms, enable the 5.4Ghz (HBR2) link rate for devices that support it. The sink device must report that is supports Displayport 1.2 and the HBR2 bit rate in the DPCD in order to use HBR2. Signed-off-by: NTodd Previte <tprevite@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
Because we already do the wait in software: see ironlake_wait_backlight_on and ironlake_edp_wait_backlight_off. For the "backlight on" delay, even BSpec says we need to program 0x1 to PP_ON_DELAYS 12:0. For the "backlight off" delay, if we don't do the same thing, when we call ironlake_wait_panel_off we'll end up waiting for the it again. On my machine the off delay is 200ms, so we save this amount of time whenever we disable the panel (e.g, suspend). Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
Function ironlake_wait_panel_off should just wait for the power off delay, while function ironlake_wait_panel_power_cycle should wait for the panel cycle (that's required after we turn the panel off, before we enable it again). The problem is that, currently, ironlake_wait_panel_off is waiting not just for the panel to be off, but also for the power cycle delay and the backlight off delay. This function relies on the PP_STATUS bits 3:0, which are not documented and not supposed to be used. A quick analysis of the values we get while waiting quickly shows that power off is reached while bits 3:0 are still 0x1, and the time it takes to become 0x0 is the power cycle delay. On my system with backlight off delay of 200ms, power down delay of 50ms and power cycle delay of 500ms, this is what I get: - Start waiting with value 0x80000008, timestamp 6.429364. - Jumps to 0xa0000003, timestamp 6.431360 (time waited: 0.001996) - Jumps to 0xa0000002, timestamp 6.631277 (time waited: 0.201913) - Jumps to 0x08000001, timestamp 6.681258 (time waited: 0.251894) - Jumps to 0x00000000, timestamp 7.192012 (time waited: 0.762648) As you can see, ironlake_wait_panel_off is sleeping 760ms instead of the expected 50ms: the first 200ms matches the backlight off delay (which we should already have waited for!), then the 50ms for the real panel off delay, then the 500ms for the panel power cycle. This patch makes is look just at bits 31 and 29:28, which will ignore the panel power cycle. And just to be clear: this saves 500ms on my system every time we disable the panel. But we can still save 200ms more (the backlight off delay) on the next patches. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuougseek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
I like how the macros are nicely column-aligned, so we can properly compare what each macro waits for, but a column full of zeroes doesn't really help anything: it just makes the lines bigger, and they're already way past 80 columns. I imagine this column was used in the past, but IMHO now we can get rid of it. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
They now also work on vlv, which has the regs somewhere else. And daring a glance into the looking glass it seems like this functionality will continue to work the same for the next few hardware platforms. So it's better to just remove that misleading prefix and have a bit shorter code for better readability. The only exceptions are the panel/backlight functions shared with intel_ddi.c, those get an intel_ prefix. While at it make the vdd_on/off functions static. And one straggler was missing the edp_ in the name, so make everything neatly OCD. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
The eDP spec defines some points where after you do action A, you have to wait some time before action B. The thing is that in our driver action B does not happen exactly after action A, but we still use msleep() calls directly. What this patch does is that we record the timestamp of when action A happened, then, just before action B, we look at how much time has passed and only sleep the remaining amount needed. With this change, I am able to save about 5-20ms (out of the total 200ms) of the backlight_off delay and completely skip the 1ms backlight_on delay. The 600ms vdd_off delay doesn't happen during normal usage anymore due to a previous patch. v2: - Rename ironlake_wait_jiffies_delay to intel_wait_until_after and move it to intel_display.c - Fix the msleep call: diff is in jiffies v3: - Use "tmp_jiffies" so we don't need to worry about the value of "jiffies" advancing while we're doing the math. v4: - Rename function again. - Move function to i915_drv.h. - Store last_power_cycle at edp_panel_off too. - Use msecs_to_jiffies_timeout, then replace the msleep with an open-coded version that avoids the extra +1 jiffy. - Try to add units to every variable name so we don't confuse jiffies with milliseconds. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
Our driver has two different ways of waiting for panel power sequencing delays. One of these ways is through ironlake_wait_panel_status, which implicitly uses the values written to our registers. The other way is through the functions that call intel_wait_until_after, and on this case we do direct msleep() calls on the intel_dp->xxx_delay variables. Function intel_dp_init_panel_power_sequencer is responsible for initializing the _delay variables and deciding which values we need to write to the registers, but it does not write these values to the registers. Only at intel_dp_init_panel_power_sequencer_registers we actually do this write. Then problem is that when we call intel_dp_i2c_init, we will get some I2C calls, which will trigger a VDD enable, which will make use of the panel power sequencing registers and the _delay variables, so we need to have both ready by this time. Today, when this happens, the _delay variables are zero (because they were not computed) and the panel power sequence registers contain whatever values were written by the BIOS (which are usually correct). What this patch does is to make sure that function intel_dp_init_panel_power_sequencer is called earlier, so by the time we call intel_dp_i2c_init, the _delay variables will already be initialized. The actual registers won't contain their final values, but at least they will contain the values set by the BIOS. The good side is that we were reading the values, but were not using them for anything (because we were just skipping the msleep(0) calls), so this "fix" shouldn't fix any real existing bugs. I was only able to identify the problem because I added some debug code to check how much time time we were saving with my previous patch. Regression introduced by: commit ed92f0b2 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Wed Jun 12 17:27:24 2013 -0300 drm/i915: extract intel_edp_init_connector v2: - Rewrite commit message. Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 23 1月, 2014 1 次提交
-
-
由 Todd Previte 提交于
Add new definitions for hotplug live status bits for VLV2 since they're in reverse order from the gen4x ones. Changelog: - Restored gen4 bit definitions - Added new definitions for VLV2 - Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct bit defintions - Replaced a lost trailing brace for the added switch() Signed-off-by: NTodd Previte <tprevite@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951 [danvet: Switch to _VLV postfix instead of prefix and regroupg comments again so that the g4x warning is right next to those defines. Also add a _G4X suffix for those special ones. Also cc stable.] Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 22 1月, 2014 2 次提交
-
-
由 Imre Deak 提交于
Atm after a failed link training we disable the DP port. This can happen during a modeset-enable or a DP link re-establishment. The latter can be a problem and we shouldn't disable the DP port, see the previous patch for the reasoning. In the former case the right thing would be to disable the DP port, but also the rest of the pipe. As a stop-gap solution leave the DP port enabled in both cases. It is an improvement on its own (avoiding HW lock ups) and the proper solution for the first case requires a bigger change, so let's keep that on the TODO list. v2: - fix explanation of change impact (Chris) Suggested-by: NDaniel Vetter <daniel@ffwll.ch> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
Currently if the DP link is lost (either because of a hot unplug, or failed link status check) we disable the DP port, but leave the rest of the pipe running. This is incompatible with the modeset disabling sequence of some platforms/configurations. At least this is the case for DP ports on the CPU as opposed to PCH. Atm we'll also get a warning when we do a modeset disable after the above link lost event, since we expect the DP port to be enabled at this point (see the bugzilla ticket for the related dmesg). Note that with this patch we'll still end up disabling the port, thanks to the HPD uevent and subsequent modeset disable. See also the next patch fixing the other half of this issue. Solution suggested by Ville. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 12月, 2013 1 次提交
-
-
由 Thierry Reding 提交于
The current values seem to be defined in a format that's specific to the i915, gma500 and radeon drivers. To make this more generally useful, use the values as defined in the specification. While at it, prefix the constants with DP_ for improved namespacing. Signed-off-by: NThierry Reding <treding@nvidia.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 12月, 2013 2 次提交
-
-
由 Paulo Zanoni 提交于
If we're disabling the VDD override bit and the panel is enabled, we don't need to wait for anything. If the panel is disabled, then we need to actually wait for panel_power_cycle_delay, not panel_power_down_delay, because the power down delay was already respected when we disabled the panel. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
I don't see a reason to touch VDD when we're disabling the panel: since the panel is enabled, we don't need VDD. This saves a few sleep calls from the vdd_on and vdd_off functions at every modeset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo. Also drop the runtime_pm_put call which now has to go due to different patch ordering. Also from Paul.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 12月, 2013 2 次提交
-
-
由 Paulo Zanoni 提交于
And put it when it's off. Otherwise, when you run pm_pc8 from intel-gpu-tools, and the delayed function that disables VDD runs, we'll get some messages saying we're touching registers while the HW is suspended. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
These are needed when we cat the debugfs and sysfs files. V2: - Rebase V3: - Rebase V4: - Rebase Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 12月, 2013 2 次提交
-
-
由 Chris Wilson 提交于
When inspecting reports that boot/suspend/resume times are unusual it would be useful to clearly identify the time we must spend waiting for the hardware to complete its task. In this case we have a notification before we start waiting for the panel to change state, but none afterwards - which would be useful. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Sweeping some dead code away. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 28 11月, 2013 3 次提交
-
-
由 Damien Lespiau 提交于
We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Reduce the eDP detection to just checking if it's port A, or if the VBT tells us that the port is eDP for the other ports. Suggested-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
VLV can have eDP on either port B or C, or even both. Based on the VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we check the correct ports. So instead of hardcoding port D, rename the function to intel_dp_is_edp() and pass the port as a parameter, and use it on VLV ports B and C. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051Tested-by: NRobert Hooker <robert.hooker@canonical.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> [danvet: Wrestle the patch to apply and compile properly.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 11月, 2013 1 次提交
-
-
由 Daniel Vetter 提交于
Now we have this everywhere. Next up would be to wire up the DP hotplug pin to speed up panel power sequencing for eDP panels ... I've decided to leave the has_aux_irq logic in the code, it should come handy for hw bringup. For testing/fail-safety the dp aux code already has a timeout when waiting for interrupts to signal completion and screams rather loud if they don't arrive in time. Given that we need a real piece of hw to talk to anyway this is probably as good as it gets. v2: Don't check the dp aux channel bits on i965 machines, they have a different meaning there. Yay for reusing bits at will! Spotted by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 11月, 2013 1 次提交
-
-
由 Jani Nikula 提交于
We used to put the local sink and any downstream sinks to power down mode at disable or dpms off using the DPCD SET_POWER register, until this was broken by commit e8cb4558 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 1 13:05:48 2012 +0200 drm/i915/dp: convert to encoder disable/enable Fix it. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NTodd Previte <tprevite@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-