- 13 Jun, 2013 1 commit
-
-
Ville Syrjälä authored
The specs are a bit unclear whether the per-plane trickle feed disable control exists on VLV. There is another trickle feed disable control in the MI_ARB register. After some experimentation it turns out both the DSPCNTR trickle feed bits and the MI_ARB bit can be toggled. However the DSPCNTR bits don't seem to have any effect. The MI_ARB bit, on the other hand, has a noticable effect. I performed an experiment where I reduced the FIFO size via DSPARB and observed the effect of the MI_ARB trickle feed bit on the display. Using a 1920x1080-60 mode, with MI_ARB=0x4 the display started to have problems with DSPARB=0x42424242, whereas with MI_ARB=0x0 the problems didn't start until DSPARB=0x09090909. This seems to confirm that the MI_ARB trickle feed bit actually does work. So replace the use of the DSPCNTR trickle feed bits with MI_ARB on VLV. v2: Amend commit message with results from experimentation Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 Jun, 2013 9 commits
-
-
Daniel Vetter authored
We have a nice comment saying that the pixel multiplier only sticks once the vco is on and stable. The only problem is that the enable bit wasn't set at all. This patch fixes this and so brings the ilk+ pch pll code in line with the i8xx/i9xx pll code. Or at least improves matters a lot. This should fix sdvo on ilk-ivb for low-res modes. Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
Just the plumbing, all the modeset and enable code has not yet been switched over to use the new state. It seems to be decently broken anyway, at least wrt to handling of the special pixel mutliplier enabling sequence. Follow-up patches will clean up that mess. Another missing piece is more careful handling (and fixup) of the fp1 alternate divisor state. The BIOS most likely doesn't bother to program that one to what we expect. So we need to be more careful with comparing that state, both for cross checking but also when checking for dpll sharing when acquiring shared dpll. Otherwise fastboot will deny a few shared dpll configurations which would otherwise work. v2: We need to memcpy the pipe config dpll hw state into the pll, for otherwise the cross-check code will get angry. v3: Don't forget to read the pch pll state in the crtc get_pipe_config function for ibx/ilk platforms. Reviewed-by:
-
Daniel Vetter authored
Now that we have proper hw state reconstruction we should never have a case where we don't have the software dpll state properly set up. So add WARNs to the respective !pll cases in enable/disabel_shared_dpll. Reviewed-by:
-
Daniel Vetter authored
Simply grew too large and needed to be split up into parts. Reviewed-by:
-
Daniel Vetter authored
Simply grew too big. This also makes the fixup and restore logic in setup_hw_state stand out a bit more clearly. Reviewed-by:
-
Daniel Vetter authored
Currently still with an empty register state, this will follow in a next step. This one here just creates the new vfunc and uses it for cross-checking, initial state takeover and the dpll assert function. And add a FIXME for the ddi pll readout code, which still needs to be converted over. v2: - Add some hw state readout debug output. - Also cross check the enabled crtc counting. Note that I've botched up the patch ordering, and before this patch we've read out the pll selection correctly, but did not reconstruct the refcounts properly. See the bug link. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65673Reviewed-by:
-
Daniel Vetter authored
So don't try to store it in the DPLL_FP register. Otherwise it looks like the limits for pineview are correct: It has it's own clock computation code, which doesn't use an offset for n divisors, and the register value based m limits look sane enough. v2: Rebase on top of the pineview clock refactor and fixup up the commit message: It's m1 pnv doens't care about, not m2! Quoting Damien's review: - "n can vary between 2 and 6, but we declare the 3-6 as limits. - "p1 seems to be able to go up to 9 - "the m upper limit seems a bit big, but the docs are a bit shy on that values for pnv. "Otherwise, the change itself seems good:" Reviewed-by: -
Daniel Vetter authored
We don't (yet) have proper pixel multiplier readout support on pch split platforms, so the cross check will naturally fail. v2: Fix spelling in the comment, spotted by Ville. v3: Since the ordering constraint is pretty tricky between the crtc get_pipe_config callback and the encoder->get_config callback add a few comments about it. Prompted by a discussion with Chris Wilson on irc about why this does work anywhere else than on i915g/gm. Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
Chris Wilson authored
Stéphane Marchesin found a bug where the fences were not being restored, and in particular the fence pin_count was incorrect. Had we had a warning in place, this bug would have come to light much earlier. Better late than never? Signed-off-by:
-
- 11 Jun, 2013 4 commits
-
-
Chris Wilson authored
This is of no value to the developer reading the report, let alone the bamboozled user. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
If we detect a ring is in a valid wait for another, just let it be. Eventually it will either begin to progress again, or the entire system will come grinding to a halt and then hangcheck will fire as soon as the deadlock is detected. This error was foretold by Ben in commit 05407ff8 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu May 30 09:04:29 2013 +0300 drm/i915: detect hang using per ring hangcheck_score "If ring B is waiting on ring A via semaphore, and ring A is making progress, albeit slowly - the hangcheck will fire. The check will determine that A is moving, however ring B will appear hung because the ACTHD doesn't move. I honestly can't say if that's actually a realistic problem to hit it probably implies the timeout value is too low." v2: Make sure we don't even incur the KICK cost whilst waiting. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65394Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Chris Wilson authored
After kicking a ring, it should be free to make progress again and so should not be accused of being stuck until hangcheck fires once more. In order to catch a denial-of-service within a batch or across multiple batches, we still do increment the hangcheck score - just not as severely so that it takes multiple kicks to fail. This should address part of Ben's justified criticism of commit 05407ff8 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu May 30 09:04:29 2013 +0300 drm/i915: detect hang using per ring hangcheck_score "There's also another corner case on the kick. If the seqno = 2 (though not stuck), and on the 3rd hangcheck, the ring is stuck, and we try to kick it... we don't actually try to find out if the kick helped." v2: Make sure we catch DoS attempts with batches full of invalid WAITs. v3: Preserve the ability to detect loops by always charging the ring if it is busy on the same request. v4: Make sure we queue another check if on a new batch References: https://bugs.freedesktop.org/show_bug.cgi?id=65394Signed-off-by:
-
Chris Wilson authored
When we reset and restart a ring, we also want to clear any existing hangcheck. Signed-off-by:
-
- 10 Jun, 2013 17 commits
-
-
Damien Lespiau authored
In case of intel_sdvo_get_active_outputs() failing, we end up reading a value from the stack. Signed-off-by:
-
Damien Lespiau authored
It's now intel_sdvo_get_capabilities(). Signed-off-by:
-
Daniel Vetter authored
The hw state readout code for the pipe config will now check this for us, so rip out this hand-rolled complexity. Reviewed-by:
-
Daniel Vetter authored
Looks at first like a bit of overkill, but - Haswell actually wants different enable/disable functions for different plls. - And once we have full dpll hw state tracking we can move the full register setup into the ->enable hook. Reviewed-by:
-
Daniel Vetter authored
Using ids in register macros is much more common in our driver. Also this way we can reduce the platform specific stuff a bit. Reviewed-by:
-
Daniel Vetter authored
An id to match the idx (useful for register access macros) and a name fore neater debug output. Reviewed-by:
-
Daniel Vetter authored
In the future this won't be just for pch plls, so move it into the shared dpll init code. v2: Bikeshed the uncessary {} away while applying to appease checkpatch. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: -
Daniel Vetter authored
Well, the first step of a long road at least, it only reads out the pipe -> shared dpll association thus far. Other state which needs to follow: - hw state of the dpll (on/off + dpll registers). Currently we just read that out from the hw state, but that doesn't work too well when the dpll is in use, but not yet fully enabled. We get away since most likely it already has been enabled and so the correct state is left behind in the registers. But that doesn't hold for atomic modesets when we want to enable all pipes at once. - Refcount reconstruction for each dpll. - Cross-checking of all the above. For that we need to keep the dpll register state both in the pipe and in the shared_dpll struct, so that we can check that every pipe is still connected to a correctly configured dpll. Note that since the refcount resconstruction isn't done yet this will spill a few WARNs at boot-up while trying to disable pch plls which have bogus refcounts. But since there's still a pile of refactoring to do I'd like to lock down the state handling as soon as possible hence decided against reordering the patches to quiet these WARNs - after all the issues they're complaining about have existed since forever, as Jesse can testify by having pch pll states blow up consistently in his fastboot patches ... v2: We need to preserve the old shared_dpll since currently the shared dpll refcount dropping/getting is done in ->mode_set. With the usual pipe_config infrastructure the old dpll id is already lost at that point, hence preserve it in the new config. v3: Rebase on top of the ips patch from Paulo. v4: We need to unconditionally take over the shared_dpll id from the old pipe config when e.g. doing a direct pch port -> cpu edp transition. v5: Move the saving of the old shared_dpll id to an ealier patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
The bits are evenly space, so we can cut down on two big switch blocks. This also greatly simplifies the hw state readout which follows in the next patch. Reviewed-by:
-
Daniel Vetter authored
With the big sed-job prep work done this is now really simple. With the exception that we only assign the right shared dpll id in the ->mode_set callback but also depend upon the old one still being around. Until that mess is fixed up we need to jump through a few hoops to keep the old value save. v2: Kill the funny whitespace spotted by Chris. v3: Move the shared_dpll pipe config fixup into this patch as noticed by Ville. Also unconditionally set the shared_dpll with the current one, since otherwise we won't handle direct pch port -> cpu edp transitions correctly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Dealing with discrete enum values is simpler for hw state readout and pipe config computations than pointers - having neat names instead of chasing pointers should look better in the code. This isn't a that good reason for pch plls, but on haswell we actually have 3 different types of plls: WRPLL, SPLL and the DP clocks. Having explicit names should help there. Since this also adds the intel_crtc_to_shared_dpll helper to further abstract away the crtc -> dpll relationship this will also help to make the next patch simpler, which moves the shared dpll into the pipe configuration. Also note that for uniformity we have two special dpll ids: NONE for pipes which need a shared pll but don't have one (yet) and private for when there's a non-shared pll (e.g. per-pipe or per-port pll). I've thought whether we should also add a 2nd enum for the type of the pll we want (for really generic pll selection code) but thrown that idea out again - likely there's too much platform craziness going on to be able to share the pll selection logic much. Since this touched all the shared_pll functions a bit I've also done an s/intel_crtc/crtc/ replacement on a few of them. v2: Kill DPLL_ID_NONE. It's probably better to call it DPLL_ID_INVALID and use it to check that the compute config stage assigns a dpll to every pipe. But since that code isn't ready yet until we move the dpll selection out of the ->mode_set callback, there's no use for it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
For fastboot we need some support to read out the sharing state of plls, at least for platforms where they can be shared (or freely assigned at least). Now for ivb we already have pretty extensive infrastructure for tracking pch plls, and it took us an aweful lot of tries to get that remotely right. Note that hsw could also share plls, but even now they're already freely assignable. So we need this on more than just ivb. So on top of the usual fastboot fun pll sharing seems to be an additional step up in fragility. Hence a common infrastructure for all shared/freely assignable display plls seems to be in order. The plan is to have a bit of dpll hw state readout code, which can be used individually, but also to fill in the pipe config. The hw state cross check code will then use that information to make sure that after every modeset every pipe still is connected to a pll which still has the correct configuration - a lot of the pch pll sharing bugs where due to incorrect sharing. We start this endeavour with a simple s/pch_pll/shared_dpll/ rename job. Reviewed-by:
-
Daniel Vetter authored
Before I start to make a complete mess out of this, crank up the paranoia level a bit. v2: Kill the has_pch_encoder check in put_shared_dpll - it's invalid as spotted by Ville since we currently only put the dpll when we already have the new pipe config. So a direct pch port -> cpu edp transition will hit this. v3: Now that I've lifted my blinders add the WARN_ON Ville requested. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Simlar to how disable already works on haswell. This is possible since we now carefully track the pch state in the pipe config. Reviewed-by:
-
Daniel Vetter authored
We ->mode_set is called we can't just blindly reuse an existing pll since that might be shared with a different, still active pch output. v2: Only update the pll settings when the pch pll is know to be unused, otherwise we can wreak havoc with a running pipe. Which in the case of DP will likely result in a black screen due to loss of link lock. v3: Tighten up the asserts a bit more, especially make sure that the pch pll is still enabled when we try to disable it. This would have caught the bug fixed in this patch. Reviewed-by:
-
Damien Lespiau authored
This makes, arguably, the condition on state easier to read. Suggested-by:
-
Chris Wilson authored
The hotplug_mask is no longer used as the hpd interrupt setup is now handled in the core. Signed-off-by:
-
- 07 Jun, 2013 8 commits
-
-
Ville Syrjälä authored
Don't enable the cursor until g4x_fixup_plane() had a chance to do cast its magic spell. Egbert writes: "Today I had the chance to test this. First I tried if I can still reproduce the blank with this patch added when I disable my voodoo g4x_fixup_plane(): It turned out it still happens however very rarely (like 1 out of 20 tries). When I reenabled my voodoo the issue still occurred. I had to switch two lines around, ie: intel_enable_plane(dev_priv, plane, pipe); if (IS_G4X(dev)) g4x_fixup_plane(dev_priv, pipe); + intel_crtc_update_cursor(crtc, true); to avoid the blank screen issue - which is it didn't happen in ~75 tries." v2: Add a comment to remind people of the ordering constraints Acked-by:Egbert Eich <eich@suse.com> Signed-off-by:
-
Rodrigo Vivi authored
WaFbcNukeOn3DBlt for IVB, HSW. According BSPec: "Workaround: Do not enable Render Command Streamer tracking for FBC. Instead insert a LRI to address 0x50380 with data 0x00000004 after the PIPE_CONTROL that follows each render submission." v2: Chris noticed that flush_domains check was missing here and also suggested to do LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets use the module parameter check. v3: Adding Wa name as Damien suggested. v4: Ville noticed VLV doesn't support fbc at all and comment came wrong from spec. v5: Ville noticed than on blt a Cache Clean LRI should be used instead the Nuke one. v6: Check for flush domain on blt (by Ville). Check for scanout dirty (by Chris). v7: Apply proper fbc_dirty implemented by Chris. v8: remove unused variables. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Chris Wilson authored
This is required for tracking render damage for use with FBC and will be used in subsequent patches. Signed-off-by:
-
Ville Syrjälä authored
Pull the code to disable trickle feed for all primary planes into a separate function. Signed-off-by:
-
Ville Syrjälä authored
We disable trickle feed in all the (relevant) clock gating functions, except ironlake_init_clock_gating(). Copy paste the same code there as well. Signed-off-by:
-
Ville Syrjälä authored
According to BSpec, trickle feed should be disabled for BW and mobile CL. Those constraints seem to match all of our gen4 chipsets. Trickle feed is disabled via the MI_ARB_STATE register instead of per plane controls on gen4. Reviewed-by:
-
Ville Syrjälä authored
The docs say that the trickle feed disable bit is present (for primary planes only, not video sprites) on CTG, and that it must be set for ELK. Just set it for all g4x chipsets. v2: Do it in init_clock_gating too Reviewed-by:
-
Daniel Vetter authored
We always limited the link bw calculations to 24bpp. Tested with my shiny new high-bpc screen, seems to work as advertised. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65280Tested-by:
shui yangwei <yangweix.shui@intel.com> Reviewed-by:
-
- 06 Jun, 2013 1 commit
-
-
Daniel Vetter authored
For various reasons the hw state readout might not be able to faithfully match the hw state: - broken hw (like the case which motivated this patch here where the sdvo encoder does not implemented mandatory functionality correctly). - platforms which are not supported fully with the pipe config infrastructure - if our code doesn't support a given hw configuration natively, e.g. special restrictions on the per-pipe panel fitters when they're used in high-quality scaling modes. In all these cases both fastboot and the hw state cross checker need to be aware of these cases and act accordingly. To be able to do this add a new quirk flag to the pipe config structure. The specific case at hand is an sdvo encoder which doesn't implement the get_timings function, so adjusted_mode flags will be wrong. The strange thing though is that the encoder _does_ work, even though it doesn't implement any of the timings functions (so neither get nor set, neither for input nor output timings). Not that non-compliant sdvo encoder are any surprise at all ... v2: - Don't read random garbage from the dtd if the get_timings call failed (suggested by Chris). - Still check the interlaced flag, that's read out from someplace else. We want maximal paranoia, after all. Reviewed-by:
-
