- 28 1月, 2014 1 次提交
-
-
由 Chris Wilson 提交于
Through a twisty and circuituous path it is possible to currently trick the code into creating a default context and forgetting to pin it immediately into the GGTT. (This requires a system using contexts without an aliasing ppgtt, which is currently restricted to Baytrails machines manually specifying a module parameter to force enable contexts, or on Sandybridge and later that manually disable the aliasing ppgtt.) The consequence is that during module unload we attempt to unpin the default context twice and encounter a BUG remonstrating that we attempt to unpin an unbound object. [ 161.002869] Kernel BUG at f84861f8 [verbose debug info unavailable] [ 161.002875] invalid opcode: 0000 [#1] SMP [ 161.002882] Modules linked in: coretemp kvm_intel kvm crc32_pclmul aesni_intel aes_i586 xts lrw gf128mul ablk_helper cryptd hid_sensor_accel_3d hid_sensor_gyro_3d hid_sensor_magn_3d hid_sensor_trigger industrialio_triggered_buffer kfifo_buf industrialio hid_sensor_iio_common snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi snd_seq_midi_event dm_multipath scsi_dh asix ppdev usbnet snd_rawmidi mii hid_sensor_hub microcode snd_seq rfcomm bnep snd_seq_device bluetooth snd_timer snd parport_pc binfmt_misc soundcore dw_dmac_pci dw_dmac_core mac_hid lp parport dm_mirror dm_region_hash dm_log hid_generic usbhid hid i915(O-) drm_kms_helper(O) igb dca ptp pps_core i2c_algo_bit drm(O) ahci libahci video [ 161.002991] CPU: 0 PID: 2114 Comm: rmmod Tainted: G W O 3.13.0-rc8+ #2 [ 161.002997] Hardware name: NEXCOM VTC1010/Aptio CRB, BIOS 5.6.5 09/24/2013 [ 161.003004] task: dbdd6800 ti: dbe0e000 task.ti: dbe0e000 [ 161.003010] EIP: 0060:[<f84861f8>] EFLAGS: 00010246 CPU: 0 [ 161.003044] EIP is at i915_gem_object_ggtt_unpin+0x88/0x90 [i915] [ 161.003050] EAX: dfce3840 EBX: 00000000 ECX: dfafd690 EDX: dfce3874 [ 161.003056] ESI: c0086b40 EDI: df962e00 EBP: dbe0fe1c ESP: dbe0fe0c [ 161.003062] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 161.003068] CR0: 8005003b CR2: b7718000 CR3: 1bec0000 CR4: 001007f0 [ 161.003076] Stack: [ 161.003081] 00afc014 00000004 c0086b40 dfafc000 dbe0fe38 f8487e5a dfaa5400 c0086b40 [ 161.003099] dfafc000 dfaa5400 dfaa5414 dbe0fe58 f84741aa 00000000 f89c34b9 dfaa5414 [ 161.003117] dfaa5400 dfaa5400 f644b000 dbe0fe6c f89a5443 dfaa5400 f8505000 f644b000 [ 161.003134] Call Trace: [ 161.003169] [<f8487e5a>] i915_gem_context_fini+0xba/0x1c0 [i915] [ 161.003202] [<f84741aa>] i915_driver_unload+0x1fa/0x2f0 [i915] [ 161.003232] [<f89a5443>] drm_dev_unregister+0x23/0x90 [drm] [ 161.003259] [<f89a54ed>] drm_put_dev+0x3d/0x70 [drm] [ 161.003294] [<f8470615>] i915_pci_remove+0x15/0x20 [i915] [ 161.003306] [<c1338a6f>] pci_device_remove+0x2f/0xa0 [ 161.003317] [<c140c871>] __device_release_driver+0x61/0xc0 [ 161.003328] [<c140d12f>] driver_detach+0x8f/0xa0 [ 161.003341] [<c140c54f>] bus_remove_driver+0x4f/0xc0 [ 161.003353] [<c140d708>] driver_unregister+0x28/0x60 [ 161.003362] [<c10cee42>] ? stop_cpus+0x32/0x40 [ 161.003372] [<c10bd510>] ? module_refcount+0x90/0x90 [ 161.003383] [<c13378c5>] pci_unregister_driver+0x15/0x60 [ 161.003413] [<f89a739f>] drm_pci_exit+0x9f/0xb0 [drm] [ 161.003458] [<f84e624a>] i915_exit+0x1b/0x1d [i915] [ 161.003468] [<c10bf8a8>] SyS_delete_module+0x158/0x1f0 [ 161.003480] [<c1173d5d>] ? ____fput+0xd/0x10 [ 161.003488] [<c106f0fe>] ? task_work_run+0x7e/0xb0 [ 161.003499] [<c165a68d>] sysenter_do_call+0x12/0x28 [ 161.003505] Code: 0f b6 4d f3 8d 51 0f 83 e1 f0 83 e2 0f 09 d1 84 d2 88 48 54 75 07 80 a7 91 00 00 00 7f 83 c4 04 5b 5e 5f 5d c3 8d b6 00 00 00 00 <0f> 0b 8d b6 00 00 00 00 55 89 e5 57 56 53 83 ec 64 3e 8d 74 26 [ 161.003586] EIP: [<f84861f8>] i915_gem_object_ggtt_unpin+0x88/0x90 [i915] SS:ESP 0068:dbe0fe0c v2: Rename the local variable (is_default_ctx) to avoid confusion with the function is_default_ctx(). And correct Jesse's email address. Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73985Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <benjamin.widawsky@intel.com> [danvet: Fix up the rebase fail from my first attempt, thankfully pointed out by Ville.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 1月, 2014 2 次提交
-
-
由 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>
-
由 Rodrigo Vivi 提交于
This address will be used to verify panel CRC for test and validation purposes. Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Fix whitespace fail.] Acked-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 1月, 2014 14 次提交
-
-
由 Ville Syrjälä 提交于
Having a 4 byte register at 0x321b seems unlikely as that's not 4 byte aligned. Since later platforms have more or less the same FBC registers with new names, assume that FBC_FENCE_OFF is at 0x3218 just like DPFC_FENCE_YOFF. This feels like a simple typo in BSpec. 321Bh looks a lot like 3218h after all. Should still be tested on real hardware of course. But I don't have any mobile gen4 systems. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
The debug message telling FBC1 has been enabled is missing a newline. Add it. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
On CTG and IVB+ we don't try to preserve any bits from the DPFC_CONTROL register. Follow suit on ILK/SNB. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
We will anyway re-enable FBC normally after resume, so trying to save and restore the register makes little sense. We do need to preserve the FBC1 interval bits in FBC_CONTROL since we only initialize them during driver load, and try to preserve them after that. v2: s/I915_HAS_FBC/HAS_FBC/ and fix the check for gen4 Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
We set up all the bits for DPFC_CONTROL but forgot to actually write them to the register. Oops. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Make the FBC plane macros take the plane as a parameter. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
The ILK/SNB docs don't really mention the the DPFC_HT_MODIFY bit. CTG docs clearly state that it should be set only when tracking back buffer modification in persistent mode. The bit is supposed to be set by software after the first CPU modification to the back buffer, and it would get automagically cleared by the hardware on the next page flip. Since we only track front buffer modification we don't need to set this bit. GTT modification tracking still appears to work on ILK and SNB with the bit unset. I don't have a CTG to verify how that behaves. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
The ILK/SNB docs are a bit unclear what the persistent mode does, but the CTG docs clearly state that it was meant to be used when we're tracking back buffer modifications. We never do that, so leave it in non-persistent mode. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
We use nuking instead of render tracking on IVB+, so there's no point in writing IVB_FBC_RT_BASE. v2: Drop the IVB_FBC_RT_BASE write too v3: Move the SNB stuff elsewhere, leaving only IVB+ here Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Because whatever.* * This should contain a fairly long list of issues and still unresolved resgressions, but I didn't really get a vote. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
I want to see these without having full debugs enabled. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> [danvet: fix the gen8 irq handler as spotted by Paulo in his review.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Currently we print all pipe underruns on GMCH platforms. Hook up the same logic we use on PCH platforms where we disable the underrun reporting after the first underrun. Underruns don't actually generate interrupts themselves on GMCH platforms, we just can detect them whenever we service other interrupts. So we don't have any enable bits to worry about. We just need to remember to clear the underrun status when enabling underrun reporting. Note that the underrun handling needs to be moved to the non-locked pipe_stats[] loop in the interrupt handlers to avoid having to rework the locking in intel_set_cpu_fifo_underrun_reporting(). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
This is useful for debugging as we then know that the first entry is always the global GTT, and all later entries the per-process GTT VM. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 25 1月, 2014 23 次提交
-
-
由 Jesse Barnes 提交于
Forgot to convert to using the refclk variable when I added refclk readout support, and Paulo noticed the resulting calculation was off due to the way p & r are stored. Reported-by: NPaulo Zanoni <przanoni@gmail.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
This statenment became false here: commit 4fc688ce Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 2 11:14:01 2012 -0700 drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
Now that we have DDI support, we can check these all the time. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
Read out and calculate the port and pixel clocks on DDI configs as well. This means we have to grab the DP divider values and look at the port mapping to figure out which clock select reg to read out. v2: do the work from ddi_get_config (Ville) v3: check WRPLL reference clock (Ville) add additional SPLL freqs (Ville) clean up port/crtc clock calc (Ville) fix up crtc_clock conditionals (Ville) drop superfluous dp_get_m_n from get_config (Ville) Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 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>
-
由 Jani Nikula 提交于
Since commit ee1452d7 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 20 15:05:30 2013 +0300 drm/i915: assume all GM45 Acer laptops use inverted backlight PWM failed and was later reverted in commit be505f64 Author: Alexander van Heukelum <heukelum@fastmail.fm> Date: Sat Dec 28 21:00:39 2013 +0100 Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM" fix the individual broken machine instead. Note to backporters: http://patchwork.freedesktop.org/patch/17837/ is the patch you want for 3.13 and older. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54171 Reference: http://mid.gmane.org/DUB115-W7628C7C710EA51AA110CD4A5000@phx.gbl CC: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> [danvet: Patch mangling for 3.14 plus adding the link to the original for 3.13.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
It's unused, and nowadays specifying unknown parameters no longer prevents modules from being loaded. Signed-off-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>
-
由 Ville Syrjälä 提交于
Group the sprite register writes a bit tighter. We want to write the registers atomically, and so doing the base address/offset artihmetic within the critical section is pointless when it can all be done beforehand. Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Currently we're doing the reset handling a bit late, and we're doing it both in the driver load code and on resume. This makes it unusable for e.g. resetting the panel power sequence state like Paulo wants to. Instead of adding yet another single-use callback shuffle things around: - Output handling code is responsible to reset/init all state on its own at driver load time. - We call the reset functions much earlier, before we start using any of the modeset code. Compared to Paulo's new ->resume callback the only difference in placement is that ->reset is still called without dev->struct_mutex held. Which is imo a feature. v2: Rebase on top of the now merge dinq. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.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>
-
由 Ville Syrjälä 提交于
I forgot to set new_config and new_enabled appropriately in the load detect code. Fix it up. v2: Handle the other error path in intel_get_load_detect_pipe() too (Imre) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Not sure anyone cares about this information. I suppose most people would just look at /proc/interrupts instead. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
irq_received is used as a boolean in i965_irq_handler(), so make it bool. This also makes i965_irq_handler() closer to i915_irq_handler(). Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewd-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Add intel_hpd_irq_uninstall() which will cancel the hotplug re-enable timer. Also s/i915_reenable_hotplug_timer_func/intel_hpd_irq_reenable/ Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> 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>
-