- 29 Apr, 2013 11 commits
-
-
Daniel Vetter authored
This nicely allows us to drop some hacks which have only been used to work around modeset failures due to lack of fdi lanes. v2: Implement proper checking for Haswell platforms - the fdi link to the LPT PCH has only 2 lanes. Note that we already filter out impossible modes in intel_crt_mode_valid. Unfortunately LPT does not support 6bpc on the fdi rx, so we can't pull clever tricks to squeeze in a few more modes. v2: Rebased on top of Ben Widawsky's num_pipes reorg. v3: Rebase on top of Ville's pipe debug output ocd rampage. v4: Fixup rebase fail spotted by Ville. v5: Fixup rebase fail spotted by Imre Deak. I suck. Cc: Imre Deak <imre.deak@intel.com> Cc: 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>
-
Daniel Vetter authored
Again in preparation to move the configuration checks into the pipe_config computation stage of the modeset sequence. Reviewed-by:
-
Daniel Vetter authored
Now that it's split up, we can easily move it around and precompute the fdi lane configuration. Reviewed-by:
-
Daniel Vetter authored
And also move the computed m_n values into the pipe_config. This is a prep step to move the fdi state computation completely into the prepare phase of the modeset sequence. Which will allow us to handle fdi link bw constraints in a better way. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
v2: Introduce some nice #defines for the FDI lane width fields and put them to good use. Suggested by Ville. v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and use the shift #define also in the mask. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
We need this for two reasons: - Correct handling of shared fdi lanes on ivb with fastboot. - Handling fdi link bw limits when we only have two fdi lanes by dithering down a bit. Just search&replace in this patch, no functional change at all. Reviewed-by:
-
Daniel Vetter authored
Totally untested due to lack of screens supporting more than 8bpc. But now we should have closed all holes in our bpp handling, so this should be safe. The last missing piece was 10bpc support for g4x/vlv, since we directly use the pipe bpp to feed the display link (and anyway, only the cpt has any means to have a pipe bpp != the display link bpp). Reviewed-by:
-
Daniel Vetter authored
The current code is rather ... ugly. The only thing it managed to pull off is getting 6bpc on DP working on g4x. Then someone added another custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly implementing the PIPECONF-based dither/bpc controls on g4x/vlv. Note that compared to pch based platforms g4x/vlv don't support 12bpc modes. g4x is already caught, extend the check for vlv. The other fixup is to restrict the lvds-specific dithering to early gen4 devices - g4x should use the pipeconf dither controls. Note that on gen2/3 the dither control is in the panel fitter even. v2: Don't enable dithering when the pipe is in 10 bpc mode. Quoting from Bspec "PIPEACONF - Pipe A Configuration Register, bit 4": "Programming note: Dithering should only be enabled for 8 bpc or 6 bpc." v3: Actually drop the old ugly dither code. v4: Explain in a short comment why g4x/vlv shouldn't dither for 30 bpp pipes (Jesse). v5: Also clear the dither type correctly as spotted by Ville. v6: As Ville pointed out we need to indeed set the dithering both in the pipeconf register (for DP outputs) and in the LVDS port register (for LVDS ouputs). Otherwise LVDS panel will not get properly dithered. The old patch got away with this since it forgot to clear the LVDS dither bit ... v7: Remove redundant BPC_MASK clearing, spotted by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
They can get at the adjusted mode through intel_crtc->config. Reviewed-by:
-
Daniel Vetter authored
We've had our fair share of woes already which showed that we can't rely on the bpc limits in the EDID for eDP panels without risking black screens. So now we limit the depth by what the BIOS recommends in the VBT: commit 2f4f649a Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Nov 12 14:33:44 2012 +0200 drm/i915: do not ignore eDP bpc settings from vbt But that's not enough, since at least the panel on my ASUS Zenbook Prime here is also unhappy if the bpc is too low. Hence just take the firmware value and dither to get what flimsy panels want. Like before we ensure that we don't change the bpp if the firmware doesn't provide a value, see commit 9a30a61f Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Nov 12 14:33:45 2012 +0200 drm/i915: do not default to 18 bpp for eDP if missing from VBT v2: Apparently there are some horribly broken eDP panels around which only work if the DP link is set up as if we want to driver a 24bpp mode, but still only work if the data is feed at 18bpp. See commit 57c21963 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 4 17:19:37 2013 +0200 drm/i915: revert eDP bpp clamping code changes for the gory details. Adjust the patch accordingly and update all the relevant comments. v3: Give up on the cargo-culting v2 attempt and just enfore the edp bpp value if it's there. Broken panels be damned! Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
-
Daniel Vetter authored
This hack is getting a bit messy, but this plugs the leak for now until we have the cpu_transcoder properly pipe_config'ed. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
- 27 Apr, 2013 1 commit
-
-
Chris Wilson authored
Instead of repeatedly bombarding the user with a request to reboot and increase the stolen size with every fb refresh, just inform them the first time only. v2: Rearrange code so the hint to increase the amount of memory stolen by the BIOS is only emitted if we fail to find sufficient stolen memory for FBC. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup formatting code mismatch that gcc spotted.] Signed-off-by:
-
- 26 Apr, 2013 1 commit
-
-
Jesse Barnes authored
Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 25 Apr, 2013 17 commits
-
-
Jesse Barnes authored
We prevent invalid ones from getting here in the first place, but it doesn't hurt to have an extra sanity check. Signed-off-by:
-
Jesse Barnes authored
And put the pfit stuff into substructs while we're at it. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Jesse Barnes authored
This gets the panel fitter working on eDP on VLV, and should also apply to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one panel as eDP anyway). A few cleanups are still possible on top of this, for example the LVDS border control could be placed in the LVDS encoder structure and updated based on the result of the panel fitter calculation. Multi-pipe fitting isn't handled correctly either if we ever get a config that wants to try the panel fitter on more than one output at a time. v2: use pipe_config for storing pfit values (Daniel) add i9xx_pfit_enable function for use by 9xx and VLV (Daniel) v3: fixup conflicts and lvds_dither check Reviewed-by: -
Daniel Vetter authored
We only ever check whether it's strictly bigger than one, so all the is_sdvo/is_hdmi checks are redundant. Flatten the code a bit. Also, s/temp/dpll_md/ Reviewed-by:
-
Daniel Vetter authored
If we compute the pch pll state, we _have_ a pch encoder. Reviewed-by:
-
Daniel Vetter authored
g4x dplls and ilk+ pch plls have a separate field for the reduced p1 setting, so this restriction does not apply. Only older platforms have the restriction that the p1 divisors must match. This unnecessary restriction has been introduced in commit cec2f356 Author: Sean Paul <seanpaul@chromium.org> Date: Tue Jan 10 15:09:36 2012 -0800 drm/i915: Only look for matching clocks for LVDS downcloc Note that with lvds the p2 divisors _always_ match for LVDS, and we don't support auto-downclocking anywhere else. On eDP downclocking works with separate data m/n settings, using the same link clock. Cc: Sean Paul <seanpaul@chromium.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Daniel Vetter authored
Up to now we've relied on the bios to get this right for us. Let's try out whether our code has improved a bit, since we should dither always when the output bpp doesn't match the plane bpp. - gen5+ should be fine, since we only use the bios hint as an upgrade. - gen4 changes, since here dithering is still controlled in the lvds register. - gen2/3 has implicit dithering depeding upon whether you use 2 or 3 lvds pairs (which makes sense, since it only supports 8bpc pipe outpu configurations). - hsw doesn't support lvds. v2: Remove redudant dither setting. v3: Completly drop reliance on dev_priv->lvds_dither. v4: Enable dithering on gen2/3 only when we have a 18bpp panel, since up-dithering to a 24bpp panel is not supported by the hw. Spotted by Ville. v5: Also only enable lvds port dithering on gen4 for 18bpp modes. In practice this only excludes dithering a 10bpc plane down for a 24bpp lvds panel. Not something we truly care about. Again noticed by Ville. v6: Actually git add. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
With the exception of hsw, which has dedicated DP clocks which run at the fixed frequency already, and vlv, which doesn't have optmized pre-defined dp clock parameters (yet). v2: Ville asked me to elaborate a bit more on the longer-term goals wrt dpll settings computation: So ultimately my idea is that in the compute config stage first the crtc code puts the default platform pll limits into the pipe_config. Then encoders can either overwrite that limit structure with their own special stuff (mostly for lvds madness). Or they can pick some or all of the parameters (e.g. just the p2 switchover on hdmi, or all the clock parameters for dp/sdvo tv). Once that's done then the generic crtc code can fill out any missing bits (using the find_best_pll code) and then try to assign which pll to use (if it's a platform with shared plls). In the end the modeset could should simply write the computed stuff into registers and never be able to fail. Of course there's still a lot of data to be moved into pipe_config to make this all happen, hence some of the temporary ugliness. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Reviewed-by:
-
Daniel Vetter authored
This was somehow lost in the pipe_config->dpll introduction in commit f47709a9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 28 10:42:02 2013 +0100 drm/i915: create pipe_config->dpll for clock state While at it, extract a few small helpers for common computations. v2: Use the newly added helpers more thanks to Ville's trick to typedef the legacy intel_clock_t as the new-world struct dpll. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
We need the dpll/fp/fp2 values only when we need a pch pll. So move them together with the code to acquire such a pll. Reviewed-by:
-
Damien Lespiau authored
Between ivb, hsw and vlv, only Ivybridge has sprites with scaling capabilities. Also make max_downscale coherent with that. v2: Rebase on top of the recent ivb/vlv/hsw sprite scaling fixes. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1) Reviewed-by:
-
Jani Nikula authored
v2: Make TRANSCODER_EDP handling more explicit. (Imre) Signed-off-by:
-
Jani Nikula authored
With the previous work asle and gse interrupt handlers should now be functionally the same. Drop the duplicated code. v2: Drop intel_opregion_gse_intr() also in the !CONFIG_ACPI path. (Damien) Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Jani Nikula authored
In theory, the BIOS should not even request these from us now that we aren't claiming we support these, but when it does anyway, don't pretend it succeeded. It should be the right thing to do, but might confuse the BIOS. Signed-off-by:
-
Jani Nikula authored
In theory, this should prevent the BIOS from requesting them from us, and this should be the right thing. In practice, this is not always the case, and might surprise the BIOS. Signed-off-by:
-
Jani Nikula authored
Backlight data and registers are fiddled through LVDS/eDP modeset enable/disable hooks, backlight sysfs files, asle interrupts, and register save/restore. Protect the backlight related registers and driver private fields using a spinlock. The locking in register save/restore covers a little more than is strictly necessary, including non-modeset case, for simplicity. v2: Cover register access, save/restore, i915_read_blc_pwm_ctl() and code paths leading there. Signed-off-by: -
Jani Nikula authored
In preparation of adding locking to backlight, make max backlight value (the modulation frequency the PWM duty cycle value must not exceed) internal to intel_panel.c. Have intel_panel_set_backlight() accept a caller defined range for level, and scale input to max backlight value internally. Clean up intel_panel_get_max_backlight() and usage internally. Signed-off-by:
-
- 24 Apr, 2013 6 commits
-
-
Daniel Vetter authored
The LPT PCH only supports 8bpc, so we need to force the pipe bpp to the right value. Reviewed-by:
-
Daniel Vetter authored
Prevents black screens when using 30bpp framebuffers on my HDMI screens here. The DP input on the same screen though reports a 1.4 EDID with the correct 8bpc limit set. v2: Actually check for the right thing! Reviewed-by:
-
Daniel Vetter authored
Our rps code relies on the interrupts being off to prevent re-arming of the work items at inopportune moments. Also drop the redundant cancel_work for the main rps work, disable_gt_powersave already takes care of that. Finally add a WARN_ON to ensure we obey that piece of ordering constraint. Long term I want to lock down the setup/teardown code in a similar way to how we painstakingly check modeset sequence constraints already. v2: Disable polling after hpd handling is shut down - since Egbert's hpd irq storm handling the hotplug work can re-arm the polling handler. Spotted by Jani Nikula. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Jesse Barnes authored
We don't want to write reserved regs here, and may want to do other bits in the future, so split it out. Reported-by:
-
Jesse Barnes authored
Ville noticed this while doing another review; we may as well cancel this work just to make sure we don't try anything fancy after disabling the RPS interfaces. Reported-by:
-
Jesse Barnes authored
On VLV, the Punit doesn't automatically drop the GPU to it's minimum voltage level when entering RC6, so we arm a timer to do it for us from the RPS interrupt handler. It'll generally only fire when we go idle (or if for some reason there's a long delay between RPS interrupts), but won't be re-armed again until the next RPS event, so shouldn't affect power consumption after we go idle and it triggers. v2: use delayed work instead of timer + work queue combo (Ville) v3: fix up delayed work cancel (must be outside lock) (Daniel) fix up delayed work handling func for delayed work (Jesse) v4: cancel delayed work before RPS shutdown (Jani) pass delay not absolute time to mod_delayed_work (Jani) Signed-off-by:
-
- 23 Apr, 2013 4 commits
-
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Let's introduce one more of those orthogonal feature macros. This should hopefully make the code more readable and make things easier for new platform enabling. This time, HAS_FPGA_DBG_UNCLAIMED() is true for platforms that have bit 31 of FPGA_DBG able to signal unclaimed writes. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
