summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: gen2 has no tv out supportDaniel Vetter2013-03-031-5/+1Star
| | | | | | | So ditch that if clause from the i8xx pll update code. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipeRodrigo Vivi2013-03-032-14/+17
| | | | | | | | | | | | | | While old platforms had 3 transcoders and 3 pipes (1:1), HSW has 4 transcoders and 3 pipes. These regs were being used only by HDMI code where pipe is always the same thing as cpu_transcoder. This patch allow us to use them for DP, specially for TRANSCODER_EDP. v2: Adding HSW_TVIDEO_DIP_VSC_DATA to transmit vsc to eDP. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Kill pipestat[] cacheVille Syrjälä2013-02-212-25/+17Star
| | | | | | | | | Caching the PIPESTAT enable bits has been deemed pointless. Just read them from the register itself. 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>
* drm/i915: Refactor gen2 to gen4 vblank interrupt handlingVille Syrjälä2013-02-202-54/+72
| | | | | | | | | | | The indentation is getting way too deep. Pull the vblank interupt handling out to separate functions. v2: Keep flip_mask handling in the main irq handler and flatten {i8xx,i915}_handle_vblank() even further. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix races in gen4 page flip interrupt handlingVille Syrjälä2013-02-201-11/+20
| | | | | | | | | | | | | | | | | | | | | Use the gen3 logic for handling page flip interrupts on gen4. Unfortuantely this kills the stall_check since that looks like it can easily trigger too early. With the current logic the stall check would kick in on the first vblank after the flip has been submitted to the ring. If the CS takes longer than that to process the commands in the ring, the stall check will cause the page flip to be complete too early. That doesn't sound like a very good idea. Something better should be deviced if we still need the stall check. For now, mark i915_pageflip_stall_check() as unused. v2: Fix irq enable_mask and add __always_unused (Chris Wilson) References: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1116587 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Eliminate race from gen2/3 page flip interrupt handlingVille Syrjälä2013-02-201-6/+21
| | | | | | | | | | | | | | | | | If the interrupt handler were to process a previous vblank interrupt and the following flip pending interrupt at the same time, the page flip would be completed too soon. To eliminate this race, check the live pending flip status from the ISR register before finishing the page flip. v2: Added a comment explaining the logic (by Chris Wilson) v3: Fix a typo in the comment Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't restore LVDS enable state blindly v2Jesse Barnes2013-02-201-2/+6
| | | | | | | | | | | | We still rely on a few LVDS bits, but restoring the enable bit can cause trouble at this point, so don't. v2: use the right mask to prevent restore (Daniel) conditionalize on KMS support (Denial) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: clear the FPGA_DBG_RM_NOCLAIM bit at driver initPaulo Zanoni2013-02-201-0/+18
| | | | | | | | | | | | Otherwise, if the BIOS did anything wrong, our first I915_{WRITE,READ} will give us "unclaimed register" messages. V2: Even earlier. V3: Move it to intel_early_sanitize_regs. Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58897 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use FPGA_DBG for the "unclaimed register" checksPaulo Zanoni2013-02-202-4/+7
| | | | | | | | | | | | | We plan to treat GEN7_ERR_INT as an interrupt, so use this register for the checks inside I915_WRITE. This way we can have the best of both worlds: the error message with a register address and the V2: Split in 2 patches: one for the macro, one for changing the register, as requested by Ben. V3: Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: create functions for the "unclaimed register" checksPaulo Zanoni2013-02-201-8/+23
| | | | | | | | | | | This avoids polluting i915_write##x and also allows us to reuse code on i915_read##x. v2: Rebase v3: Convert the macros to static functions Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: rename sdvox_reg to hdmi_reg on HDMI contextPaulo Zanoni2013-02-203-41/+39Star
| | | | | | | | | | | | | | | | | | Some (but not all) of the HDMI registers can be used to control sDVO, so those registers have two names. IMHO, when we're talking about HDMI, we really should call the HDMI control register "hdmi_reg" instead of "sdvox_reg", otherwise we'll just confuse people reading our code (we now have platforms with HDMI but without SDVO). So now "struct intel_hdmi" has a member called "hdmi_reg" instead of "sdvox_reg". Also, don't worry: "struct intel_sdvo" still has a member called "sdvo_reg". v2: Rebase (v1 was sent in May 2012). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add aux_ch_ctl_reg to struct intel_dpPaulo Zanoni2013-02-202-45/+22Star
| | | | | | | | This way we can remove some duplicated code and avoid more mistakes and regressions with these registers in the future. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: wait_event_timeout's timeout is in jiffiesPaulo Zanoni2013-02-201-1/+2
| | | | | | | | | | | So use msecs_to_jiffies(10) to make the timeout the same as in the "!has_aux_irq" case. This patch was initially written by Daniel Vetter and posted on pastebin a few weeks ago. I'm just bringing it to the mailing list. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use HAS_DDI on intel_hdmi.c and intel_display.cPaulo Zanoni2013-02-202-7/+7
| | | | | | | | Since basically every code called on these places comes from intel_ddi.c Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove obsolete obj assignment in page flipMika Kuoppala2013-02-201-3/+0Star
| | | | | Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add \n to the end of sysfs attributesJani Nikula2013-02-201-8/+8
| | | | | | | It is customary to end sysfs attributes with a newline. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Finish page flips and update primary planes after a GPU resetVille Syrjälä2013-02-203-0/+42
| | | | | | | | | | | | | | | | | | GPU reset will drop all flips that are still in the ring. So after the reset, call update_plane() for all CRTCs to make sure the primary planes are scanning out from the correct buffer. Also finish all pending flips. That means user space will get its page flip events and won't get stuck waiting for them. v2: Explicitly finish page flips instead of relying on FLIP_DONE interrupt being generated by the base address update. v3: Make two loops over crtcs to avoid deadlocks with the crtc mutex Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup long line complaint from checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Really wait for pending flips when panningVille Syrjälä2013-02-201-3/+2Star
| | | | | | | | | | | | | | | | | | | | | | Since obj->pending_flips was never set, intel_pipe_set_base() never actually waited for pending page flips to complete. We really do want to wait for the pending flips, because otherwise the mmio surface base address update could overtake the flip, and you could end up with an old frame on the screen once the flip really completes. Just call intel_crtc_wait_pending_flips() prior to calling intel_pipe_set_base() instead of calling just intel_finish_fb() from intel_pipe_set_base(). Moving the call outside of intel_pipe_set_base() avoids calling it twice from the full modeset path. v2: Wait for pending flips w/o holding struct_mutex Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove platforms in the preliminary_hw_support descriptionDamien Lespiau2013-02-201-3/+1Star
| | | | | | | | We already managed to get it out of sync (Haswell has been promoted out of this option), so let's remove all mentions to platforms. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement pipe CSC based limited range RGB outputVille Syrjälä2013-02-203-2/+124
| | | | | | | | | | | | | | | | | | | | | | | | | HSW no longer has the PIPECONF bit for limited range RGB output. Instead the pipe CSC unit must be used to perform that task. The CSC pre offset are set to 0, since the incoming data is full [0:255] range RGB, the coefficients are programmed to compress the data into [0:219] range, and then we use either the CSC_MODE black screen offset bit, or the CSC post offsets to shift the data to the correct [16:235] range. Also have to change the confiuration of all planes so that the data is sent through the pipe CSC unit. For simplicity send the plane data through the pipe CSC unit always, and in case full range output is requested, the pipe CSC unit is set up with an identity transform to pass the plane data through unchanged. I've been told by some hardware people that the use of the pipe CSC unit shouldn't result in any measurable increase in power consumption numbers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: inverted brightness quirk for Acer Aspire 4736ZDaniel Vetter2013-02-201-0/+3
| | | | | | | | Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881 Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@intel.com> Tested-by: Jani Monoses <jani@ubuntu.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Print the hw context status is debugfsBen Widawsky2013-02-201-1/+10
| | | | | | | | | | | | | Print out the HW context object information per ring. Even though the existing code only utilizes the render ring, it's simple enough to support future expansion. I had this in a patch somewhere in a rev of the original implementation, but I must have lost it. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: s/context/default context/ bikeshed applied.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remapDaniel Vetter2013-02-201-1/+1
| | | | | | | | | | | Yet another remnant ... this might explain why l3 remapping didn't really work on HSW. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441 Spotted-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+Ville Syrjälä2013-02-202-1/+3
| | | | | | | | | | | | | | | | The bit controlling whether PIPE_CONTROL DW/QW write targets the global GTT or PPGTT moved moved from DW 2 bit 2 to DW 1 bit 24 on IVB. I verified on IVB that the fix is in fact effective. Without the fix none of the scratch writes actually landed in the pipe control page. With the fix the writes show up correctly. v2: move PIPE_CONTROL_GLOBAL_GTT_IVB setup to where other flags are set Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Set i9xx sdvo clock limits according to specificationsPatrik Jakobsson2013-02-201-2/+2
| | | | | | | | | | | | The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9. Since we do all calculations based on them being register values (which are subtracted by 2) we need to specify them accordingly. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359 Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Set i9xx lvds clock limits according to specificationsPatrik Jakobsson2013-02-201-2/+2
| | | | | | | | | | The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9. Since we do all calculations based on them being register values (which are subtracted by 2) we need to specify them accordingly. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Preserve the DDI link reversal configurationDamien Lespiau2013-02-203-3/+18
| | | | | | | | | | | | | | | | | | | | | Similarly to: commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Tue Dec 11 15:18:28 2012 +0000 drm/i915: Preserve the FDI line reversal override bit on CPT DDI port support lane reversal to easy the PCB layouting work. Let's preserve the bit configured by the BIOS (until we find how to correctly retrieve the information from the VBT, but this does sound more fragile then just relying on the BIOS that has, hopefully, been validated already. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Preserve the FDI line reversal override bit on CPTDamien Lespiau2013-02-204-11/+13
| | | | | | | | | | | | | | | | | | | | The FDI link has supported link reversal to make the PCB layout engineer's life easier for quite a while and we have always presered this bit as we programmed FDI_RX_CTL with a read/modify/write sequence. We're trying to take a bit more control over what the BIOS leaves in various register and with the introduction of DDI, started to program FDI_RX_CTL fully. There's a fused bit to indicate DMI link reversal and FDI defaults to mirroring that configuration. We have a bit to override that behaviour that we need to preserve from the BIOS. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add missing \n to UTS_RELEASE in the error_stateJani Nikula2013-02-201-1/+1
| | | | | | | | | | | | | | Amending commit 4518f611ba21ba165ea3714055938a8984a44ff9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jan 23 16:16:35 2013 +0100 drm/i915: dump UTS_RELEASE into the error_state CC: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: Use C8 instead of RGB332 when determining the format from depth/bppVille Syrjälä2013-02-201-1/+1
| | | | | | | | | | | | | | | | Support for real RGB332 is a rarity, most hardware only really support C8. So use C8 instead of RGB332 when determining the format based on depth/bpp. This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not RGB332. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Tested-by: mlsemon35@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: Fill depth/bits_per_pixel for C8 formatVille Syrjälä2013-02-201-0/+1
| | | | | | | | | Set depth/bits_per_pixel to 8 for C8 format. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't clflush gem objects in stolen memoryImre Deak2013-02-201-0/+7
| | | | | | | | | | | | | | | As explained by Chris Wilson gem objects in stolen memory are always coherent with the GPU so we don't need to ever flush the CPU caches for these. This fixes a breakage - at least with the compact sg patches applied - during the resume/restore gtt mappings path, when we tried to clflush an FB object in stolen memory, but since stolen objects don't have backing pages we passed an invalid page pointer to drm_clflush_page(). Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't wait for page flips if there was GPU resetVille Syrjälä2013-02-202-1/+7
| | | | | | | | | | | | | | | | If a GPU reset occurs while a page flip has been submitted to the ring, the flip will never complete once the ring has been reset. The GPU reset can be detected by sampling the reset_counter before the flip is submitted, and then while waiting for the flip, the sampled counter is compared with the current reset_counter value. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Move the reset_counter assignment to an earlier place in common code as discussed on the mailing list.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60140 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Kill obj->pending_flipVille Syrjälä2013-02-202-13/+0Star
| | | | | | | | | The pending flip mask no longer set anywhere, so trying to wait for while it's non-zero is a no-op. Remove it completely. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix a typo in a intel_modeset_stage_output_state() commentDamien Lespiau2013-02-201-1/+1
| | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove bogus mutex_unlock from error-pathDaniel Vetter2013-02-201-1/+0Star
| | | | | | | | | | | | | | This has been lost in the locking rework for intel_alloc_context_page: commit 2c34b850ee1e9f86b41706149d0954eee58757a3 Author: Ben Widawsky <ben@bwidawsk.net> Date: Sat Mar 19 18:14:26 2011 -0700 drm/i915: fix ilk rc6 teardown locking Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Print the pipe control page GTT addressVille Syrjälä2013-02-201-0/+3
| | | | | | | | | We already print the HWS addresses during init, so do the same for the pipe control page. Reduces guesswork when looking at hex addresses later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: clean up panel fitter handling in lvdsMika Kuoppala2013-02-202-23/+29
| | | | | | | | | | | | | | | | | | | | | | | | With the previous patch "drm/i915: disable shared panel fitter for pipe" we now disable the panel fitter at the right spot in the modeset sequence in the crtc functions on all platforms. Hence the disabling in intel_disable_lvds is no longer required and potentially harmful (since the plane is still enabled at this point). Similarly on the enabling side we enable the panel fitter in the lvds callback only once the plane is enabled. Which is too late. Hence move this into a new intel_pre_enable_lvds callback. Finally we can ditch lvds_encoder->pfit_dirty - this was required to work around the crtc helper semantics, but with the new i915 modeset infrastructure we should enable/disable the pfit only when enabling or disabling the entire output pipeline. So separate state tracking for the pfit is no longer required. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Bikeshed the commit message a bit to stress that now we enable/disable the pfit on i9xx platforms at the right point of time compared to the old code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: disable shared panel fitter for pipeMika Kuoppala2013-02-201-0/+8
| | | | | | | | | | | | | | | | If encoder is switched off by BIOS, but the panel fitter is left on, we never try to turn off the panel fitter and leave it still attached to the pipe - which can cause blurry output elsewhere. Based on work by Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867 Cc: stable@vger.kernel.org Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com> [danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: detect wrong MCH watermark valuesDaniel Vetter2013-02-202-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Some early bios versions seem to ship with the wrong tuning values for the MCH, possible resulting in pipe underruns under load. Especially on DP outputs this can lead to black screen, since DP really doesn't like an occasional whack from an underrun. Unfortunately the registers seem to be locked after boot, so the only thing we can do is politely point out issues and suggest a BIOS upgrade. Arthur Runyan pointed us at this issue while discussion DP bugs - thus far no confirmation from a bug report yet that it helps. But at least some of my machines here have wrong values, so this might be useful in understanding bug reports. v2: After a bit more discussion with Art and Ben we've decided to only the check the watermark values, since the OREF ones could be be a notch more aggressive on certain machines. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Runyan, Arthur J <arthur.j.runyan@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/ctx: Remove bad invariantBen Widawsky2013-02-151-5/+0Star
| | | | | | | | | | | | | It's not that the assertion is incorrect, but rather that we can call do_destroy early in loading, and we will falsely BUG(). Since contexts have been in for a while now, and in the internal APIs are pretty stable, it should be fairly safe to remove this. v2: Remove unused dev_priv, and dev Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Extract ring init from hw_initBen Widawsky2013-02-151-19/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | The ring initialization will differ a bit in upcoming generations, and this split will prepare the code for what's needed. This patch also fixes a bug introduced in: commit 99433931950f33039d9e1a52b4ed9af3f1b58e84 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Tue Jan 22 14:12:17 2013 +0200 drm/i915: use gem_set_seqno() on hardware init After doing the extraction, the bad error handling became obvious. I acknowledge that this should be two patches, but it's a pretty small/trivial patch. If requested, I can certainly do the fix as a distinct patch. v2: Should be cleanup blt, not init blt on failure (Chris) v3: Forgot to git add on v2 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix gen2 mappable calculationsBen Widawsky2013-02-152-10/+16
| | | | | | | | | | | | | | | | | | When I refactored the code initially, I forgot that gen2 uses a different bar for the CPU mappable aperture. The agp-less code knows nothing of generations less than 5, so we have to expand the gtt_probe function to include the mappable base and end. It was originally broken by me: commit baa09f5fd8a6d033ec075355dda99a65b7f6a0f3 Author: Ben Widawsky <ben@bwidawsk.net> Date: Thu Jan 24 13:49:57 2013 -0800 drm/i915: Add probe and remove to the gtt ops Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add ibx_irq_postinstallPaulo Zanoni2013-02-151-43/+25Star
| | | | | | | | | | | So we can remove duplicated code. Note that this function is used not only on IBX, but also CPT and LPT. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Also bikeshed s/ironlake_enable_pch_hotplug/ibx_enable_hotplug to keep consistent with our ibx for pch naming scheme.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix sprite_scaling_enabled for multiple spritesVille Syrjälä2013-02-152-12/+17
| | | | | | | | | | | | | | We have more than one sprite, so a boolean simply won't cut it. Turn sprite_scaling_enabled into a bitmask and track the state of sprite scaler for each sprite independently. Also don't re-enable LP watermarks until the sprite registers have actually been written, and thus sprite scaling has really been disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: unify HDMI/DP hpd definitionsDaniel Vetter2013-02-154-48/+38Star
| | | | | | | | | | They're physically the same pins and also the same bits, duplicating only confuses the reader. This also makes it a bit obvious that we have quite some code duplication going on here. Squashing that is for a larger rework in our hpd handling though. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Clarify HW context size logicBen Widawsky2013-02-151-5/+2Star
| | | | | | | | | | | | This was a rebase error from when the patches originally landed. Since the context size is unsigned, there is also no use in checking if it's less than 0. The existing code is not really wrong, but it's not simple as it should be. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: write backlight harderDaniel Vetter2013-02-151-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid changed the register write sequence for restoring the backlight, which helped prevent non-working backlights on some machines. Turns out that the original sequence was the right thing to do for a different set of machines. Worse, setting the backlight level _after_ enabling it seems to reset it somehow. So we need to make that one conditional upon the backlight having been reset to zero, and add the old one back. Cargo-culting at it's best, but it seems to work. Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* i915: ignore lid open event when resumingZhang Rui2013-02-144-20/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i915 driver needs to do modeset when 1. system resumes from sleep 2. lid is opened In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes, thus it is the i915_resume code does the modeset rather than intel_lid_notify(). But in PM_SUSPEND_FREEZE state, this will be broken because system is still responsive to the lid events. 1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid. 2. When we reopen the lid, intel_lid_notify() will do a modeset, before the system is resumed. here is the error log, [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]() [92146.548076] Hardware name: VGN-Z540N [92146.548078] pipe_off wait timed out [92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G W 3.8.0-rc3-s0i3-v3-test+ #9 [92146.548175] Call Trace: [92146.548189] [<c10378e2>] warn_slowpath_common+0x72/0xa0 [92146.548227] [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915] [92146.548263] [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915] [92146.548270] [<c10379b3>] warn_slowpath_fmt+0x33/0x40 [92146.548307] [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915] [92146.548344] [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915] [92146.548380] [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915] [92146.548417] [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915] [92146.548456] [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915] [92146.548493] [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915] [92146.548535] [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915] [92146.548543] [<c15610d3>] notifier_call_chain+0x43/0x60 [92146.548550] [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80 [92146.548556] [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30 [92146.548563] [<c131a684>] acpi_lid_send_state+0x78/0xa4 [92146.548569] [<c131aa9e>] acpi_button_notify+0x3b/0xf1 [92146.548577] [<c12df56a>] ? acpi_os_execute+0x17/0x19 [92146.548582] [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc [92146.548589] [<c12e2b82>] acpi_device_notify+0x16/0x18 [92146.548595] [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f [92146.548600] [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b [92146.548607] [<c1051208>] process_one_work+0x128/0x3f0 [92146.548613] [<c1564f73>] ? common_interrupt+0x33/0x38 [92146.548618] [<c104f8c0>] ? wake_up_worker+0x30/0x30 [92146.548624] [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e [92146.548629] [<c10524f9>] worker_thread+0x119/0x3b0 [92146.548634] [<c10523e0>] ? manage_workers+0x240/0x240 [92146.548640] [<c1056e84>] kthread+0x94/0xa0 [92146.548647] [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0 [92146.548652] [<c15649b7>] ret_from_kernel_thread+0x1b/0x28 [92146.548658] [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0 three different modeset flags are introduced in this patch MODESET_ON_LID_OPEN: do modeset on next lid open event MODESET_DONE: modeset already done MODESET_SUSPENDED: suspended, only do modeset when system is resumed In this way, 1. when lid is closed, MODESET_ON_LID_OPEN is set so that we'll do modeset on next lid open event. 2. when lid is opened, MODESET_DONE is set so that duplicate lid open events will be ignored. 3. when system suspends, MODESET_SUSPENDED is set. In this case, we will not do modeset on any lid events. Plus, locking mechanism is also introduced to avoid racing. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix RC6VIDS encode/decodeBen Widawsky2013-02-141-2/+2
| | | | | | | | | | | | | | | | | | | | The RC6 VIDS has a linear ramp starting at 250mv, which means any values below 250 are invalid. The old buggy macros tried to adjust for this to be more flexible, but there is no need. As Dan pointed out the ENCODE only ever has one value. The only invalid value for decode is an input of 0 which means something is really wonky, and the cases where DECODE are used either don't matter (debug values), or would be implicitly correct (the check for less than 450). This patch makes simpler, easier to read macros which are actually correct. Maybe this patch can actually fix some bugs now. Thanks to Dan for catching this. /me hides Cc: stable@kernel.org Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-19 04:49:56 +0200