aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-04-18drm/i915: move cpu_transcoder to the pipe configurationDaniel Vetter4-24/+32
For a bunch of reason we need to more accurately track this: - hw pipe state readout for Haswell needs the cpu transcoder. - We need to know the right cpu transcoder in a bunch of places in ->disable and other modeset callbacks. In the future we need to add hw state readout&check support, too. But to avoid ugly merge conflicts do the rote sed job now without any functional changes. v2: Preserve the cpu_transcoder value when overwriting crtc->config. Reported by Paulo. Cc: Paulo Zanoni <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Reviewed-by: Chris Wilson <[email protected]> (v1) [danvet: Removed rough whitespace that Chris spotted.] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: preserve the PBC bits of TRANS_CHICKEN2Paulo Zanoni2-3/+11
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits are being zeroed, but I couldn't find a reason for this, so leave them as they are for now to avoid regressions. Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Imre Deak <[email protected]> [danvet: Delete the redudant #define that Imre spotted in his review.] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: set CPT FDI RX polarity bits based on VBTPaulo Zanoni5-6/+16
Check the VBT to see if the machine has inverted FDI RX polarity on CPT. Based on this bit, set the appropriate bit on the TRANS_CHICKEN2 registers. This should fix some machines that were showing black screens on all outputs. Cc: [email protected] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60029 Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)Egbert Eich2-1/+52
We disable hoptplug detection when we encounter a hotplug event storm. Still hotplug detection is required on some outputs (like Display Port). The interrupt storm may be only temporary (on certain Dell Laptops for instance it happens at certain charging states of the system). Thus we enable it after a certain grace period (2 minutes). Should the interrupt storm persist it will be detected immediately and it will be disabled again. v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker. v3: Clarified loop start value, Removed superfluous test for Ivybridge and Haswell, Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä) v4: Fixed two bugs pointed out by Jani Nikula. Signed-off-by: Egbert Eich <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)Egbert Eich1-17/+58
This patch disables hotplug interrupts if an 'interrupt storm' has been detected. Noise on the interrupt line renders the hotplug interrupt useless: each hotplug event causes the devices to be rescanned which will will only increase the system load. Thus disable the hotplug interrupts and fall back to periodic device polling. v2: Fixed cleanup typo. v3: Fixed format issues, clarified a variable name, changed pr_warn() to DRM_INFO() as suggested by Jani Nikula <[email protected]>. Signed-off-by: Egbert Eich <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Mask out the HPD irq bits before setting them individually.Egbert Eich1-0/+2
To disable previously enabled HPD IRQs we need to reset them and set the enabled ones individually. Signed-off-by: Egbert Eich <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: (re)init HPD interrupt storm statisticsEgbert Eich7-10/+23
When an encoder is shared on several connectors there is only one hotplug line, thus this line needs to be shared among these connectors. If HPD detect only works reliably on a subset of those connectors, we want to poll the others. Thus we need to make sure that storm detection doesn't mess up the settings for those connectors. Therefore we store the settings in the intel_connector struct and restore them from there. If nothing is set but the encoder has a hpd_pin set we assume this connector is hotplug capable. On init/reset we make sure the polled state of the connectors is (re)set to the default value, the HPD interrupts are marked enabled. Signed-off-by: Egbert Eich <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Add HPD IRQ storm detection (v5)Egbert Eich2-12/+66
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt fires more than 5 times / sec). Rationale: Despite of the many attempts to fix the problem with noisy hotplug interrupt lines we are still seeing systems which have issues: Once cause of noise seems to be bad routing of the hotplug line on the board: cross talk from other signals seems to cause erronous hotplug interrupts. This has been documented as an erratum for the the i945GM chipset and thus hotplug support was disabled for this chipset model but others seem to have this problem, too. We have seen this issue on a G35 motherboard for example: Even different motherboards of the same model seem to behave differently: while some only see only around 10-100 interrupts/s others seem to see 5k or more. We've also observed a dependency on the selected video mode. Also on certain laptops interrupt noise seems to occur duing battery charging when the battery is at a certain charge levels. Thus we add a simple algorithm here that detects an 'interrupt storm' condition. v2: Fixed comment. v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff. v4: Followed by Jesse Barnes to use a time_..() macro. v5: Fixed coding style as suggested by Jani Nikula. Signed-off-by: Egbert Eich <[email protected]> Acked-by: Chris Wilson <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: WARN when LPT-LP is not paired with ULT CPUPaulo Zanoni1-0/+2
Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: don't intel_crt_init on any ULT machinesPaulo Zanoni1-1/+1
We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not have CRT, so just check for !IS_ULT. This problem happened on a real machine and resulted in a very ugly dmesg. Cc: [email protected] Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: remove comment about IVB link training from intel_pm.cPaulo Zanoni1-1/+0
We have the exact same comment inside intel_init_display. This is a leftover from when we moved a lot of code from intel_display.c to intel_pm.c. Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: VLV doesn't have LLCBen Widawsky1-0/+2
Caused by me with v2 of commit 219f4fdbed5570f1d2e8da0af1c298dd3622060e Author: Ben Widawsky <[email protected]> Date: Fri Mar 15 11:17:54 2013 -0700 drm/i915: Introduce GEN7_FEATURES for device info I don't have a VLV to test it with, Jesse, Ken, can one of you test? Cc: Jesse Barnes <[email protected]> Cc: Kenneth Graunke <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Scale ring, rather than ia, frequency on HaswellChris Wilson3-16/+38
Haswell introduces a separate frequency domain for the ring (uncore). So where we used to increase the CPU (IA) clock with GPU busyness, we now need to scale the ring frequency directly instead. As the ring limits our memory bandwidth, it is vital for performance that when the GPU is busy, we increase the frequency of the ring to increase the available memory bandwidth. v2: Fix the algorithm to actually use the scaled gpu frequency for the ring. v3: s/max_ring_freq/min_ring_freq/ as that is what it is Signed-off-by: Chris Wilson <[email protected]> Cc: Jesse Barnes <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> [danvet: Add space checkpatch complained about.] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: shorten debugfs output simple attributesMika Kuoppala1-4/+4
commit 647416f9eefe7699754b01b9fc82758fde83248c Author: Kees Cook <[email protected]> Date: Sun Mar 10 14:10:06 2013 -0700 drm/i915: use simple attribute in debugfs routines made i915_next_seqno debugfs entry to crop it's output if returned value was large enough. Using simple_attr will limit the output to 24 bytes. Fix is to strip out preamples on all simple attributes that have one. v2: Fix all simple attributes (Daniel Vetter) Cc: Kees Cook <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Acked-by: Kees Cook <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Fixup pfit disabling for gen2/3Daniel Vetter1-7/+21
The recent rework of the pfit handling didn't take into account that the panel fitter is fixed to pipe B: commit 24a1f16de97c4cf0029d9acd04be06db32208726 Author: Mika Kuoppala <[email protected]> Date: Fri Feb 8 16:35:37 2013 +0200 drm/i915: disable shared panel fitter for pipe Fix this up by properly computing the pipe the pfit is on. Also extract the logic into its own function, add a debug assert to check that the pipe is off (mostly just documentation) and add some debug output. If pipe A was disabled after pipe B was set up, the panel fitter will be disabled. Now most userspace doesn't do modesets in this order, which is why I couldn't ever reproduce this and why it took me so long to figure out. We really need hw state readout and check support for the pannel fitter ... Reported-by: Hans de Bruin <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Hans de Bruin <[email protected]> References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19049 Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Fixup Oops in the pipe config computationDaniel Vetter1-10/+13
Yet again our current confusion between doing the modeset globally, but only having the new parameters for one crtc at a time. So that intel_set_mode essentially already does a global modeset: intel_modeset_affected_pipes compares the current state with where we want to go to (which is carefully set up by intel_crtc_set_config) and then goes through the modeset sequence for any crtc which needs updating. Now the issue is that the actual interface with the remaining code still only works on one crtc, and so we only pass in one fb and one mode. In intel_set_mode we also only compute one intel_crtc_config (which should be the one for the crtc we're doing a modeset on). The reason for that mismatch is twofold: - We want to eventually do all modeset as global state changes, so it's just infrastructure prep. - But even the old semantics can change more than one crtc when you e.g. move a connector from crtc A to crtc B, then both crtc A and B need to be updated. Usually that means one pipe is disabled and the other enabled. This is also the reason why the hack doesn't touch the disable_pipes mask. Now hilarity ensued in our kms config restore paths when we actually try to do a modeset on all crtcs: If the first crtc should be off and the second should be on, then the call on the first crtc will notice that the 2nd one should be switched on and so tries to compute the pipe_config. But due to a lack of passed-in fb (crtc 1 should be off after all) it only results in tears. This case is ridiculously easy to hit on gen2/3 where the lvds output is restricted to pipe B. Note that before the pipe_config bpp rework gen2/3 didn't care really about the fb->depth, so this is a regression brought to light with commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter <[email protected]> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw But apparently Ajax also managed to blow up pch platforms, probably with some randomized configs, and pch platforms trip up over the lack of an fb even in the old code. So this actually goes back to the first introduction of the new modeset restore code in commit 45e2b5f640b3766da3eda48f6c35f088155c06f3 Author: Daniel Vetter <[email protected]> Date: Fri Nov 23 18:16:34 2012 +0100 drm/i915: force restore on lid open Fix this mess by now by justing shunting all the cool new global modeset logic in intel_modeset_affected_pipes. v2: Improve commit message and clean up all the comments in intel_modeset_affected_pipes - since the introduction of the modeset restore code they've been a bit outdated. Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725 Cc: [email protected] References: http://www.mail-archive.com/[email protected]/msg38084.html Tested-by: Richard Cochran <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: ensure single initialization and cleanup of backlight deviceJani Nikula4-6/+10
Backlight cleanup in the eDP connector destroy callback caused the backlight device to be removed on some systems that first initialized LVDS and then attempted to initialize eDP. Prevent multiple backlight initializations, and ensure backlight cleanup is only done once by moving it to modeset cleanup. A small wrinkle is the introduced asymmetry in backlight setup/cleanup. This could be solved by adding refcounting, but it seems overkill considering that there should only ever be one backlight device. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701 Signed-off-by: Jani Nikula <[email protected]> Tested-by: Peter Verthez <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: don't touch the PF regs if the power well is downPaulo Zanoni1-3/+7
This solves some "unclaimed register" messages when booting the machine with eDP attached. V2: Rebase and add the comment requested by Daniel. Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: add intel_using_power_wellPaulo Zanoni3-2/+19
It returns true if we've requested to turn the power well on and it's really on. It also returns true for all the previous gens. For now there's just one caller, but I'm going to add more. Signed-off-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: don't check inconsistent modeset state when force-restoringDaniel Vetter1-6/+24
It will be only consistent once we've restored all the crtcs. Since a bunch of other callers also want to just restore a single crtc, add a boolean to disable checking only where it doesn't make sense. Note that intel_modeset_setup_hw_state already has a call to intel_modeset_check_state at the end, so we don't reduce the amount of checking. v2: Try harder not to create a big patch (Chris). v3: Even smaller (still Chris). Also fix a trailing space. References: https://lkml.org/lkml/2013/3/16/60 Cc: Tomas Melin <[email protected]> Cc: Richard Cochran <[email protected]> Cc: Chris Wilson <[email protected]> Cc: [email protected] Reviewed-by: Chris Wilson <[email protected]> Tested-by: Tomas Melin <[email protected]> Tested-by: Richard Cochran <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: IVB/HSW have 32 fence registerVille Syrjälä3-5/+7
Increase the number of fence registers to 32 on IVB/HSW. VLV however only has 16 fence registers according to the docs. Increasing the number of fences was attempted before [1], but there was some uncertainty about the maximum CPU fence number for FBC. Since then BSpec has been updated to state that there are in fact 32 fence registers, and the CPU fence number field in the SNB_DPFC_CTL_SA register is 5 bits, and the CPU fence number field in the ILK_DPFC_CONTROL register must be zero. So now it all makes sense. [1] http://lists.freedesktop.org/archives/intel-gfx/2011-October/012865.html v2: Include some background information based on the previous attempt Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Return stored value from max freq sysfs entryMika Kuoppala1-1/+1
commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584 Author: Ben Widawsky <[email protected]> Date: Fri Apr 5 14:29:22 2013 -0700 drm/i915: Better overclock support changed the sysfs read semantics for 'gt_max_freq_mhz'. By always returning overclock max instead of stored value. Fix this by returning the stored value. Separate sysfs entry should be considered for overclocking max freq. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63415 Cc: Ben Widawsky <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Remove stale codeBen Widawsky1-3/+0
Looks like a some remnant from a rebase. Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Increase max fence pitch limit to 256KB on IVB+Ville Syrjälä2-3/+7
BSpec contains several scattered notes which state that the maximum fence stride was increased to 256KB on IVB. Testing on real hardware agrees. Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Reject fence stride=0 on gen4+Ville Syrjälä1-3/+3
Our checks for an invalid fence stride forgot to guard against zero stride on gen4+. Fix it. v2: Avoid duplicated code (danvet) Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Configure GAM_ECOCHK appropriatly for Gen7Ville Syrjälä2-2/+14
IVB and HSW use different encodings for the PPGTT cacheability bits in the GAM_ECOCHK register. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Set GAC_ECO_BITS register on Gen7+Ville Syrjälä1-0/+5
According to BSpec GAC_ECO_BITS register exists on Gen7 platforms as well. Configure it accordingly. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Add ECOBITS_SNB_BITVille Syrjälä2-1/+3
GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add the define, and enable it on SNB. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Don't default to overclock maxBen Widawsky1-2/+1
Requested-by: Daniel Vetter <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Better overclock supportBen Widawsky4-6/+16
Most importantly this will allow users to set overclock frequencies in sysfs. Previously the max was limited by the RP0 max as opposed to the overclock max. This is useful if one wants to either limit the max overclock frequency, or set the minimum frequency to be in the overclock range. It also fixes an issue where if one sets the max frequency to be below the overclock max, they wouldn't be able to set back the proper overclock max. In addition I've added a couple of other bits: Show the overclock freq. as max in sysfs Print the overclock max in debugfs. Print a warning if the user sets the min frequency to be in the overclock range. In this patch I've decided to store the hw_max when we read it from the pcode at init. The reason I do this is the pcode reads can fail, and are slow. v2: Report when user requested overclocked max (Daniel) Remove when user sets min to overclock range (Daniel) Reported-by: freezer from #intel-gfx on irc Signed-off-by: Ben Widawsky <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> [danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment that Mika spotted.] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: use lower aux clock divider on non-ULT HSWJani Nikula1-2/+6
Workaround to avoid intermittent aux channel failures, per spec change. v2: Don't mess with cpu dp aux divider (Paulo Zanoni) Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> [danvet: Kill spurious tab spotted by Paulo.] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Allow PPGTT enable to failBen Widawsky4-6/+15
I'm really not happy that we have to support this, but this will be the simplest way to handle cases where PPGTT init can fail, which I promise will be coming in the future. v2: Resolve conflicts due to patch series reordering. Signed-off-by: Ben Widawsky <[email protected]> (v1) Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: NULL aliasing_ppgtt on cleanupBen Widawsky1-0/+1
This will allow us to carry on if we've cleaned up the PPGTT. The usage for this is coming up - it simplifies handling a failed PPGTT init. Signed-off-by: Ben Widawsky <[email protected]> [danvet: Spill the secrets about failing ppgtt init.] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Abstract PPGTT enablingBen Widawsky4-61/+61
Since we've already set up a nice vtable to abstract other PPGTT functions, also abstract the actual register programming to enable things. This function will probably need to change a bit as we implement real processes. v2: Resolve conflicts due to patch series reordering. Signed-off-by: Ben Widawsky <[email protected]> (v1) Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Rework PPGTT init codeBen Widawsky1-1/+5
This rework will help if future platforms choose to be a bit different. Should have no functional impact. v2: Don't move around the vtable setup (Daniel) v3: Squash in the disable-by-default patch. Signed-off-by: Ben Widawsky <[email protected]> (v1) Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Conditionally carve out GGTT PDEBen Widawsky1-3/+6
It only works that way on GEN6 and GEN7. Let's not assume GENn will be the same. Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915/ppgtt: Set scratch page "globally"Ben Widawsky1-2/+1
The PPGTT scratch page is used for all gens, and doing it in the global part of our PPGTT setup makes the code a bit nicer. This was in a patch submitted earlier as part of the PPGTT cleanups. Grumpy maintainer must have missed it, and I didn't yell when appropriate. Apologies for everyone :-) v2: Update commit message Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: random checkpatch fixesBen Widawsky1-3/+2
There used to be other fixes in this patch but they've slowly disappeared as other parts have been fixed. Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Map registers before GTT initBen Widawsky1-24/+23
This will allow us to read/write registers in GTT init. Signed-off-by: Ben Widawsky <[email protected]> [danvet: Fix up error handling. We really should look into devres for this stuff ...] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Call out GEN6 PTE specificityBen Widawsky1-16/+15
We can assume that the PTE layout, and size changes for future generations. To avoid confusion with the existing GEN6 PTE typedef, give it a GEN6_ prefix. v2: Fixup checkpatch warning and bikeshed commit message slightly. v3: Rebase on top of Imre's for_each_sg_pages rework. v4: Fixup conflicts in patch series reordering. Signed-off-by: Ben Widawsky <[email protected]> (v1) Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: generalize pte vs. register BAR allocationBen Widawsky1-2/+4
All gen6+ parts so far have 1 BAR which holds both the register space and the GTT PTEs. Up until now, that was a 4MB BAR with half allocated to each. I have a strong hunch (wink, nod, wink) that future gens will also keep a similar 50-50 split though the sizes may change. To help this along change the code to obey the rule of half the total size instead of a hard-coded 2MB. Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Use MLC (l3$) for context objectsChris Wilson1-0/+7
Enabling context support increases SwapBuffers latency by about 20% (measured on an i7-3720qm). We can offset that loss slightly by enabling faster caching for the contexts. As they are not backed by any particular cache (such as the sampler or render caches) our only option is to select the generic mid-level cache. This reduces the latency of the swap by about 5%. Oddly this effect can be observed running smokin-guns on IVB at 1280x1024: Using BLT copies for swaps: 151.67 fps Using Render copies for swaps (unpatched): 141.70 fps With contexts disabled: 150.23 fps With contexts in L3$: 150.77 fps Signed-off-by: Chris Wilson <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Kenneth Graunke <[email protected]> Reviewed-by: Kenneth Graunke <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: update FDI mPHY setup codeDaniel Vetter1-7/+0
Bspec has been been updated and dropped these two changes for non-sdv LPT PCHs. Cc: Paulo Zanoni <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Workaround incoherence between fences and LLC across multiple CPUsChris Wilson1-5/+23
In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and manually flush writes to memory prior to writing the fence register in conjunction with the memory barriers placed around the register write. Fixes i-g-t/gem_fence_thrash v2: Bring a bigger gun v3: Switch the bigger gun for heavier bullets (Arjan van de Ven) v4: Remove changes for working generations. v5: Reduce to a per-cpu wbinvd() call prior to updating the fences. v6: Rewrite comments to ellide forgotten history. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191 Signed-off-by: Chris Wilson <[email protected]> Cc: Jon Bloomfield <[email protected]> Tested-by: Jon Bloomfield <[email protected]> (v2) Cc: [email protected] Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: tune down Y tiling scanout warningDaniel Vetter1-2/+4
Userspace can easily hit this and does since Ville added a new evil igt testcase in: commit 069e35e0fc3785faa562adcfd2dd7bbed4cb1dea Author: Ville Syrjälä <[email protected]> Date: Mon Mar 4 15:34:06 2013 +0200 kms_flip: Add flip-vs-bad-tiling test v2: Fix the spelling in the added comment (Chris). Cc: Ville Syrjälä <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63246 Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: set CB tuning also for the reduce clockDaniel Vetter1-2/+7
Since the ratio is different, we also need to pass in the parameters for the reduced clock. Might or might not reduce flicker for the auto-downclocking on lvds/eDP. Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: fix FP CB tuning limits for lvdsDaniel Vetter1-1/+1
Only on IBX should we set the limiting factor to 25 unconditionally for dual-channel mode, on CPT/PPT 25 only applies when the lvds refclock is 100MHz. Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: fix lost FP_CB_TUNE setting for pch pllsDaniel Vetter1-3/+3
commit de13a2e3f88a4da8e85063b6de37096795079e41 Author: Paulo Zanoni <[email protected]> Date: Thu Sep 20 18:36:05 2012 -0300 drm/i915: extract compute_dpll from ironlake_crtc_mode_set missed the subtle adjustment of the FP1 register. Fix this up by passing a pointer around instead of the value. Cc: Paulo Zanoni <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-04-18drm/i915: Fix SDVO connector and encoder get_hw_state functionsEgbert Eich1-6/+3
The connector associated with the encoder is considered active when the output associtated with this connector is active on the encoder. The encoder itself is considered active when either there is an active output on it or the respective SDVO channel is active. Having active outputs when the SDVO channel is inactive seems to be inconsistent: such states can be found when intel_modeset_setup_hw_state() collects the hardware state set by the BIOS. This inconsistency will be fixed in intel_sanitize_crtc() (when intel_crtc_update_dpms() is called), this however only happens when the encoder is associated with a crtc. This patch also reverts: commit bd6946e87a98fea11907b2a47368e13044458a35 Author: Daniel Vetter <[email protected]> Date: Tue Apr 2 21:30:34 2013 +0200 drm/i915: Fix sdvo connector get_hw_state function Signed-off-by: Egbert Eich <[email protected]> Suggested-by: Daniel Vetter <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031 Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2013-04-08drm/i915: Add a pipeless ivybridge configurationBen Widawsky1-0/+17
FIXME: This is based on some HW being used for a demo. We should probably wait until we have confirmation on the IDs before upstreaming this patch. v2: Use GEN7_FEATURES (Chris) Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.