summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)Author
2013-04-18drm/i915: IVB/HSW have 32 fence registerVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Return stored value from max freq sysfs entryMika Kuoppala
commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584 Author: Ben Widawsky <ben@bwidawsk.net> 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 <ben@bwidawsk.net> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Remove stale codeBen Widawsky
Looks like a some remnant from a rebase. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Increase max fence pitch limit to 256KB on IVB+Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Reject fence stride=0 on gen4+Ville Syrjälä
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Configure GAM_ECOCHK appropriatly for Gen7Ville Syrjälä
IVB and HSW use different encodings for the PPGTT cacheability bits in the GAM_ECOCHK register. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Set GAC_ECO_BITS register on Gen7+Ville Syrjälä
According to BSpec GAC_ECO_BITS register exists on Gen7 platforms as well. Configure it accordingly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Add ECOBITS_SNB_BITVille Syrjälä
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ä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Don't default to overclock maxBen Widawsky
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> 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>
2013-04-18drm/i915: Better overclock supportBen Widawsky
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 <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment that Mika spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: use lower aux clock divider on non-ULT HSWJani Nikula
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 <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Kill spurious tab spotted by Paulo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Allow PPGTT enable to failBen Widawsky
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 <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: NULL aliasing_ppgtt on cleanupBen Widawsky
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 <ben@bwidawsk.net> [danvet: Spill the secrets about failing ppgtt init.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Abstract PPGTT enablingBen Widawsky
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 <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Rework PPGTT init codeBen Widawsky
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 <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Conditionally carve out GGTT PDEBen Widawsky
It only works that way on GEN6 and GEN7. Let's not assume GENn will be the same. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915/ppgtt: Set scratch page "globally"Ben Widawsky
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 <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: random checkpatch fixesBen Widawsky
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 <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Map registers before GTT initBen Widawsky
This will allow us to read/write registers in GTT init. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fix up error handling. We really should look into devres for this stuff ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Call out GEN6 PTE specificityBen Widawsky
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 <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: generalize pte vs. register BAR allocationBen Widawsky
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 <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Use MLC (l3$) for context objectsChris Wilson
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 <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: update FDI mPHY setup codeDaniel Vetter
Bspec has been been updated and dropped these two changes for non-sdv LPT PCHs. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Workaround incoherence between fences and LLC across multiple CPUsChris Wilson
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 <chris@chris-wilson.co.uk> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Tested-by: Jon Bloomfield <jon.bloomfield@intel.com> (v2) Cc: stable@vger.kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: tune down Y tiling scanout warningDaniel Vetter
Userspace can easily hit this and does since Ville added a new evil igt testcase in: commit 069e35e0fc3785faa562adcfd2dd7bbed4cb1dea Author: Ville Syrjälä <ville.syrjala@linux.intel.com> 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ä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63246 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: set CB tuning also for the reduce clockDaniel Vetter
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 <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: fix FP CB tuning limits for lvdsDaniel Vetter
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 <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: fix lost FP_CB_TUNE setting for pch pllsDaniel Vetter
commit de13a2e3f88a4da8e85063b6de37096795079e41 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> 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 <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: Fix SDVO connector and encoder get_hw_state functionsEgbert Eich
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 <daniel.vetter@ffwll.ch> Date: Tue Apr 2 21:30:34 2013 +0200 drm/i915: Fix sdvo connector get_hw_state function Signed-off-by: Egbert Eich <eich@suse.de> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63031 Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-08drm/i915: Add a pipeless ivybridge configurationBen Widawsky
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 <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-08drm/i915: Set PCH_NOPBen Widawsky
Set up PCH_NOP when we match a certain platform. v2: Just do a num_pipes check + comment instead of trying to check the platform (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-08drm/i915: Don't wait for PCH on resetBen Widawsky
BIOS should be setting this, but in case it doesn't... v2: Define the bits we actually want to clear (Jesse) Make it an RMW op (Jesse) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-08drm/i915: Don't touch South Display when PCH_NOPBen Widawsky
Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will be bad for CPU" range when we have PCH_NOP. There is a bit of a hack in init clock gating. We want to do most of the clock gating, but the part we skip will hang the system. It could probably be abstracted a bit better, but I don't feel it's too unsightly. v2: Use inverse HAS_PCH_NOP check (Jani) v3: Actually do what I claimed in v2 (spotted by Daniel) Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel) Move LVDS bail into this patch (Ben) v4: logical rebase conflict resolution with SDEIIR (Ben) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Brush up patch a bit and resolve conflicts: - Adjust PCH_NOP checks due to Egbert's hpd handling rework. - Addd a PCH_NOP check in the irq uninstall code. - Resolve conflicts with Paulo's SDE irq handling race fix. v5: Drop the added hunks in the ilk irq handler again, they're bogus. OOps. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-06drm/i915: PCH_NOPBen Widawsky
Given certain fusing options discussed in the previous patch, it's possible to end up with platforms that normally have PCH but that PCH doesn't actually exist. In many cases, this is easily remedied with setting 0 pipes. This covers the other corners. Requiring this is a symptom of improper code splitting (using HAS_PCH_SPLIT instead of proper GEN checking, basically). I do not want to fix this. v2: Remove PCH reflck after change in previous patch (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-06drm/i915: Support PCH no displayBen Widawsky
GEN supports a fusing option which subtracts the PCH display (making the CPU display also useless). In this configuration MMIO which gets decoded to a certain range will hang the CPU. For us, this is sort of the equivalent of having no pipes, and we can easily modify some code to not do certain things with no pipes. v2: Moved the num pipes check up in the call chain, and removed extra checks noted by Daniel. For more details, see: http://lists.freedesktop.org/archives/intel-gfx/2013-March/025746.html v3: Drop the intel_setup_overlay check (Daniel) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-06drm/i915: info level for simulated gpu hang dmesg noticeDaniel Vetter
Otherwise running igt will fill your dmesg with hang notices and it's hard to judge from a quick look whether they're expected or not. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-05drm/i915: revert eDP bpp clamping code changesDaniel Vetter
The behaviour around handling the eDP bpp value from vbt has been slightly changed in commit 3600836585e3fdef0a1410d63fe5ce4015007aac Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:59 2013 +0100 drm/i915: convert DP autodither code to new infrastructure The old behaviour was that we used the plane's bpp (usually 24bpp) for computing the dp link bw, but set up the pipe with the bpp value from vbt if available. This takes the vbt bpp override into account even for the dp link bw configuration. On Paulo's hsw machine this resulted in a slower link clock and a black screen - but the mode actually /should/ fit even with the lower clock. Until we've cleared up simply stay bug-for-bug compatible with the old code. While at it, also restore a debug message lost in: commit 4e53c2e010e531b4a014692199e978482d471c7e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Mar 27 00:44:58 2013 +0100 drm/i915: precompute pipe bpp before touching the hw Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-05Revert "drm/i915: fix DP get_hw_state return value"Daniel Vetter
This reverts commit deb18211a110c102d32b3e9ed866bd7d25e0f8d5. It completely breaks the logic, since when we fall through to the end of the function we actually _have_ figured out the correct pipe. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-05drm/i915: Don't use the HDMI port color range bit on ValleyviewVille Syrjälä
VLV docs still list the the color range selection bit for the HDMI ports, but for DP ports it has been repurposed. I have no idea whether the HDMI color range selection bit still works on VLV, but since we now have to use the PIPECONF color range bit for DP, we might as well do the same for HDMI. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-05drm/i915: Set PIPECONF color range bit on ValleyviewVille Syrjälä
VLV has the color range selection bit in the PIPECONF register. Configure it appropriately. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: fixup rebase issues due to slightly different baseline.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-05drm/i915: extract i9xx_set_pipeconfDaniel Vetter
Prep-patch to improve the bpc handling in a next patch. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-05drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900Christian Lamparter
The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900 mini desktop PCs are probably misleading the LVDS detection code in intel_lvds_supported. Nothing is connected to the LVDS ports in these systems. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: create pipe_config->dpll for clock stateDaniel Vetter
Clock computations and handling are highly encoder specific, both in the optimal clock selection and also in which clocks to use and when sharing of clocks is possible. So the best place to do this is somewhere in the encoders, with a generic fallback for those encoders without special needs. To facility this, add a pipe_config->clocks_set boolean. This patch here is only prep work, it simply sets the computed clock values in pipe_config->dpll, and uses that data in the hw clock setting functions. Haswell code isn't touched, simply because Haswell clocks work much different and need their own infrastructure (with probably a Haswell-specific config->ddi_clock substruct). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: hw readout support for ->has_pch_encodersDaniel Vetter
Now we can ditch the checks in the Haswell disable code. v2: add support for Haswell Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: add hw state readout/checking for pipe_configDaniel Vetter
We need to be able to read out the hw state code for a bunch of reasons: - Correctly disabling boot-up/resume state. - Pure paranoia. Since not all of the pipe configuration is e.g. relevant for fastboot (or at least we can allow some wiggle room in some parameters, like the clocks), we need to add a strict_checking parameter to intel_pipe_config_compare for fastboot. For now intel_pipe_config_compare should be fully paranoid and check everything that the hw state readout code supports. Which for this infrastructure code is nothing. I've gone a bit overboard with adding 3 get_pipe_config functions: The ilk version will differ with the next patch, so it's not too onerous. v2: Don't check the hw config if the pipe is off, since an enabled, but dpms off crtc will obviously have tons of difference with the hw state. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: rip out superflous is_dp&is_cpu_edp trackingDaniel Vetter
The only exception left is is_cpu_edp in the haswell modeset code. We need that to assign the cpu transcoder, but we might want to move that eventually into the encoder, too. \o/-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: remove leaky eDP functionsDaniel Vetter
Jesse Barnes noticed in his review of my DP cleanup series that intel_edp_target_clock is now unused. Checking related code I've noticed that also intel_edp_link_config is long unused. Kill them both. Wrt leaky eDP functions used in the common crtc code, the only thing still left is intel_encoder_is_pch_edp. That one is just due to the massive confusion between eDP vs. DP and port A vs. port D. Crtc code should at most concern itself with the later, never with the former. But that's material for another patch series. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: track dp target_clock in pipe_configDaniel Vetter
We need it in the fdi m_n computation, which nicely kills almost all ugly special cases in there. It looks like we also need this to handle 12bpc hdmi correctly. Eventually it might be better to switch things around and put the target clock into adjusted_mode->clock and create a new pipe_config parameter for the port link clock. v2: Add a massive comment in the code to explain this mess. v3: s/dp_target_clock/pixel_target_clock in anticipation of the hdmi use-case. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: move dp_m_n computation to dp_encoder->compute_configDaniel Vetter
We need a flag to designate dp encoders and the dp link m_n parameters in the pipe config for that. And now that the pipe bpp computations have been moved up and stored in the pipe config, too, we can do this without losing our sanity. v2: Rebased on top of Takashi Iwai's fix to (again) fix the target clock handling for eDP. Luckily the new code is sane enough and just does the right thing! v3: Move ->has_dp_encoder to this patch (Jesse). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03drm/i915: clear up the fdi/dp set_m_n confusionDaniel Vetter
There's a rather decent confusion going on around transcoder m_n values. So let's clarify: - All dp encoders need this, either on the pch transcoder if it's a pch port, or on the cpu transcoder/pipe if it's a cpu port. - fdi links need to have the right m_n values for the fdi link set in the cpu transcoder. To handle the pch vs transcoder stuff a bit better, extract transcoder set_m_n helpers. To make them simpler, set intel_crtc->cpu_transcoder als in ironlake_crtc_mode_set, so that gen5+ (where the cpu m_n registers are all at the same offset) can use it. Haswell modeset is decently confused about dp vs. edp vs. fdi. dp vs. edp works exactly the same as dp (since there's no pch dp any more), so use that as a check. And only set up the fdi m_n values if we really have a pch encoder present (which means we have a VGA encoder). On ilk+ we've called ironlake_set_m_n both for cpu_edp and for pch encoders. Now that dp_set_m_n handles all dp links (thanks to the pch encoder check), we can ditch the cpu_edp stuff from the fdi_set_m_n function. Since the dp_m_n values are not readily available, we need to carefully coax the edp values out of the encoder. Hence we can't (yet) kill this superflous complexity. v2: Rebase on top of the ivb fdi B/C check patch - we need to properly clear intel_crtc->fdi_lane, otherwise those checks will misfire. v3: Rebased on top of a s/IS_HASWELL/HAS_DDI/ patch from Paulo Zanoni. v4: Drop the addition of has_dp_encoder, it's in the wrong patch (Jesse). Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-10-30 07:31:33 +0000