summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-01-08drm/radeon: Avoid the locking overhead in object lookups for relocs.exec-lockingEric Anholt1-3/+5
Signed-off-by: Eric Anholt <eric@anholt.net>
2013-01-08drm/i915: Use an ida instead of an idr, and maintain our own pointer table.Eric Anholt3-67/+84
The multi-layer nature of the idr is too expensive for our purposes, so just use the ida code for number allocation (should be faster than walking our array, since it's a bitmask) Signed-off-by: Eric Anholt <eric@anholt.net>
2013-01-08drm/i915: Remove the temporary eb hash table.Eric Anholt1-56/+1
This was used to work around the overhead of locking file->table_lock, but now that that's a mutex we don't need to bother any more. Signed-off-by: Eric Anholt <eric@anholt.net>
2013-01-08drm/i915: Look up objects for relocations using the idr.Eric Anholt1-28/+13
We know those cachelines are hot because we just looked at them when looking up the whole object list. Signed-off-by: Eric Anholt <eric@anholt.net>
2013-01-08drm/i915: Hold the table lock across all our object lookups in execbuf.Eric Anholt1-4/+6
Signed-off-by: Eric Anholt <eric@anholt.net>
2013-01-08drm: Expose a variant of drm_gem_object_lookup where the lock is held.Eric Anholt2-4/+15
Signed-off-by: Eric Anholt <eric@anholt.net>
2013-01-08drm: Convert the lock protecting object handles to a mutex.Eric Anholt2-10/+10
In execbuf, we want to be able to do many lookups of handles without having to take and drop a lock every time. Convert it to a mutex so that we'll be able to hold the lock across all our lookups. Signed-off-by: Eric Anholt <eric@anholt.net>
2012-12-20drm/i915: Return the real error code from intel_set_mode()Chris Wilson7-49/+39
Note: This patch also adds a little helper intel_crtc_restore_mode for the common case where we do a full modeset but with the same parameters, e.g. to undo bios damage or update a property. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Added note.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-20drm/i915: Make GSM voidBen Widawsky2-3/+4
The iomapping of the register region has historically been a uint32_t for the obvious reason that our PTE size was always 4b. In the future however, we cannot make this assumption. By making the type void, it makes the upcoming pointer math we will do much easier, and hopefully gives the compiler opportunities to warn us when we do stupid things. v2: Cast to __iomem, caught by Ville Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fixup __iomem issue for real.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-20drm/i915: Move GSM mapping into dev_privBen Widawsky4-10/+10
This removes an unused field from the AGP structure and moves it into the dev_priv structure (with a slightly better name). This builds upon the kill-agp series already merged. GSM is a well defined term in the bspec: GSM: Graphics Stolen Memory GTT stolen space is defined for storage of the GFX GTT entries in physical memory. IA can not access GSM directly , it can only access via GTTMMADR. GT can access GSM directly or through GTTMMADR. This is not the entire stolen space. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-20drm/i915: Move even more gtt code to i915_gem_gttBen Widawsky3-56/+61
This really should have been part of the kill agp series. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-19drm/i915: Make next_seqno debugs entry to use i915_gem_set_seqnoMika Kuoppala1-10/+1
This debugs entry can be used to set arbitrary value to next_seqno. Use i915_gem_set_seqno instead of poking next_seqno. v2: nasty details of next_seqno and last_seqno handling moved inside i915_gem_set_seqno as suggested by Chris Wilson. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-19drm/i915: Introduce i915_gem_set_seqno()Mika Kuoppala2-5/+31
This function can be used to set the driver's next_seqno to arbitrary value. i915_gem_set_seqno() will idle the gpu, retire outstanding requests, clear the semaphore mailboxes and set the hardware status page's seqno index. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-19drm/i915: Always clear semaphore mboxes on seqno wrapMika Kuoppala1-12/+0
In preparation for setting the seqno to arbitrary value on init or through debugfs. We need to always clear the semaphores and set the hws page seqno index by calling intel_ring_init_seqno(). v2: rewrote the commit message as suggested by Chris Wilson. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-19drm/i915: Initialize hardware semaphore state on ring initMika Kuoppala3-21/+13
Hardware status page needs to have proper seqno set as our initial seqno can be arbitrary. If initial seqno is close to wrap boundary on init and i915_seqno_passed() (31bit space) refers to hw status page which contains zero, errorneous result will be returned. v2: clear mboxes and set hws page directly instead of going through rings. Suggested by Chris Wilson. v3: hws needs to be updated for all gens. Noticed by Chris Wilson. References: https://bugs.freedesktop.org/show_bug.cgi?id=58230 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-19drm/i915: Introduce ring set_seqnoMika Kuoppala2-0/+29
In preparation for setting per ring initial seqno values add ring::set_seqno(). Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-18drm/i915: Missed conversion to gtt_pte_tBen Widawsky1-2/+2
commit f61c0609073133375ace61f74b0e4e7cf631406b Author: Ben Widawsky <ben@bwidawsk.net> Date: Mon Oct 22 11:44:43 2012 -0700 drm/i915: introduce gtt_pte_t Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-18drm/i915: Bug on unsupported swizzled platformsBen Widawsky1-1/+3
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-18drm/i915: BUG() if fences are used on unsupported platformBen Widawsky2-1/+3
Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-18drm/i915: fixup overlay stolen memory leakDaniel Vetter3-3/+5
We need to clean up the overlay first, before taking down the stolen memory allocator. This regression has been introducec in commit 8040513870399f1cb032cb8bc805df5042fedcdf Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 15 11:32:29 2012 +0000 drm/i915: Allocate overlay registers from stolen memory v2: Rework the patch a bit as suggested by Chris Wilson: - move the overlay teardown up, into the modeset cleanup - move the stolen mm takedown into i915_gem_cleanup_stolen Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-17drm/i915: clean up PIPECONF bpc #definesDaniel Vetter2-24/+19
Ilk+ somehow used #defines in near the PIPESTAT definitions, which decently confused me. Earlier platforms called it BPP instead of BPC. Clean this all up. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-17drm/i915: add intel_dp_set_signal_levelsPaulo Zanoni1-36/+33
So we can de-duplicate code that's inside intel_dp_start_link_train and intel_dp_complete_link_train. V2: Rebase since patch 3/5 was discarded. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-17drm/i915: remove leftover display.update_wm assignmentPaulo Zanoni1-2/+1
This was moved to intel_init_pm. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-17drm/i915: check for the PCH when setting pch_transcoderPaulo Zanoni1-1/+1
Don't check the CPU, it doesn't have any PCH transcoder. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-17drm/i915: Clear the stolen fb before enablingChris Wilson1-0/+7
As the stolen memory region will contain the contents of whatever was last there, it invariably contains garbage. To be consistent with the shmemfs backed fb and the expectations of the fb layer, we need to clear the fb prior to installing it as an fbcon. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58111 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup sparse __iomem confusion reported by Wu Fengguang.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-17drm/i915: Access to snooped system memory through the GTT is incoherentChris Wilson1-0/+6
We ignore all the user requests to handle flushing to the GTT domain if the user requests such on a snoopable bo, and as such access through the GTT to such pages remains incoherent. The specs even warn that such behaviour is undefined - a strong reason never to do so. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-14drm/i915: Remove stale comment about intel_dp_detect()Damien Lespiau1-7/+0
The function doesn't use any of the registers mentioned, nor does it return true or false. Hard to do worse. Remove it, the function is absolutely descriptive enough to not need any comment. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-14drm/i915: Implement ibx_digital_port_connected() for IBXDamien Lespiau1-16/+28
CPT+ PCHs have different bit definition to read the HPD live status. I don't have an ILK with digital ports handy, which is why this patch is separate from the CPT+ implementation. If the docs don't lie, it should all be fine though. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-14drm/i915/dp: Log the DPCD only if we have successfully retrieved oneDamien Lespiau1-5/+6
Moving the DPCD just after a successful read will allow to: - log all DPCD reads (eDP ones, changes signalled by HPD IRQ) - don't log it if we haven't been able to read it v2: Be sure to log the DPCD when a downstream port does not have HPD support and the branch device asserts HPD (Jani Nikula) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-14drm/i915/dp: Read the HPD status before trying to read the DPCDDamien Lespiau1-0/+5
Just like: Author: Damien Lespiau <damien.lespiau@intel.com> Date: Wed Dec 12 19:37:22 2012 +0000 drm/i915/hdmi: Read the HPD status before trying to read the EDID But this time for DiplayPort. v2: Adapt to the ibx_ name change and don't add commit hash (Chris Wilson, Jani Nikula) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-14drm/i915/hdmi: Read the HPD status before trying to read the EDIDDamien Lespiau3-2/+43
If you unplug the hdmi connector slowly enough, the hotplug interrupt fires but then the kernel code tries to read the EDID and succeeds (because the connector is still half connected, the HPD pin is shorter than the others, and DDC works). Since EDID succeeds it thinks the monitor is still connected. To prevent that, read the live HPD status in the hotplug handler before trying to read the EDID. v2: Rename the function to ibx_ (Chris Wilson) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55372 Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-14drm/i915: Cleanup SHOTPLUG_CTL status bits definitionsDamien Lespiau1-9/+12
Those status bits don't follow the usual pattern: _MASK (those bits are write 1 to clear, useful to select the value we want to read) and the values shifted by the same amount. Cleaned that that up when poking at the register for testing purposes, might as well upstream that cleanup. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-12drm/i915: rework locking for intel_dpio|sbi_read|writeDaniel Vetter4-36/+25
Spinning for up to 200 us with interrupts locked out is not good. So let's just spin (and even that seems to be excessive). And we don't call these functions from interrupt context, so this is not required. Besides that doing anything in interrupt contexts which might take a few hundred us is a no-go. So just convert the entire thing to a mutex. Also move the mutex-grabbing out of the read/write functions (add a WARN_ON(!is_locked)) instead) since all callers are nicely grouped together. Finally the real motivation for this change: Dont grab the modeset mutex in the dpio debugfs file, we don't need that consistency. And correctness of the dpio interface is ensured with the dpio_lock. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-11drm/i915: Fixup hpd irq register setup orderingDaniel Vetter6-14/+79
For GMCH platforms we set up the hpd irq registers in the irq postinstall hook. But since we only enable the irq sources we actually need in PORT_HOTPLUG_EN/STATUS, taking dev_priv->hotplug_supported_mask into account, no hpd interrupt sources is enabled since commit 52d7ecedac3f96fb562cb482c139015372728638 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 1 21:03:22 2012 +0100 drm/i915: reorder setup sequence to have irqs for output setup Wrongly set-up interrupts also lead to broken hw-based load-detection on at least GM45, resulting in ghost VGA/TV-out outputs. To fix this, delay the hotplug register setup until after all outputs are set up, by moving it into a new dev_priv->display.hpd_irq_callback. We might also move the PCH_SPLIT platforms to such a setup eventually. Another funny part is that we need to delay the fbdev initial config probing until after the hpd regs are setup, for otherwise it'll detect ghost outputs. But we can only enable the hpd interrupt handling itself (and the output polling) _after_ that initial scan, due to massive locking brain-damage in the fbdev setup code. Add a big comment to explain this cute little dragon lair. v2: Encapsulate all the fbdev handling by wrapping the move call into intel_fbdev_initial_config in intel_fb.c. Requested by Chris Wilson. v3: Applied bikeshed from Jesse Barnes. v4: Imre Deak noticed that we also need to call intel_hpd_init after the drm_irqinstall calls in the gpu reset and resume paths - otherwise hotplug will be broken. Also improve the comment a bit about why hpd_init needs to be called before we set up the initial fbdev config. Bugzilla: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54943 Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-11drm/i915: Set initial seqno value close to wrap boundaryMika Kuoppala1-1/+1
To gain confidence in the wrap handling, make it happen quite soon after the boot. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-11drm/i915: Open-code i915_gpu_idle() for handling seqno wrappingChris Wilson1-4/+8
The complication is that during seqno wrapping we must be extremely careful not to write to any ring as that will require a new seqno, and so would recurse back into the seqno wrap handler. So we cannot call i915_gpu_idle() as that does additional work beyond simply retiring the current set of requests, and instead must do the minimal work ourselves during seqno wrapping. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-11drm/i915: Don't emit semaphore wait if wrap happenedMika Kuoppala3-7/+23
If wrap just happened we need to prevent emitting waits for pre wrap values. Detect this and emit no-ops instead. v2: Use olr > seqno to detect wrap instead of *seqno == 0 as suggested by Chris Wilson. v3: Use last used seqno to detect the wraparound. From Chris Wilson v4: Fixed unnecessary last_seqno assigment References: https://bugs.freedesktop.org/show_bug.cgi?id=57967 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-10i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointersTim Gardner1-6/+16
smatch warning: drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts 500 bytes on stack Refactor so that saved_mode and saved_hwmode are dynamically allocated as opposed to being automatic variables. 500 bytes seems like it could run the potential for blowing the kernel stack. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-10drm/i915: Remove duplicate inclusion of drm/drm_edid.hSachin Kamat1-1/+0
drm/drm_edid.h was included twice. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-08drm/i915: don't prevent CPU idle statesTomas Janousek1-1/+1
Commit 9ee32fea5f unconditionally prevents the CPU from entering idle states until intel_dp_aux_ch completes for the first time, which never happens on my DisplayPort-less intel gfx, causing the CPU to get rather hot. Signed-off-by: Tomas Janousek <tomi@nomi.cz> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-07drm/i915: Reduce memory pressure during shrinker by preallocating swizzle pagesChris Wilson3-8/+22
On a machine with bit17 swizzling, we need to store the bit17 of the physical page address in put-pages. This requires a memory allocation, on average less than a page, which may be difficult to satisfy is the request to put-pages is on behalf of the shrinker. We could allow that allocation to pull from the reserved memory pools, but it seems much safer to preallocate the array for tiled objects on affected machines. v2: Export i915_gem_object_needs_bit17_swizzle() for reuse. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: extract common link_m_n helpersDaniel Vetter3-57/+26
Both the dp and fdi code use the exact same computations (ignore minor differences in conversion between bits and bytes). This makes it even more apparent that we have a _massive_ mess between cpu transcoder/fdi link/pch transcoder and pch link settings. And also that we have hilarious amounts of confusion between edp and dp (despite that they're identical at a link level). Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: drop unnecessary clearing of pch dp transcoder timingsDaniel Vetter1-8/+1
This has originally been added in commit 8db9d77b1b14fd730561f64beea8c00e4478d7c5 Author: Zhenyu Wang <zhenyuw@linux.intel.com> Date: Wed Apr 7 16:15:54 2010 +0800 drm/i915: Support for Cougarpoint PCH display pipeline probably to combat issues with hw state left behind by the BIOS. And indeed, I've checked out that specific revision, and there is no DP support yet. So the pch dp transcoder won't be correctly disabled, and that's important since it requires a rether special disable dance: Just writing 0 to TRANS_DP_CTL won't cut it, since we need to select the NONE port when disabling, too. And indeed, things seem to still work, so let's just remove this. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: WARN on !crtc in intel_dp_link_downDaniel Vetter1-9/+4
This could have happened with the old crtc helper based modeset code, but can't happen any longer with the new code. Hence put in a WARN and adjust the comment. If no one hits this, we can eventually remove it (like a few other such cases across our code). Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: use wait_for_vblank instead of msleep(17)Daniel Vetter1-2/+5
17 ms is eerily close to 60 Hz ^-1 Unfortunately this goes back to the original DP enabling for ilk, and unfortunately does not come with a reason for it's existance attached. Some closer inspection of the code and DP specs shows that we set the idle link pattern before we disable the port. And it seems like that the DP spec (or at least our hw) only switch to the idle pattern on the next vblank. Hence a vblank wait at this spot makes _much_ more sense than a really long wait. v2: Rebase fixup. v3: Add comment requested by Paulo Zanoni saying that we don't really know what this wait is for. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: rip out pre-production ilk cpu edp w/aDaniel Vetter1-16/+5
While reading docs I've noticed that this special workaround to select the 1.6 GHz DP clock only applies to pre-production ilk machines. Since the registers we're touching here are rather undocumented and might be harmful on later chips, rip it out. For the Bspec reference of this w/a look in "vol4g CPU Display Registers [DevILK]", Section 4.1.7.1 "DP_A—DisplayPort A Control Register", "DP_PLL_Frequency_Select". v2: Keep a debug message as a hint in case something regresses. Requested by Chris Wilson. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: move set_pll_edp to intel_dp.cDaniel Vetter2-40/+40
Now that we enable the cpu edp pll in intel_dp->pre_enable and no longer in crtc_mode_set, we can also move the modeset part to the intel_dp->mode_set callback. Previously this was not possible because the encoder ->mode_set callbacks are called after the crtc mode set callback. v2: Rebase on top of copy&pasted hsw crtc_mode_set. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: rip out pre-DDI stuff from haswell_crtc_mode_setDaniel Vetter1-126/+2
Especially getting rid of all things lvds is ... great! v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni. v3: - handle DP ports correctly (spoted by Paulo) - don't leave {} behind for a single-line block (again spotted by Paulo) - kill another if (IBX || CPT) block Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: be less verbose when handling gmbus/aux irqsPaulo Zanoni1-4/+0
Having 9500 lines repeated on dmesg does not help me at all. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-06drm/i915: Remove duplicate and unused register #defines in i915_reg.hDexuan Cui1-4/+0
TRANS_DP_VIDEO_AUDIO is not used at all. The other 3 has duplicated #defines. Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2024-05-15 11:12:42 +0000