- 02 Apr, 2013 9 commits
-
-
Jesse Barnes authored
PPS register offsets have changed in Valleyview. v2: don't clobber port select bits on VLV when fixing up PPS timings don't bother with G4x PPS regs (Jani) Signed-off-by:Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Needed to handle pre/post enable/disable paths on VLV and avoid a few fields that are marked reserved on VLV. v2: don't set color range or DP PLL fields (Jani) Signed-off-by:
-
Jesse Barnes authored
Need to make sure sprites are disabled before shutting off a pipe. Signed-off-by:
-
Jesse Barnes authored
No constant alpha yet though, that needs a new ioctl and/or property to get/set. v2: use drm_plane_format_cpp (Ville) fix up vlv_disable_plane, remove IVB bits (Ville) remove error path rework (Ville) fix component order confusion (Ville) clean up platform init (Ville) use compute_offset_xtiled (Ville) v3: fix up more format confusion (Ville) update to new page offset function (Ville) v4: remove incorrect formats from framebuffer_init (Ville) Reviewed-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jesse Barnes authored
If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by:
-
Jesse Barnes authored
If we couldn't find a pipe we shouldn't return true. This might be even better as a WARN though, since it should be impossible to have the port enabled without a pipe selected. Signed-off-by:
-
Chris Wilson authored
Modifying the clock sources (via the DREF control on the PCH) is a slow multi-stage process as we need to let the clocks stabilise between each stage. If we are not actually changing the clock sources, then we can return early. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> [danvet: Appease checkpatch by deleting a space after a ~] Signed-off-by:
-
Jani Nikula authored
No functional changes. Signed-off-by:
-
Jesse Barnes authored
Earlier code would leave both bits set, so any reset after the first would only reset media. Signed-off-by:
-
- 28 Mar, 2013 10 commits
-
-
Daniel Vetter authored
Ville pointed out that my assumption that no unsupported pixel format can get past the pipe config computation stage to the platform update_plane callbacks is wrong. The reason is that this function still checks the old fb->depth value instead of the new pixel_format. While checking with all the other places that use this I've noticed that intel_framebuffer_init already has all the platform checks we need, so replace those checks with a WARN_ON. Since fb->depth isn't set for YUV pixel formats and since we already can't create an fb with an rgb layout not support on the running platform I /think/ this patch doesn't fix any bug. But it surely looks better! v2: BGR formats are also only gen4+, so add the corresponding WARN_ON, too (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
We've mostly switched over to the new more flexible schema, but there's one check left in the modeset code. Motivated by a question from Ville whether there's really no way an unsupported pixel_format can escape into our platform update_plane callbacks. v2: Ville noticed that the fb->depth check is redudant when we already check fb->pixel_format. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
As Thomas Gleixner spotted, it's rather horrible racy: - We can miss almost a full tick, so need to compensate by 1 jiffy. - We need to re-check the condition when having timed-out, since a the last check could have been before the timeout expired. E.g. when we've been preempted or a long irq happened. Cc: Thomas Gleixner <tglx@linutronix.de> Reported-by:
Jack Winter <jbh@alchemy.lu> Cc: Jack Winter <jbh@alchemy.lu> Reviewed-by:
-
Daniel Vetter authored
Since commit bcf9dcc1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Jul 15 09:42:38 2012 +0100 drm/i915: Workaround hang with BSD and forcewake on SandyBridge and commit 0cc2764c Author: Ben Widawsky <ben@bwidawsk.net> Date: Sat Sep 1 22:59:48 2012 -0700 drm/i915: use cpu_relax() in wait_for_atomic these two macros are essentially the same, so unify them. We keep the _us version since it's a nice documentation for smaller timeouts. v2: Fixup time unit conversion, _wait_for takes ms (Ville). Cc: Jack Winter <jbh@alchemy.lu> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Paulo Zanoni authored
- It's a static function - I just added a few more users to it - Its sister ironlake_enable_display_irq is not marked as inline - The compiler will still inline if it thinks it should do Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniel Vetter authored
- gen4 and earlier (save for g4x) only really have a 8bpc pipe, with the possibility to dither to 6bpc using the panel fitter - g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly. - TV/SDVO out are the only connectors available on platforms with a pipe bpp != 8, add code to force the pipe to 8bpc unconditionally. <rant> The dither handling on gmch platforms is one giant disaster. I'm hoping somewhat that vlv enabling will fix this up, but given that the 6bpc handling for edp was simply added with another quick hack, I don't have high hopes ... </rant> v2: Neither vlv nor g4x have 12bpc pipes. Still set pipe_bpp to 12*3, but let the crtc code clamp things down to 10bpc on these platforms. v3: Fix a bpc vs. bpp mixup in the gen4 and earlier pipe_bpp limiter code. v4: Drop the hunk in intel_hdmi.c about g4x/vlv 12bpc, it was wrong. Reviewed-by:
-
Daniel Vetter authored
- There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc float layout, but we don't really support it. - 10bpc is a gen4+ feature, fix up the support for it. - Update_plane should never see a wrong fb bpp value, BUG in the corresponding cases. v2: Rebase on top of Ville's plane pixel layout changes. v3: Actually drop the old gen4 check for 10bpc planes, spotted by Ville Syrjälä. Reviewed-by:
-
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:
-
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:
-
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:
-
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 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:
-
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 3 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:
-
