An error occurred fetching the project authors.
- 25 Jul, 2012 2 commits
-
-
Daniel Vetter authored
Intel hw only has one MUX for encoders, so outputs are either not cloneable or all in the same group of cloneable outputs. This neatly simplifies the code and allows us to ditch some ugly if cascades in the dp and hdmi init code (well, we need these if cascades for other stuff still, but that can be taken care of in follow-up patches). Note that this changes two things: - dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is gen3+, so no problem. Note that the old code had a bug and didn't allow cloning crt with dvo (but only the other way round). - sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't work, but the only reason I've found is that you can't use the panel-fitter (used for lvds upscaling) with anything else. But we don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is a) rather confusing b) mostly as a guideline to implementors (i.e. explicitly stating what is already implicit from the spec, without always going into the details of why). So I think we can ignore this - worst case we'll get a bug report from a user with with sdvo-lvds and sdvo-tmds and have to add that special case back in. Because sdvo lvds is a bit special explain in comments why sdvo LVDS outputs can be cloned, but native LVDS and eDP can't be cloned - we use the panel fitter for the later, but not for sdvo. Note that this also uncoditionally initializes the panel_vdd work used by eDP. Trying to be clever doesn't buy us anything (but strange bugs) and this way we can kill the is_edp check. v2: Incorporate review from Paulo - Add in a missing space. - Pimp comment message to address his concerns. Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Shobhit Kumar authored
Move the DP structure to shared location so that it can be used from within the ddi module. Changes from Paulo: - Move less code to intel_drv.h - Remove #include statement - Replace a tab with a space in train_set Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
- 20 Jul, 2012 2 commits
-
-
Daniel Vetter authored
We have way too much lying hardware to rely on a simple "does someone answer on the ddc i2c address?" check. And now it's unused, so just kill it. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
-
Eugeni Dodonov authored
This initializes power wells within the modeset_init_hw routine. Testing has shown that this works for both driver load time and for suspend-resume code paths. Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
- 05 Jul, 2012 3 commits
-
-
Daniel Vetter authored
To avoid recomputing the display framebuffer offset on gen2/3 pageflips. This is also prep work to do similar trickery on gen4+ Also: - kill "Start", such upper-case remnants from the ddx must surely die. - rename "Offset" to linear_offset, to make it clearer that on gen4+ this is only used by the hw for linear buffers, for tiled buffers it uses the TILEOFF register. - call DSAPADDR DSPLINOFF on gen4+ for the same reason (and because the documentation really renamed the register). Reviewed-by:
-
Daniel Vetter authored
While creating the new enable/disable_gt_powersave functions in commit 8090c6b9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jun 24 16:42:32 2012 +0200 drm/i915: wrap up gt powersave enabling functions I've botched up the handling of ironlake_disable_rc6. Fix this up by calling it at the right place. Note though that ironlake_disable_rc6 does a bit more than just disabling rc6 - it also tears down all the allocated context objects. Hence we need to move intel_teardown_rc6 out and directly call it from intel_modeset_cleanup. Also properly mark ironlake_enable_rc6 as static and kill the un-used declaration in i915_drv.h. Note: In review a question popped out why disable_rc6 also tears down the backing object and why we should move that out - it's simply for consistency with gen6+ rps code, which does it that way. Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-Off-by:
-
Eugeni Dodonov authored
This commit moves force wake support routines into intel_pm modules, and exports the gen6_gt_check_fifodbg routine (used in I915_READ). Signed-off-by:
-
- 25 Jun, 2012 1 commit
-
-
Daniel Vetter authored
... instead of calling each one for each generation indiviudally. Notice that we've already managed to be inconsistent, the resume path is missing an IS_VLV check. As a nice benefit we can mark all the platform specific enable/disable functions as static and hide them in intel_pm.c Reviewed-by:
-
- 13 Jun, 2012 1 commit
-
-
Chris Wilson authored
As we switch on/off the primary plane if it is completely obscured by an overlapping video sprite, we also nee to make sure that we update the FBC configuration at the same time. v2: Not all crtcs are intel_crtcs, as spotted by Daniel. v3: Boot testing rules. References: https://bugs.freedesktop.org/show_bug.cgi?id=50238Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
- 12 Jun, 2012 1 commit
-
-
Daniel Vetter authored
On gen4+ we have a bitfield to specify from which pipe the backlight controller should take it's clock. For PCH split platforms we've already set these up, but only at initialization time. And without taking into account the 3rd pipe added with ivb. For gen4, we've completely ignored these. Although we do restrict lvds to the 2nd pipe, so this is only a problem on machines where we boot up with the lvds on the first pipe. So restructure the code to enable the backlight on the right pipe at modeset time. v2: For odd reasons panel_enable_backlight gets called twice in a modeset, so we can't WARN_ON in there if the backlight controller is switched on already. v3: backlight enable can also be called through dpms on, so the check in there is legit. Update the comment to reflect that. Tested-By:
Kamal Mostafa <kamal@canonical.com> Bugzilla: https://bugs.launchpad.net/bugs/954661 Cc: Carsten Emde <C.Emde@osadl.org> Reviewed-by:
-
- 04 Jun, 2012 2 commits
-
-
Daniel Vetter authored
We should only frob adjusted_mode. This is in preparation of a massive patch by Laurent Pinchart to make the mode argument const. After the previous two prep patches the only thing left is to clean up things a bit. I've opted to pass in an adjust_mode param to dp_adjust_dithering because that way we can be sure to avoid duplicating this logic between mode_valid and mode_fixup - which was the cause behind a dp link bw calculation bug in the past. Also mark the mode argument of pch_panel_fitting const. v2: Split up the mode->clock => adjusted_mode->clock change, as suggested by Chris Wilson. Reported-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
... instead of abusing mode->clock by storing it in there - we shouldn't touch that one at all. This patch is the first prep step to constify the mode argument of the intel_dp_mode_fixup function. The next patch will stop us from modifying mode->clock. Reviewed-by:
-
- 30 May, 2012 1 commit
-
-
Paulo Zanoni authored
We need a function that is able to fully 'set' the state of the DIP registers to a known state. Currently, we have the write_infoframe function that is called twice: once for AVI and once for SPD. The problem is that write_infoframe tries to keep the state of the DIP register as it is, changing only the minimum necessary bits. The second problem is that write_infoframe does twice (once for each time it is called) some work that should be done only once (like waiting for vblank and setting the port). If we add even more DIPs, it will do even more repeated work. This patch only adds the infrastructure keeping the code behavior the same as before. v2: add static keywords Signed-off-by:
-
- 20 May, 2012 1 commit
-
-
Daniel Vetter authored
At least the worst offenders: - SDVO specifies that the encoder should compute the ecc. Testing also shows that we must not send the ecc field, so copy the dip_infoframe struct to a temporay place and avoid the ecc field. This way the avi infoframe is exactly 17 bytes long, which agrees with what the spec mandates as a minimal storage capacity (with the ecc field it would be 18 bytes). - Only 17 when sending the avi infoframe. The SDVO spec explicitly says that sending more data than what the device announces results in undefined behaviour. - Add __attribute__((packed)) to the avi and spd infoframes, for otherwise they're wrongly aligned. Noticed because the avi infoframe ended up being 18 bytes large instead of 17. We haven't noticed this yet because we don't use the uint16_t fields yet (which are the only ones that would be wrongly aligned). This regression has been introduce by 3c17fe4b is the first bad commit commit 3c17fe4b Author: David Härdeman <david@hardeman.nu> Date: Fri Sep 24 21:44:32 2010 +0200 i915: enable AVI infoframe for intel_hdmi.c [v4] Patch tested on my g33 with a sdvo hdmi adaptor. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI) Reviewed-by:
-
- 19 May, 2012 6 commits
-
-
Eugeni Dodonov authored
On Haswell, we need to properly train the DDI buffers prior to enabling HDMI, and enable the required clocks with correct dividers for the desired frequency. Also, we cannot simple reuse HDMI routines from previous generations of GPU, as most of HDMI-specific stuff is being done via the DDI port programming instead of HDMI-specific registers. This commit take advantage of the WR PLL clock table which is in a separate (previous) commit to select the right divisors for each mode. Signed-off-by:
-
Eugeni Dodonov authored
Move intel_hdmi data structure and support functions to a shared location, to allow their usage from intel_ddi module. Reviewed-by:
-
Eugeni Dodonov authored
Digital port detection on Haswell is indicated by the presence of a bit in DDI_BUF_CTL for port A, and by a different register for ports B, C and D. So we check for those bits during the initialization time and let the hdmi function know about those. Note that this bit does not indicates whether the output is DP or HDMI. However, the DDI buffers can be programmed in a way that is shared between DP/HDMI and FDI/HDMI except for PORT E. So for now, we detect those digital outputs as being HDMI, but proper DP support is still pending. Note that DDI A can only drive eDP, so we do not handle it here for hdmi initialization. v2: simplify Haswell handling logic v3: use generic function for handling digital outputs. Signed-off-by:
-
Eugeni Dodonov authored
The line time can be programmed according to the number of horizontal pixels vs effective pixel rate ratio. v2: improve comment as per Chris Wilson suggestion v3: incorporate latest changes in specs. v4: move into wm update routine, also mention that the same routine can program IPS watermarks. We do not have their enablement code yet, nor handle the required clock settings at the moment, so this patch won't program those values for now. Signed-off-by:
-
Eugeni Dodonov authored
Starting with Haswell, DDI ports can work in FDI mode to support connectivity with the outputs located on the PCH. This commit adds support for such connections in the intel_ddi module, and provides Haswell-specific functionality to make it work. v2: simplify the commit as per Daniel Vetter suggestion. Signed-off-by:
-
Eugeni Dodonov authored
DDI is introduced starting with Haswell GPU generation. So to simplify its management in the future, we also add intel_ddi.c to hold all the DDI-related items. Buffer translations for DDI links must be initialized prior to enablement. For FDI and DP, first 9 pairs of values are used to select the connection parameters. HDMI uses the last pair of values and ignores the first 9 pairs. So we program HDMI values in both cases, which allows HDMI to work over both FDI and DP-friendly buffers. Reviewed-by:
-
- 03 May, 2012 6 commits
-
-
Chris Wilson authored
Every time we use the device after a period of idleness, check that the power management setup is still sane. This is to workaround a bug whereby it seems that we begin suppressing power management interrupts, preventing SandyBridge+ from going into turbo mode. This patch does have a side-effect. It removes the mark-busy for just moving the cursor - we don't want to increase the render clock just for the sprite, though we may want to bump the display frequency. I'd argue that we do not, and certainly don't want to take the struct_mutex here due to the large latencies that introduces. References: https://bugs.freedesktop.org/show_bug.cgi?id=44006Signed-off-by:
-
Paulo Zanoni authored
They require an AVI InfoFrame with a proper Pixel Repetition field. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Paulo Zanoni authored
To keep the consistency with the other fields. Signed-off-by:
-
Daniel Vetter authored
They're now in intel_pm.c, so group them a bit better. Acked-by:
-
Daniel Vetter authored
We now have a nice home for power management code, so let's use it! v2: Resolve conflict agains "Only enable IPS polling for gen5" Acked-by:
-
Jesse Barnes authored
PCH PLLs aren't required for outputs on the CPU, so we shouldn't just treat them as part of the pipe. So split the code out and manage PCH PLLs separately, allocating them when needed or trying to re-use existing PCH PLL setups when the timings match. v2: add num_pch_pll field to dev_priv (Daniel) don't NULL the pch_pll pointer in disable or DPMS will fail (Jesse) put register offsets in pll struct (Chris) v3: Decouple enable/disable of PLLs from get/put. v4: Track temporary PLL disabling during modeset v5: Tidy PLL initialisation by only checking for num_pch_pll == 0 (Eugeni) v6: Avoid mishandling allocation failure by embedding the small array of PLLs into the device struct Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44309 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (up to v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v3+) Reviewed-by:
-
- 18 Apr, 2012 5 commits
-
-
Eugeni Dodonov authored
This adds intel_pm routine for generic power-related infrastructure initialization. v2: now that all the platform-specific stuff is initialized in one place, we can also add back the static definitions to platform-specific functions which we abstract now. Acked-by:
Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
-
Eugeni Dodonov authored
This moves the clock gating-related functions into intel_pm module. Also, please note that we do change the function type from static to non-static in this patch for the move, to prevent breaking bisecting with non-working intermediate commit. Those are returned back to static form in the following patch which setups a generic PM initialization function, which was split into a different one to simplify review. v2: rebase on top of latest drm-intel-next-queued to incorporate all the changes that went there meanwhile. Acked-by:
-
Eugeni Dodonov authored
This moves DRPS, RPS and RC6-related functionality into intel_pm module. It also removes the linux/cpufreq.h include from intel_display, as its only user was the GPU turbo-related functionality in Gen6+ code path. v2: rebase on top of latest drm-intel-next-queued adding the bits that shifted around since the last patch. Acked-by:
-
Eugeni Dodonov authored
Move watermarks and helper functions (such as cxsr and fifo buffers) into intel_pm module. Signed-off-by:
-
Eugeni Dodonov authored
This commit moves Frame Buffer Compression-related operations and support functions into the new intel_pm module. Signed-off-by:
-
- 16 Apr, 2012 2 commits
-
-
Chris Wilson authored
Rather than export every single architecture specific update_wm, just export the wrapper around the display vtable. Signed-off-by:
-
Daniel Vetter authored
This regression has been introduced in commit ca9bfa7e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 14:49:20 2012 +0100 drm/i915: fixup interlaced vertical timings confusion, part 1 Unfortunately that commit failed to take into account that the lvds code does some special adjustements to the crtc timings for upscaling an centering. Fix this by explicitly computing crtc timings in the lvds mode fixup function and setting a special flag in mode->private_flags if the crtc timings have been adjusted. v2: Add a comment to explain the new mode driver private flag, suggested by Eugeni Dodonov. v3: Kill the confusing and now redundant set_crtcinfo call in intel_fixed_panel_mode, noticed by Chris Wilson. Reported-and-Tested-by:
Hans de Bruin <jmdebruin@xmsnet.nl> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43071Reviewed-by:
-
- 29 Mar, 2012 1 commit
-
-
Dave Airlie authored
Looking at hibernate overwriting I though it looked like a cursor, so I tracked down this missing piece to stop the cursor blink timer. I've no idea if this is sufficient to fix the hibernate problems people are seeing, but please test it. Both radeon and nouveau have done this for a long time. I've run this personally all night hib/resume cycles with no fails. Reviewed-by:
Keith Packard <keithp@keithp.com> Reported-by:
Petr Tesarik <kernel@tesarici.cz> Reported-by:
Stanislaw Gruszka <sgruszka@redhat.com> Reported-by: Lots of misc segfaults after hibernate across the world. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=37142Tested-by:
Dave Airlie <airlied@redhat.com> Tested-by:
Bojan Smojver <bojan@rexursive.com> Tested-by:
Andreas Hartmann <andihartmann@01019freenet.de> Cc: stable@vger.kernel.org Signed-off-by:
-
- 28 Mar, 2012 1 commit
-
-
Jesse Barnes authored
ValleyView puts some display related registers like the PLL controls and dividers behind the DPIO bus. Add simple indirect register access routines to get to those registers. v2: move new wait_for macro to intel_drv.h (Ben) fix DPIO_PKT double write (Ben) add debugfs file Reviewed-by:
-
- 24 Mar, 2012 1 commit
-
-
Daniel Vetter authored
With valleyview we'll have these at yet another address, so keeping track of this with an ever-growing list of registers will get ugly. This way intel_sdvo.c is fully independent of the base address of the output ports display register blocks. While at it, do 2 closely related cleanups: - use SDVO_NAME some more - change the sdvo_reg variables to uint32_t like other registers. Reviewed-by:
-
- 29 Jan, 2012 1 commit
-
-
Chris Wilson authored
In order to correctly account for reserving space in the GTT and fences for a batch buffer, we need to independently track whether the fence is pinned due to a fenced GPU access in the batch or whether the buffer is pinned in the aperture. Currently we count the fenced as pinned if the buffer has already been seen in the execbuffer. This leads to a false accounting of available fence registers, causing frequent mass evictions. Worse, if coupled with the change to make i915_gem_object_get_fence() report EDADLK upon fence starvation, the batchbuffer can fail with only one fence required... Fixes intel-gpu-tools/tests/gem_fenced_exec_thrash Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38735Signed-off-by:
Paul Neumann <paul104x@yahoo.de> [danvet: Resolve the functional conflict with Jesse Barnes sprite patches, acked by Chris Wilson on irc.] Signed-off-by:
-
- 06 Jan, 2012 1 commit
-
-
Dave Airlie authored
So we have a few places where the drm drivers would like to sleep to be nice to the system, mainly in the modesetting paths, but we also have two cases were atomic modesetting must take place, panic writing and kernel debugger. So provide a central inline to determine if a sleep or delay should be used and use this in the intel and radeon drivers. v2: drop intel_drv.h MSLEEP macro, nobody uses it. Based on patch from Michel Dänzer <michel.daenzer@amd.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43941Reviewed-by:
-
- 03 Jan, 2012 2 commits
-
-
Jesse Barnes authored
Add new ioctls for getting and setting the current destination color key. This allows for simple overlay display control by matching a color key value in the primary plane before blending the overlay on top. v2: remove unnecessary mutex acquire/release around reg accesses v3: add support for full color key management v4: fix copy & paste bug in snb_get_colorkey don't bother checking min/max values against docs as the docs are likely wrong (how could we handle 10bpc surface formats?) Reviewed-by: -
Jesse Barnes authored
To save power when the sprite is full screen, we can disable the primary plane on the same pipe. Track the sprite status and enable/disable the primary opportunistically. v2: remove primary plane enable/disable hooks; they're identical Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
