- 13 Jun, 2014 31 commits
-
-
Jesse Barnes authored
Early revs didn't have PPGTT support, so disable there. v2: add debug msg when disabling on early stepping v3: enable on other B3 packages as well (untested) (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=79669 References: https://bugs.freedesktop.org/show_bug.cgi?id=79670Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
CHECK linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: warning: incorrect type in initializer (different address spaces) linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: expected struct drm_i915_gem_exec_object2 *user_exec_list linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1529:47: got void [noderef] <asn:1>* linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: warning: incorrect type in argument 1 (different address spaces) linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: expected void [noderef] <asn:1>*dst linux/drivers/gpu/drm/i915/i915_gem_execbuffer.c:1533:61: got unsigned long long *<noident> Signed-off-by:
-
Ville Syrjälä authored
Knowing the device stepping may be crucial in analyzing problems. Since we always ask bug reporters for dmegs with drm.debug=0xe (or something) it would be nice if the PCI revision is already included in the dump. Avoids having to ask for lspci output as well. Signed-off-by:
-
Ville Syrjälä authored
obj->framebuffer_references isn't an atomic_t so the decrement needs to be protected by some lock. struct_mutex seems like the appropriate lock here, and we may already take it for the obj unref anyway. Signed-off-by:
-
Rodrigo Vivi authored
On the current structure HSW doesn't support PSR with sprites enabled but sprites can be enabled after PSR was enabled what would cause user to miss screen updates. v2: move it to update_plane. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Broadwell has a PSR per transcoder, where DDIA supports link disable and link standby modes while other transcoders only support link standby. Reviewed-by:
-
Rodrigo Vivi authored
Reviewed-by:
-
Rodrigo Vivi authored
When link is in stand by and PSR exit is triggered by a primary or sprite plane flip this mode allows only one single updated frame to be send to display than get back to PSR immediately. Reviewed-by:
-
Rodrigo Vivi authored
Also do not cache aux info. That info could be related to another panel. Reviewed-by:
-
Rodrigo Vivi authored
Being more conservative by enabling PSR only on psr_enable function. Reviewed-by:
-
Rodrigo Vivi authored
Let's be more conservative and protect platforms that don't support PSR from unecessary interactions. Reviewed-by:
-
Matt Roper authored
The DRM core will translate calls to legacy cursor ioctls into universal cursor calls automatically, so there's no need to maintain the legacy cursor support. This greatly simplifies the transition since we don't have to handle reference counting differently depending on which cursor interface was called. The aim here is to transition to the universal plane interface with minimal code change. There's a lot of cleanup that can be done (e.g., using state stored in crtc->cursor->fb rather than intel_crtc) that is left to future patches. v4: - Drop drm_gem_object_unreference() that is no longer needed now that we receive the GEM obj directly rather than looking up the ID. v3: - Pass cursor obj to intel_crtc_cursor_set_obj() if cursor fb changes, even if 'visible' is false. intel_crtc_cursor_set_obj() will notice that the cursor isn't visible and disable it properly, but we still need to get intel_crtc->cursor_addr set properly so that we behave properly if the cursor becomes visible again in the future without changing the cursor buffer (noted by Chris Wilson and verified via i-g-t kms_cursor_crc). - s/drm_plane_init/drm_universal_plane_init/. Due to type compatibility between enum and bool, everything actually works correctly with the wrong init call, except for the type of plane that gets exposed to userspace (it shows up as type 'primary' rather than type 'cursor'). v2: - Remove duplicate dimension checks on cursor - Drop explicit cursor disable from crtc destroy (fb & plane destruction will take care of that now) - Use DRM plane helper to check update parameters Cc: intel-gfx@lists.freedesktop.org Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Pallavi G<pallavi.g@intel.com> Signed-off-by:
-
Matt Roper authored
Refactor cursor buffer setting such that the code to actually update the cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes a GEM object as a parameter. The existing legacy cursor ioctl handler, intel_crtc_cursor_set() will now perform the userspace handle lookup and then call this new function. This refactoring is in preparation for the universal plane cursor support where we'll want to update the cursor with an actual GEM buffer object (obtained via drm_framebuffer) rather than a userspace handle. v2: Drop obvious kerneldoc and replace with note about function's reference consumption Reviewed-by: -
Matt Roper authored
Universal plane support had placeholders for cursor planes, but didn't actually do anything with them. Save the cursor plane reference inside the crtc and update the cursor plane parameter from void* to drm_plane. Reviewed-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Chris Wilson authored
To disable a plane, userspace passes in an framebuffer id of 0. This causes us to pass CRTC == NULL to setplane_internal, who promptly deferences it to grab the struct drm_device. Oops. [ 1296.467327] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1296.467332] IP: [<c134dc51>] setplane_internal+0x11/0x280 [ 1296.467338] *pde = 00000000 [ 1296.467341] Oops: 0000 [#1] SMP [ 1296.467344] Modules linked in: ccm bnep bluetooth snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel arc4 iwldvm snd_hda_controller snd_hda_codec mac80211 snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer iwlwifi sdhci_pci snd cfg80211 x86_pkg_temp_thermal hp_wmi sdhci sparse_keymap mmc_core crc32c_intel rfkill microcode hp_accel lpc_ich lis3lv02d wmi mfd_core serio_raw input_polldev soundcore e1000e ptp pps_core [ 1296.467367] CPU: 1 PID: 672 Comm: Xorg Tainted: G W 3.15.0-rc8+ #351 [ 1296.467369] Hardware name: Hewlett-Packard HP ProBook 6360b/1620, BIOS 68SCF Ver. B.42 12/29/2010 [ 1296.467371] task: f423b5c0 ti: c2332000 task.ti: c2332000 [ 1296.467374] EIP: 0060:[<c134dc51>] EFLAGS: 00013286 CPU: 1 [ 1296.467376] EIP is at setplane_internal+0x11/0x280 [ 1296.467378] EAX: 00000000 EBX: c2333e90 ECX: 00000000 EDX: f3165600 [ 1296.467380] ESI: f430f400 EDI: 00000000 EBP: c2333e14 ESP: c2333dd4 [ 1296.467382] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 1296.467384] CR0: 80050033 CR2: 00000000 CR3: 00159000 CR4: 000407d0 [ 1296.467385] Stack: [ 1296.467387] 000200da 00000002 c2333de8 c15dc4a0 f430f400 c2333e00 c134c54f eeeeeeee [ 1296.467391] f430f400 00000007 f416b480 c2333e14 00000000 c2333e90 f430f400 00000000 [ 1296.467396] c2333e4c c1350aed 00000000 00000000 00000000 00000000 00000000 00000000 [ 1296.467400] Call Trace: [ 1296.467406] [<c15dc4a0>] ? mutex_lock+0x10/0x28 [ 1296.467408] [<c134c54f>] ? _object_find+0x5f/0x90 [ 1296.467413] [<c1350aed>] drm_mode_setplane+0x10d/0x1f0 [ 1296.467416] [<c13509e0>] ? drm_mode_getplane+0x100/0x100 [ 1296.467420] [<c1342e4d>] drm_ioctl+0x1bd/0x4f0 [ 1296.467423] [<c13509e0>] ? drm_mode_getplane+0x100/0x100 [ 1296.467427] [<c111c023>] ? handle_mm_fault+0x5d3/0xb30 [ 1296.467431] [<c1118f31>] ? tlb_finish_mmu+0x11/0x40 [ 1296.467435] [<c1342c90>] ? drm_ioctl_flags+0x40/0x40 [ 1296.467438] [<c11593d2>] do_vfs_ioctl+0x2f2/0x4d0 [ 1296.467443] [<c1226512>] ? inode_has_perm.isra.32+0x32/0x40 [ 1296.467446] [<c122662f>] ? file_has_perm+0x7f/0x90 [ 1296.467449] [<c1226fec>] ? selinux_file_ioctl+0x4c/0xf0 [ 1296.467452] [<c1159610>] SyS_ioctl+0x60/0x90 [ 1296.467456] [<c15e578c>] sysenter_do_call+0x12/0x22 [ 1296.467457] Code: 3f cf ff eb dd ba 3f 00 00 00 b8 d9 c9 7f c1 e8 e6 3f cf ff eb d9 8d 74 26 00 55 89 e5 57 56 53 83 ec 34 66 66 66 66 90 89 45 f0 <8b> 00 85 c9 89 d6 89 cb 89 45 ec 0f 84 16 01 00 00 8b 45 f0 e8 [ 1296.467485] EIP: [<c134dc51>] setplane_internal+0x11/0x280 SS:ESP 0068:c2 Fixes regression from commit b02fd7fd8a541c3d590bfdda23365a927b507ceb Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Jun 10 08:28:10 2014 -0700 drm: Support legacy cursor ioctls via universal planes when possible (v4) While at it move the plane parameter to the first position in setplane_internal since that's the main object we're manipulating. Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Pallavi G<pallavi.g@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Matt Roper authored
If drivers support universal planes and have registered a cursor plane with the DRM core, we should use that universal plane support when handling legacy cursor ioctls. Drivers that transition to universal planes won't have to maintain separate legacy ioctl handling; drivers that don't transition to universal planes will continue to operate without any change to behavior. Note that there's a bit of a mismatch between the legacy cursor ioctls and the universal plane API's --- legacy ioctl's use driver buffer handles directly whereas the universal plane API takes drm_framebuffers. Since there's no way to recover the driver handle from a drm_framebuffer, we can implement legacy ioctl's in terms of universal plane interfaces, but cannot implement universal plane interfaces in terms of legacy ioctls. Specifically, there's no way to create a general cursor helper in the way we previously created a primary plane helper. It's important to land this patch before any patches that add universal cursor support to individual drivers so that drivers don't have to worry about juggling two different styles of reference counting for cursor buffers when userspace mixes and matches legacy and universal cursor calls. With this patch, a driver that switches to universal cursor support may assume that all cursor buffers are wrapped in a drm_framebuffer and can rely on framebuffer reference counting for all cursor operations. v4: - Add comments pointing out setplane_internal's reference-eating semantics. v3: - Drop drm_mode_rmfb() call that is no longer needed now that we're using setplane_internal(), which takes care of deref'ing the appropriate framebuffer. v2: - Use new add_framebuffer_internal() function to create framebuffer rather than trying to call directly into the ioctl interface and look up the handle returned. - Use new setplane_internal() function to update the cursor plane rather than calling through the ioctl interface. Note that since we're no longer looking up an fb_id, no extra reference will be taken here. - Grab extra reference to fb under lock in !BO case to avoid issues where racing userspace could cause the fb to be destroyed out from under us after we grab the fb pointer. Reviewed-by:
-
Matt Roper authored
Refactor DRM setplane code into a new setplane_internal() function that takes DRM objects directly as parameters rather than looking them up by ID. We'll use this in a future patch when we implement legacy cursor ioctls on top of the universal plane interface. v3: - Move integer overflow checking from setplane_internal to setplane ioctl. The upcoming legacy cursor support via universal planes needs to maintain current cursor ioctl semantics and not return error for these extreme values (found via intel-gpu-tools kms_cursor_crc test). v2: - Allow planes to be disabled without a valid crtc again (and add mention of this to setplane's kerneldoc, since it doesn't seem to be mentioned anywhere else). - Reformat some parameter line wrap Reviewed-by:
-
Matt Roper authored
Refactor DRM framebuffer creation into a new function that returns a struct drm_framebuffer directly. The upcoming universal cursor support will want to create framebuffers internally to wrap cursor buffers, so we want to be able to share that framebuffer creation with the drm_mode_addfb2 ioctl handler. v2: Take struct drm_mode_fb_cmd2 parameter directly rather than void* Reviewed-by:
-
Tom O'Rourke authored
Correct a merge mishap in commit e4443e45. Wa*:chv belongs in cherryview_enable_rps, not gen8_enable_rps. Signed-off-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by:
-
Oscar Mateo authored
These do not exist anymore. Spotted while reading through intel_ringbuffer.c Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
-
Chris Wilson authored
Inserting additional PTEs has no side-effect for us as the pfn are fixed for the entire time the object is resident in the global GTT. The downside is that we pay the entire cost of faulting the object upon the first hit, for which we in return receive the benefit of removing the per-page faulting overhead. On an Ivybridge i7-3720qm with 1600MHz DDR3, with 32 fences, Upload rate for 2 linear surfaces: 8127MiB/s -> 8134MiB/s Upload rate for 2 tiled surfaces: 8607MiB/s -> 8625MiB/s Upload rate for 4 linear surfaces: 8127MiB/s -> 8127MiB/s Upload rate for 4 tiled surfaces: 8611MiB/s -> 8602MiB/s Upload rate for 8 linear surfaces: 8114MiB/s -> 8124MiB/s Upload rate for 8 tiled surfaces: 8601MiB/s -> 8603MiB/s Upload rate for 16 linear surfaces: 8110MiB/s -> 8123MiB/s Upload rate for 16 tiled surfaces: 8595MiB/s -> 8606MiB/s Upload rate for 32 linear surfaces: 8104MiB/s -> 8121MiB/s Upload rate for 32 tiled surfaces: 8589MiB/s -> 8605MiB/s Upload rate for 64 linear surfaces: 8107MiB/s -> 8121MiB/s Upload rate for 64 tiled surfaces: 2013MiB/s -> 3017MiB/s Signed-off-by:
Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Adding missing Display mmio reg offset. Credits-to: Laws, Philip <philip.laws@intel.com> Cc: He, Shuang <shuang.he@intel.com> Signed-off-by:
-
Daniel Vetter authored
Signed-off-by: -
Imre Deak authored
Atm, the forcewake refcount will be incorrectly set to zero during system suspend if there is any reference held via the i915_forcewake_user debugfs entry. Fix this by simply not zeroing the sw counters during suspend and restoring the original state using them. Note that the only other places where we zeroed the counters were driver load and unload time, where it was redundant anyway. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78059Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
If the timer putting the last forcewake refcount was pending and we canceled it, we'll leak the corresponding forcewake and RPM references. v2: - do the ptr casting at the caller instead of adding a separate helper for this (Chris) Signed-off-by:
-
Damien Lespiau authored
pipe_name() returns an ascii character. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Tom O'Rourke authored
Add Broadwell support to i915_frequency_info and extend i915_max|min_freq_get|set to (gen >= 6). v2: generalized support for i915_max|min_freq_get|set (Daniel). Signed-off-by:
Jeff McGee <jeff.mcgee@intel.com> [danvet: Fix checkpatch fail.] Signed-off-by:
-
Ville Syrjälä authored
Certain DVO chips (ns2501 for example) don't like to be accessed unless the PLL is running. Simply skip the DVO get_hw_state if the DVO port is disabled. Signed-off-by:
-
Ville Syrjälä authored
Using names initializers when filling out the watermark structs saves you from having go look up the struct definition every single time. Signed-off-by:
-
Chris Wilson authored
Now that we have a release hook into i915_gem_object_free, we can move the explicit call to the internal stolen function and hook it up throught the callback instead. Signed-off-by:
-
Daniel Vetter authored
Otherwise we incur an unsightly WARNING. The mutex locking is a bit overkill, but it curbs races and eventially we might grow a locking check in the vblank wait code to make sure the right crtc lock is held. This is fallout from commit 93937071 Author: Jesse Barnes <jbarnes@virtuousgeek.org> AuthorDate: Fri Apr 4 16:12:09 2014 -0700 drm/i915: warn when a vblank wait times out Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79612Tested-by:
Guo Jinxian <jinxianx.guo@intel.com> Reviewed-by:
-
- 11 Jun, 2014 9 commits
-
-
Daniel Vetter authored
For no reason at all the public docs lack them, and Dave needs them for his hpd interrupt rework. Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: -
Robert Beckett authored
Replaced ever growing switch for gen version with chained conditionals. Futre gen's only need to add a new one if they require something different. Reviewed-by:
Robert Beckett <robert.beckett@intel.com> [danvet: Picked from internal tree and white-wash commit message.] Signed-off-by:
-
Matt Roper authored
Those LUT where defined in the original sprite patch introducing intel_plane, but were never used. commit b840d907 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Dec 13 13:19:38 2011 -0800 drm/i915: add SNB and IVB video sprite support v6 Signed-off-by:
-
Daniel Vetter authored
Keeping track of the power domains is a bit messy since crtc->active is currently updated by the platform hooks, but we need to be aware of which state transition exactly is going on. Maybe we simply need to shovel all the power domain handling down into platform code to simplify this. But doing that requires some more auditing since currently the ->mode_set callbacks still read some random registers (to e.g. figure out the reference clocks). Also note that intel_crtc_update_dpms is always call first/last even for encoders which have their own dpms functions. Hence we really only need to update this place here. Being a quick "does it blow up?" run not really tested yet. v2: Don't do runtime PM in the DPMS hooks for HAS_DDI platforms since that is stalled. Also add a comment to explain what's going on. Signed-off-by: -
Jesse Barnes authored
Working for real this time. i915_ppgtt_info has all sorts of good stuff in it and X is running nicely on top. Signed-off-by:
-
Shashank Sharma authored
Conceptually, the MIPI registers are addressed by the MIPI transcoder index, not the pipe. It doesn't matter right now, because there's a 1:1 relationship between pipes and MIPI transcoders, but that change allows us to break that link in the future V1: Created new patch to address Damien's review comment. Replacing _PIPE calls to _TRANSCODER calls V2: Re-basing on patch 2 V3: Re-basing on patch 2 V4: Re-basing on patch 2 Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
-
Shashank Sharma authored
Re-define MIPI register definitions in such a way that most of the existing DSI code can be re-used for future platforms. Register definitions are re-written using MMIO offset variable, so that without changing the existing sequence, same code can be generically applied. V4: Addressing review comments by Damien and Ville, splitting into two patches This patch removes all the un-necessary formatting changes from previous patch. V5: Removed 80 char limit formatting for existing MIPI regs V6: Removed extra space, change one definition Signed-off-by:
-
Robin Schroer authored
Fixed several double space pointer notations, and added one newline Signed-off-by:
Robin Schroer <sulamiification@gmail.com> Reviewed-by:
-
David Herrmann authored
Instead of shuffling gfp-masks all the time, use the shmem_read_mapping_page() helper. Note that __GFP_IO and __GFP_WAIT are set in mapping_gfp_mask() for i915, so the behavior is still the same. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
