- 04 Mar, 2013 3 commits
-
-
Jesse Barnes authored
Commented out and unneeded. 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>
-
Ben Widawsky authored
Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ben Widawsky authored
v2: Actually use num_pages (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 03 Mar, 2013 9 commits
-
-
Ville Syrjälä authored
Kill the HSW check from the single thread force wake code. HSW uses MT force wake exclusively these days. The commit that removed HSW single thread forcewake support: commit 36ec8f87 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 18 14:44:35 2012 +0200 drm/i915: unconditionally use mt forcewake on hsw/ivb Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Use the number '1' instead of FORCEWAKE_KERNEL when requesting single thread force wake since there is only one bit in the register. Using the FORCEWAKE_KERNEL name might give someone the wrong impression. Signed-off-by:
-
Ville Syrjälä authored
The MT forcewake ACK register also has a corresponding bit to each of the bits in the MT forcewake register. Use the define we have for the bit we care about instead of a hardcoded number. Signed-off-by:
-
Ville Syrjälä authored
The code is totally obvious so these comments serve no purpose. What's worse, one of them was wrong. Just remove them. Signed-off-by:
-
Ville Syrjälä authored
The load detection code has moved around at some point, but it left a comment behind. The code now looks to be different enough to make the comment stale as well. Just remove it. Signed-off-by:
-
Ville Syrjälä authored
The proper use of find_pll() isn't always so easy to determine from the code itself. Some documentation should help. Signed-off-by:
-
Ville Syrjälä authored
to_user_ptr() simply casts a pointer passed as u64 from user space to void __user * correctly. Using this lets us get rid of all the tiresome casts. The idea came from Chris Wilson <chris@chris-wilson.co.uk>. Signed-off-by:
-
Daniel Vetter authored
So ditch that if clause from the i8xx pll update code. Reviewed-by:
-
Rodrigo Vivi authored
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:
-
- 21 Feb, 2013 1 commit
-
-
Ville Syrjälä authored
Caching the PIPESTAT enable bits has been deemed pointless. Just read them from the register itself. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 20 Feb, 2013 18 commits
-
-
Ville Syrjälä authored
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ä authored
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/1116587Reviewed-by:
-
Ville Syrjälä authored
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:
-
Jesse Barnes authored
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: -
Paulo Zanoni authored
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=58897Signed-off-by: -
Paulo Zanoni authored
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 authored
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 authored
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 authored
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 authored
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 authored
Since basically every code called on these places comes from intel_ddi.c Signed-off-by:
-
Mika Kuoppala authored
Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Jani Nikula authored
It is customary to end sysfs attributes with a newline. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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:
-
Damien Lespiau authored
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:
-
Jesse Barnes authored
Use the new PM routines to indicate whether we need to VT switch at suspend and resume time. When a new driver is bound, set its flag accordingly, and when unbound, remove it from the PM's console tracking list. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Jesse Barnes authored
KMS drivers can potentially restore the display configuration without userspace help. Such drivers can can call a new funciton, pm_vt_switch_required(false) if they support this feature. In that case, the PM layer won't VT switch to the suspend console at suspend time and then back to the original VT on resume, but rather leave things alone for a nicer looking suspend and resume sequence. v2: make a function so we can handle multiple drivers (Alan) v3: use a list to track device requests (Rafael) v4: Squash in build fix from Jesse for CONFIG_VT_CONSOLE_SLEEP=n v5: Squash in patch from Wu Fengguang to add a few missing static qualifiers. v6: Add missing EXPORT_SYMBOL. Signed-off-by:
-
- 19 Feb, 2013 9 commits
-
-
Daniel Vetter authored
We already have the quirk entry for the mobile platform, but also reports on some desktop versions. So be paranoid and set it everywhere. References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html Cc: stable@vger.kernel.org Cc: David Woodhouse <dwmw2@infradead.org> Cc: "Sankaran, Rajesh" <rajesh.sankaran@intel.com> Reported-and-tested-by:
Mihai Moldovan <ionic@ionic.de> Signed-off-by:
-
Chris Wilson authored
Whilst IOMMU is enabled for the Intel GPU on Ironlake, it appears that using WC writes to update the PTE on the GPU fails miserably. The result looks like the majority of the writes do not land leading to lots of screen corruption and a hard system hang. v2: s/</<=/ to preserve the current exclusion of Sandybridge Reported-by:
Nathan Myers <ncm@cantrip.org> Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391Signed-off-by:
-
Ville Syrjälä authored
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:
-
Daniel Vetter authored
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:
-
Ben Widawsky authored
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:
-
Daniel Vetter authored
Yet another remnant ... this might explain why l3 remapping didn't really work on HSW. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441Spotted-by:
-
Ville Syrjälä authored
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:
-
Patrik Jakobsson authored
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:
-
Patrik Jakobsson authored
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:
-
