- 28 Mar, 2013 3 commits
-
-
Daniel Vetter authored
The old code only handled either 6bpc or 8bpc. Since it's easy to do, reorganize the code to be a bit more generic so that it can also handle 10bpc and 12bpc. Note that we still start with 8bpc, so there's no functional change. Also, since we no don't need to compute the 6BPC flag in the mode_valid callback, we can consolidate things a bit. That requires though that the link bw computation is moved up in the compute_config callback. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
The procedure has now 3 steps: 1. Compute the bpp that the plane will output, this is done in pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also, this function clamps the pipe_bpp to whatever limit the EDID of any connected output specifies. 2. Adjust the pipe_bpp in the encoder and crtc functions, according to whatever constraints there are. 3. Decide whether to use dither by comparing the stored plane bpp with computed pipe_bpp. There are a few slight functional changes in this patch: - LVDS connector are now also going through the EDID clamping. But in a 2nd change we now unconditionally force the lvds bpc value - this shouldn't matter in reality when the panel setup is consistent, but better safe than sorry. - HDMI now forces the pipe_bpp to the selected value - I think that's what we actually want, since otherwise at least the pixelclock computations are wrong (I'm not sure whether the port would accept e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick the next higher bpc value, since otherwise there's no way to make use of the 12 bpc mode (since the next patch will remove the 12bpc plane format, it doesn't exist). Both of these changes are due to the removal of the pipe_bpp = min(display_bpp, plane_bpp); statement. Another slight change is the reworking of the dp bpc code: - For the mode_valid callback it's sufficient to only check whether the mode would fit at the lowest bpc. - The bandwidth computation code is a bit restructured: It now walks all available bpp values in an outer loop and the codeblock that computes derived values (once a good configuration is found) has been moved out of the for loop maze. This is prep work to allow us to successively fall back on bpc values, and also correctly support bpc values != 8 or 6. v2: Rebased on top of Paulo Zanoni's little refactoring to use more drm dp helper functions. v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color range work. v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed. v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked in a later patch though again. v6: Fix spelling in a comment. v7: Debug output improvements for the bpp computation. v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different things! v9: Reinstate the fix to properly ignore the firmware edp bpp ... this was lost in a rebase. v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have that. Still unsure whether this is the way to go, but at least 6bpc for a 8bpc hdmi output seems to work. v11: And g4x/vlv also lack 12bpc hdmi support, so only support high depth on DP. Adjust the code. v12: Rebased. v13: Split out the introduction of pipe_config->dither|pipe_bpp, as requested from Jesse Barnes. v14: Split out the special 6BPC handling for DP, as requested by Jesse Barnes. Reviewed-by:
-
Daniel Vetter authored
We want to compute this earlier. To avoid a big complicated patch, this patch here just does the big search&replace and still calls the old functions at the same places. Reviewed-by:
-
- 27 Mar, 2013 18 commits
-
-
Daniel Vetter authored
Now that we have a useful struct for this, let's use it. Some neat pointer-chasing required, but it's all there already. v2: Rebased on top of the added Haswell limited color range support. Reviewed-by:
-
Daniel Vetter authored
This is used way too often in the enable/disable paths. And will be even more useful in the future. Note that correct semantics of this change highly depend upon correct updating of intel_crtc->config: Like with all other modeset state, we need to call ->disable with the old config, but ->mode_set and ->enable with the new config. v2: Do not yet use the flag in the ->disable callbacks - atm we don't yet have support for the information stored in the pipe_config in the hw state readout code, so this will be wrong at boot-up/resume. v3: Rebased on top of the hdmi/dp ddi encoder merging. v4: Fixup stupid rebase error which lead to a NULL vfunc deref. v5: On haswell the VGA port is on the PCH! v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing parameter name in a function declaration. v7: Don't forget to git add ... Reviewed-by:
-
Daniel Vetter authored
Completely unused by now. Separate patch in case I've missed a place somewhere which dereferences the helper vtable but actually shouldn't do so. v2: Resolve rebase conflict with Egbert Eich's hpd infrastructure rework. Reviewed-by:
-
Daniel Vetter authored
Used by SDVO (and hopefully, eventually HDMI, if we ever get around to fixing up the low dotclock CEA modes ...). This required adding a new encoder->mode_set callback to be able to pass around the intel_crtc_config. Reviewed-by:
-
Daniel Vetter authored
Only used by the lvds encoder. Note that we shouldn't do the same simple conversion with the FORCE_6BPC flag, since that's much better handled by moving all the pipe_bpc computation around. This requires that we pass the pipe config around to encoders, so that they can set special attributes and set constraints. To do so introduce a new ->compute_config encoder callback, which is called in stead of the drm crtc helper's ->mode_fixup. To avoid massive churn all over the codebase we don't want to convert all existing ->mode_fixup functions. Instead I've opted to convert them on an as-needed basis (mostly to cut down on rebase conflicts and to have more freedom to experiment around while developing the patches). Reviewed-by:
-
Daniel Vetter authored
To make decent modeset state checking possible (e.g. for the check mode with atomic modesetting) we want to have the full pipe configuration and state checks done before we touch the hw. To ensure that all the little bits&pieces that are now moved to the pipe_config handle this correctly, move its computation to the right spot now, before we touch the hw in the disable_pipes step. Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Daniel Vetter authored
Currently only containing the requested and the adjusted mode. And only crtc callbacks are converted somewhat to it, encoders will be done on a as-needed basis (simply too much churn in one patch otherwise). Future patches will add tons more useful stuff to this struct, starting with the very simple. v2: Store the pipe_config in the intel_crtc, so that the ->mode-set, ->enable and also ->disable have easy access to it. v3: Store the pipe config in the right crtc ... v4: Rebased. v5: Fixup an OOPS when trying to kfree an ERR_PTR. v6: Used drm_moode_copy and some other small cleanups as suggested by Ville Syrjälä. v7: drm_mode_copy preserves the mode id of the destination, so no need to clear it again (Ville). v8: Break a long line spotted by Paulo. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
The backlight device .get_brightness callback is supposed to return the actual brightness by querying the hardware, not the cached value. See Documentation/ABI/stable/sysfs-class-backlight. The callback is there to support the actual_brightness sysfs file. With the backlight_level and backlight device brightness now in sync, one can reliably get the cached value through the brightness sysfs file. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
A single point of truth would be better than two, but achieving that would require more abstractions for CONFIG_BACKLIGHT_CLASS_DEVICE=n with not a whole lot of real benefits. Take the short route and just keep the backlight levels in sync. In particular, update backlight device brightness on opregion brightness changes. Signed-off-by:
-
Daniel Vetter authored
Now with Egbert Eich's hpd infrastructure rework merged this is dead simple. And we need this to make output detection work on SDVO - with the cleaned-up drm polling helpers outputs which claim to have hpd support are no longer polled. Now SDVO claims to do that, but it's not actually wired up. So just do it. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
When disabling a sprite, wait for the sprite to stop fetching data from memory before unpinning the fb. Signed-off-by:
-
Daniel Vetter authored
Noticed while reviewing the hotplug irq setup code. Just looks better. Reviewed-by:
-
Imre Deak authored
Since for_each_sg_page supports already memory w/o backing pages we can revert the corresponding workaround. This reverts commit 5bd4687e. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Imre Deak authored
The i915 driver uses sg lists for memory without backing 'struct page' pages, similarly to other IO memory regions, setting only the DMA address for these. It does this, so that it can program the HW MMU tables in a uniform way both for sg lists with and without backing pages. Without a valid page pointer we can't call nth_page to get the current page in __sg_page_iter_next, so add a helper that relevant users can call separately. Also add a helper to get the DMA address of the current page (idea from Daniel). Convert all places in i915, to use the new API. Signed-off-by:
-
Chris Wilson authored
From the w/a database: 'To prevent false VT-d type 6 error: The primary display plane must be 256KiB aligned, and require an extra 128 PTEs of padding afterward; The sprites planes must be 128KiB aligned, and require an extra 64 PTEs of padding afterward; The cursors must be 64KiB aligned, and require an extra 2 PTEs of padding afterward.' As we use the same function to pin the primary and sprite planes, we can simply use the more strict requirements for scanouts for both. Instead of using explicit padding PTEs following the scanout objects, we should be able to use the scratch page that is always mapped into the unused PTEs to avoid the VT-d error. References: https://bugs.freedesktop.org/show_bug.cgi?id=59626 References: https://bugs.freedesktop.org/show_bug.cgi?id=59627 References: https://bugs.freedesktop.org/show_bug.cgi?id=59631Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Egbert Eich authored
Now since we have replaced the bits to show interest in hotplug IRQs we can go and nuke the 'hotplug_supported_mask'. Signed-off-by:
Egbert Eich <eich@suse.de> Acked-by:
-
Egbert Eich authored
After "Convert HPD interrupts to make use of HPD pin assignment in encoders." This function is now basically the same as i915_hpd_irq_setup(). Consolidating both functions in one requires one more check for I915_HAS_HOTPLUG(dev) in the i965 code path and one more check for IS_G4X(dev) in the i915 code path. These are considered harmless. Signed-off-by:
-
Daniel Vetter authored
This fixes a regression introduced in commit e5868a31 Author: Egbert Eich <eich@suse.de> Date: Thu Feb 28 04:17:12 2013 -0500 DRM/i915: Convert HPD interrupts to make use of HPD pin assignment in encode Due to the irq setup rework in 3.9, see commit 20afbda2 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Dec 11 14:05:07 2012 +0100 drm/i915: Fixup hpd irq register setup ordering Egbert Eich's hpd rework blows up on pch-split platforms - it walks the encoder list before that has been set up completely. The new init sequence is: 1. irq enabling 2. modeset init 3. hpd setup We need to move around the ibx setup a bit to fix this. Ville Syrjälä pointed out in his review that we can't touch SDEIER after the interrupt handler is set up, since that'll race with Paulo Zanoni's PCH interrupt race fix: commit 44498aea Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 22 17:05:28 2013 -0300 drm/i915: also disable south interrupts when handling them We fix that by unconditionally enabling all interrupts in SDEIER, but masking them as-needed in SDEIMR. Since only the single-threaded setup/teardown (or suspend/resume) code touches that, no further locking is required. While at it also simplify the mask handling - we start out with all interrupts cleared in the postinstall hook, and never enable a hpd interrupt before hpd_irq_setup is called. And finally, for consistency rename the ibx hpd setup function to ibx_hpd_irq_setup. v2: Fix race around SDEIER writes (Ville). v3: Remove the superflous posting read for SDEIER, spotted by Ville. Ville also wondered whether we shouldn't clear SDEIIR, since now SDE interrupts are enabled before we have an irq handler installed. But the master interrupt control bit in DEIER is still cleared, so we should be fine. Cc: Egbert Eich <eich@suse.de> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62798Reviewed-by:
-
- 26 Mar, 2013 11 commits
-
-
Egbert Eich authored
This allows to enable HPD interrupts for individual pins to only receive hotplug events from lines which are connected and working. v2: Restructured initailization of const arrays following a suggstion by Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Egbert Eich authored
To clean up hotplug support we add a new enum to intel_encoder: enum hpd_pin. It allows the encoder to request a hpd line but leave the details which IRQ is responsible on which chipset generation to i915_irq.c. This way requesting hotplug support will become really simple on the encoder/connector level. Signed-off-by:
-
Egbert Eich authored
It's basically identical to i915_hpd_irq_setup(). Signed-off-by:
-
Jesse Barnes authored
This will poke userspace into probing for configuration changes that may have occurred across suspend/resume. Signed-off-by:
-
Jesse Barnes authored
With the other bits in place, we can do this safely. v2: disable backlight on suspend to prevent premature enablement on resume v3: disable CRTCs on suspend to allow RTD3 (Kristen) Signed-off-by:
-
Jesse Barnes authored
Needed for VT switchless resume. v2: cursor state is now handled correctly in crtc_enable (Daniel) Signed-off-by:
-
Jesse Barnes authored
To be used to restore sprite state on resume. v2: move sprite tracking bits up so we don't track modified sprite state v3: use src_x/y in sprite suspend/resume code (Ville) Signed-off-by:
-
Jesse Barnes authored
Rather than building a config which may or may not work, let the driver build an initial fb config. This allows the driver to use the BIOS boot configuration for example, displaying kernel messages and the initial fb console on the same outputs the BIOS lit up at boot time. If that fails, the driver can still fall back the same way as the core. Signed-off-by:
Dave Airlie <airlied@gmail.com> Reviewed-by:
-
Chris Wilson authored
Wrap a preallocated region of stolen memory within an ordinary GEM object, for example the BIOS framebuffer. Signed-off-by:
-
Chris Wilson authored
There is a minute window for a race between put-fence removing the fence and for a new transaction by an external party on the GTT mmap. That is we must zap the mmap prior to removing the fence and not afterwards. Fixes regression from commit 61050808 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 17 15:31:31 2012 +0100 drm/i915: Refactor put_fence() to use the common fence writing routine v2: Remember the fence to remove with a local variable (gcc) Signed-off-by:
-
Rodrigo Vivi authored
According to HSW PM programming guide, frequency bits starts at 24 instead of 25. v2: Paulo Zanoni noticed that only frequency bits can be set at GEN6_RPNSWREQ. All others are read only. CC: Ben Widawsky <ben@bwidawsk.net> CC: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
- 25 Mar, 2013 2 commits
-
-
Damien Lespiau authored
If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect port, we are currently trying to read PORT_CLK_SEL(port) with an uninitialized value. Handle that case by returning PORT_CLK_SEL_NONE and warning about it. v2: Move the warning inside intel_ddi_get_crtc_pll (Paulo Zanoni) Signed-off-by:
-
Ben Widawsky authored
HSW doesn't overclock the same way as IVB or SNB. I do not know about VLV, so I've kept that off as well. I'm still working on getting the doc updates to explain how we overclock on Haswell. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 23 Mar, 2013 6 commits
-
-
Paulo Zanoni authored
So don't read it when capturing the error state. This solves "unclaimed register" messages on Haswell when we have a GPU hang. V2: Check for HAS_PCH_SPLIT instead of Gen5+ because VLV still has this register. Signed-off-by:
-
Paulo Zanoni authored
So don't read it when capturing the error state. This solves some "unclaimed register" messages on Haswell when we hang the GPU. Signed-off-by:
-
Paulo Zanoni authored
The first version of commit "drm/i915: there's no DSPADDR register on Haswell" added 2 "!IS_HASWELL" checks. When reviewing the patch, Ben suggested to make these checks more future-proof, so when Daniel applied the patch he fixed the first check but not the second. This commit makes the second check also "future-proof". Signed-off-by:
-
Damien Lespiau authored
The port number should always be correctly set. Do the same thing as the switch above and use BUG() to signal that branch is not supposed to be taken. Signed-off-by:
-
Damien Lespiau authored
We are really talking about the transcoder function here and the disable version uses trancoder in its name already, so let's try to be consistent. Signed-off-by:
-
Damien Lespiau authored
In the case where the hardware has been wrongly programmed and the EDP TRANS_DDI_FUNC_CTL register has a bogus value in its EDP Input field, we were using the pipe variable uninitialized. In this case, shutdown the transcoder. It will be programmed correctly the next time we try to enabled eDP. Note from Paulo's review: Wrong modeset sequence can easily lead to frozen machines hence the disable_ddi call might be risky. But since things are awry already, doesn't matter too much. Signed-off-by:
-
