- 17 Dec, 2012 6 commits
-
-
Daniel Vetter authored
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>
-
Paulo Zanoni authored
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:
-
Paulo Zanoni authored
This was moved to intel_init_pm. Signed-off-by:
-
Paulo Zanoni authored
Don't check the CPU, it doesn't have any PCH transcoder. Signed-off-by:
-
Chris Wilson authored
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=58111Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup sparse __iomem confusion reported by Wu Fengguang.] Signed-off-by:
-
Chris Wilson authored
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:
-
- 14 Dec, 2012 6 commits
-
-
Damien Lespiau authored
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:
-
Damien Lespiau authored
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 authored
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 authored
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: -
Damien Lespiau authored
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=55372Signed-off-by:
-
Damien Lespiau authored
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:
-
- 12 Dec, 2012 1 commit
-
-
Daniel Vetter authored
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:
-
- 11 Dec, 2012 4 commits
-
-
Daniel Vetter authored
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 52d7eced 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=54943Reported-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Mika Kuoppala authored
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:
-
Chris Wilson authored
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:
-
Mika Kuoppala authored
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=57967Signed-off-by:
-
- 10 Dec, 2012 2 commits
-
-
Tim Gardner authored
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:
-
Sachin Kamat authored
drm/drm_edid.h was included twice. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Reviewed-by:
-
- 08 Dec, 2012 1 commit
-
-
Tomas Janousek authored
Commit 9ee32fea 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:
-
- 07 Dec, 2012 1 commit
-
-
Chris Wilson authored
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:
-
- 06 Dec, 2012 19 commits
-
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
This has originally been added in commit 8db9d77b 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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
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 authored
Having 9500 lines repeated on dmesg does not help me at all. Signed-off-by:
-
Dexuan Cui authored
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:
-
Daniel Vetter authored
Less clutter in the traces. And in both cases we yell rather loud into the logs if we time out. Patch suggested by Chris Wilson. v2: Annotate another I915_READ in dp_aux to be consistent - we filter out all register io in wait_for and similar loops. Chris also suggested to mark all dp_aux register access as _NOTRACE, but I think we should keep all functionally relevant access around, and filter unneeded bits in userspace after the trace is captured. Reviewed-by:
-
Daniel Vetter authored
At least on the platforms that have a dp aux irq and also have it enabled - vlvhsw should have one, too. But I don't have a machine to test this on. Judging from docs there's no dp aux interrupt for gm45. Also, I only have an ivb cpu edp machine, so the dp aux A code for snb/ilk is untested. For dpcd probing when nothing is connected it slashes about 5ms of cpu time (cpu time is now negligible), which agrees with 3 * 5 400 usec timeouts. A previous version of this patch increases the time required to go through the dp_detect cycle (which includes reading the edid) from around 33 ms to around 40 ms. Experiments indicated that this is purely due to the irq latency - the hw doesn't allow us to queue up dp aux transactions and hence irq latency directly affects throughput. gmbus is much better, there we have a 8 byte buffer, and we get the irq once another 4 bytes can be queued up. But by using the pm_qos interface to request the lowest possible cpu wake-up latency this slowdown completely disappeared. Since all our output detection logic is single-threaded with the mode_config mutex right now anyway, I've decide not ot play fancy and to just reuse the gmbus wait queue. But this would definitely prep the way to run dp detection on different ports in parallel v2: Add a timeout for dp aux transfers when using interrupts - the hw _does_ prevent this with the hw-based 400 usec timeout, but if the irq somehow doesn't arrive we're screwed. Lesson learned while developing this ;-) v3: While at it also convert the busy-loop to wait_for_atomic, so that we don't run the risk of an infinite loop any more. v4: Ensure we have the smallest possible irq latency by using the pm_qos interface. v5: Add a comment to the code to explain why we frob pm_qos. Suggested by Chris Wilson. v6: Disable dp irq for vlv, that's easier than trying to get at docs and hw. v7: Squash in a fix for Haswell that Paulo Zanoni tracked down - the dp aux registers aren't at a fixed offset any more, but can be on the PCH while the DP port is on the cpu die. Reviewed-by: Imre Deak <imre.deak@intel.com> (v6) Signed-off-by: -
Daniel Vetter authored
Doesn't do anything yet than call dp_aux_irq_handler. Reviewed-by:
-
Daniel Vetter authored
GMBUS_ACTIVE has inverted sense and so doesn't fit into the wait_hw_status helper, hence create a new gmbus_wait_idle functions. Also, we only care about the idle irq event and nothing else, which allows us to use the wait_event_timeout helper directly without jumping through hoops to catch NAKs. Since gen2/3 don't have gmbus interrupts, handle them separately with the old wait_for macro. This shaves another few ms off reading EDID from a hdmi screen on my testbox here. EDID reading with interrupt driven gmbus is now as fast as with busy-looping gmbus at 28 ms here (with negligible cpu overhead). Reviewed-by:
-
Daniel Vetter authored
We need two special things to properly wire this up: - Add another argument to gmbus_wait_hw_status to pass in the correct interrupt bit in gmbus4. - Since we can only get an irq for one of the two events we want, hand-roll the wait_event_timeout code so that we wake up every jiffie and can check for NAKs. This way we also subsume gmbus support for platforms without interrupts (or where those are not yet enabled). The important bit really is to only enable one gmbus interrupt source at the same time - with that piece of lore figured out, this seems to work flawlessly. Ben Widawsky rightfully complained the lack of measurements for the claimed benefits (especially since the first version was actually broken and fell back to bit-banging). Previously reading the 256 byte hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms. Given that transfering the 256 bytes over i2c at wire speed takes 20.5ms alone, the reduction in additional overhead is rather nice. v2: Chris Wilson wondered whether GMBUS4 might contain some set bits when booting up an hence result in some spurious interrupts. Since we clear GMBUS4 after every wait and we do gmbus transfer really early in the setup sequence to detect displays the window is small, but still be paranoid and clear it properly. v3: Clarify the comment that gmbus irq generation can only support one kind of event, why it bothers us and how we work around that limit. Cc: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by:
-
Daniel Vetter authored
Only enables the interrupt and puts a irq handler into place, doesn't do anything yet. Unfortunately there's no gmbus interrupt support for gen2/3 (safe for pnv, but there the irq is marked as "Test mode"). v2: Wire up the irq handler for vlv and gen4 properly. v3: i915_enable_pipestat expects the mask bit, not the status bits ... and for added hilarity those are rather inconsistently named. Reviewed-by:
-
Daniel Vetter authored
The gmbus interrupt generation is rather fiddly: We can only ever enable one interrupt source (but we always want to check for NAK in addition to the real bit). And the bits in the gmbus status register don't map at all to the bis in the irq register. To prepare for this mess, start by extracting the hw status wait loop into it's own function, consolidate the NAK error handling a bit. To keep things flexible, pass in the status bit we care about (in addition to any NAK signalling). v2: I've failed to notice that the sense of GMBUS_ACTIVE is inverted, Chris Wilson gladly pointed that out for me. To keep things simple, ignore that case for now (we only need to idle the gmbus controller at the end of an entire i2c transaction, not after every message). Reviewed-by:
-
Daniel Vetter authored
Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that well. Noticed since the dp aux code doesn't have an automatic fallback with a timeout (since the hw provides for that already). v2: Simple move drm_irq_install before intel_modeset_gem_init, as suggested by Ben Widawsky. v3: Now that interrupts are enabled before all connectors are fully set up, we might fall over serving a HPD interrupt while things are still being set up. Instead of jumping through massive hoops and complicating the code with a separate hpd irq enable step, simply block out the hotplug work item from doing anything until things are in place. v4: Actually, we can enable hotplug processing only after the fbdev is fully set up, since we call down into the fbdev from the hotplug work functions. So stick the hpd enabling right next to the poll helper initialization. v5: We need to enable irqs before intel_modeset_init, since that function sets up the outputs. v6: Fixup cleanup sequence, too. Reviewed-by:
-
Daniel Vetter authored
... together with all the other irq related resources in intel_irq_init. I've managed to oops in the notify_ring function on my ilk, presumably because of the powerctx setup call to i915_gpu_idle. Note that this is only a problem with the reorder irq setup sequence for irq-driver gmbus/dp aux. Reviewed-by:
-
Daniel Vetter authored
This is for legacy legacy stuff, and checking with the leftover pipe from the previous loop is propably not what we want. Since pipe == 2 after the loop ... Then we only assing a variable and do nothing with it. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
