summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Remove DRIVER_MODESET checks from modeset codeDaniel Vetter2015-02-274-15/+2
| | | | | | | | Mostly just checks in i915-private modeset ioctls. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove regfile code&data for UMS suspend/resumeDaniel Vetter2015-02-274-900/+3
| | | | | | | | | Lots of lines to remove! Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [danvet: Fixup makefile.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove DRIVER_MODESET checks from gem codeDaniel Vetter2015-02-271-14/+0
| | | | | | | | Hooray! Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove DRIVER_MODESET checks in the gpu reset codeDaniel Vetter2015-02-271-26/+23
| | | | | | | | Again, good riddance to UMS! Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove DRIVER_MODESET checks from suspend/resume codeDaniel Vetter2015-02-271-61/+52
| | | | | | | | UMS is dead, yay! Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove DRIVER_MODESET checks in load/unload/close codeDaniel Vetter2015-02-271-58/+37
| | | | | | | | UMS is gone, this is dead code. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: fix a printk formatDan Carpenter2015-02-261-1/+1
| | | | | | | | | | | | | | This printk leads to the following Smatch warning: drivers/gpu/drm/i915/i915_gem_gtt.c:336 alloc_pt_range() error: '%pa' expects argument of type 'phys_addr_t*', argument 5 has type 'struct i915_page_table_entry*' It looks like a simple typo to me where "%p" was intended instead of "%pa". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add media rc6 residency file to sysfsVille Syrjälä2015-02-261-0/+25
| | | | | | | | | | | | On VLV/CHV the media well rc6 residency gets reported separately from the render well, so add another file to sysfs so that we can report the residency to the user. Testcase: igt/pm_rc6_residency --run-subtest media-rc6-accuracy Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add missing description to parameter in alloc_pt_rangeMichel Thierry2015-02-261-1/+1
| | | | | | | | | | | The patch "drm/i915: Plumb drm_device through page tables operations" added an extra parameter, but it didn't update the function description. Also remove unnecessary blank line added by the same patch. Found by kbuild test robot. Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functionsAkash Goel2015-02-262-54/+17
| | | | | | | | | | | | | | | | | | | The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register are stored, initially by the Driver, inside the dev_priv->rps structure. Since these values are expected to remain same throughout, there is no real need to read this register, on dynamic basis, from certain debugfs/sysfs functions and the values can be instead retrieved from the dev_priv->rps structure when needed. For the i915_frequency_info debugfs interface, the frequency values from the RP_STATE_CAP register only should be used, to indicate the actual Hw state, since it is principally used for the debugging purpose. v2: Reverted the changes in i915_frequency_info function, to continue report back the frequency values, as per the actual Hw state (Chris) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Look at staged config when fixing pipe_src_w for LVDSAnder Conselvan de Oliveira2015-02-261-1/+1
| | | | | | | | | | | The code in function intel_crtc_compute_config() that evens pipe_src_w if necessary would look at the current config instead of the staged one when deciding if there is an LVDS encoder in use. This could potentially lead to the value not being updated, if during the modeset a crtc wasn't driving an LVDS encoder. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Ensure crtc_state backpointer is always initializedMatt Roper2015-02-261-0/+2
| | | | | | | | | | As we transition to full atomic modesetting, we want to be able to pass intel_crtc_state around in various places that we pass intel_crtc directly today. Ensure that the ->crtc backpointer is properly initialized in case we need to get back to the associated CRTC. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use enabled value from crtc_state rather than crtc (v2)Matt Roper2015-02-263-28/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As vendors transition their drivers from legacy to atomic there's some duplication of data between drm_crtc and drm_crtc_state (since unconverted drivers likely won't have a state structure). i915 is partially converted and does have a crtc->state structure, but still uses direct crtc fields internally in many places, which causes the two sets of data to get out of sync. As of commit commit 31c946e85ce6b48ce0f25e3cdca8362e4fe8b300 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Feb 22 12:24:17 2015 +0100 drm: If available use atomic state in getcrtc ioctl This way drivers fully converted to atomic don't need to update these legacy state variables in their modeset code any more. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> the DRM core starts assuming that the presence of a ->state structure implies that it should make use of the values stored there which, on i915, leads to the core code using stale values for CRTC 'enabled' status. Let's switch over to using the state value of 'enable' internally rather than using the drm_crtc field. This ensures that our driver internals are working from the same data that the DRM core is, avoiding mismatches. This patch was generated with Coccinelle using the following semantic patch: <smpl> @@ struct drm_crtc C; struct drm_crtc *CP; @@ ( - C.enabled + C.state->enable | - CP->enabled + CP->state->enable ) // For assignments, we still update the legacy value as well as the state value // so add an extra assignment statement for that. @@ struct drm_crtc C; struct drm_crtc *CP; expression E; @@ ( C.state->enable = E; + C.enabled = E; | CP->state->enable = E; + CP->enabled = E; ) </smpl> The crtc->mode and crtc->hwmode fields should probably be transitioned over as well eventually, but we seem to do an okay job of keeping those up-to-date already so I want to minimize the changes that will clash with Ander's in-progress atomic work. v2: Don't remove the assignments to the legacy value when we assign to the state value. A second cocci stanza takes care of adding the legacy assignment back where appropriate. (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Cache ringbuf pointer in request structureJohn Harrison2015-02-254-18/+5
| | | | | | | | | | | | | | | | | | | | | | | | In execlist mode, the ringbuf is a function of the ring and context whereas in legacy mode, it is derived from the ring alone. Thus the calculation required to determine the ringbuf pointer from the ring (and context) also needs to test execlist mode or not. This is messy. Further, the request structure holds a pointer to both the ring and the context for which it was created. Thus, given a request, it is possible to derive the ringbuf in either legacy or execlist mode. Hence it is necessary to pass just the request in to all the low level functions rather than some combination of request, ring, context and ringbuf. However, rather than recalculating it each time, it is much simpler to just cache the ringbuf pointer in the request structure itself. Caching the pointer means the calculation is done once at request creation time and all further code and simply read it directly from the request structure. OTC-Jira: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> [danvet: Drop contentless comment in lrc alloc request entirely. And spelling fix in the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add missing trace point to LRC execbuff code pathJohn Harrison2015-02-251-0/+2
| | | | | | | | | | | There is a trace point in the legacy execbuffer execution path that is missing from the execlist path. Trace points are extremely useful for debugging and are used by various automated validation tests. Hence, this patch adds the missing trace point back in. OTC-Jira: VIZ-5115 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename 'flags' to 'dispatch_flags' for better code readingJohn Harrison2015-02-255-35/+41
| | | | | | | | | | | | | | | | | | There is a flags word that is passed through the execbuffer code path all the way from initial decoding of the user parameters down to the very final dispatch buffer call. It is simply called 'flags'. Unfortuantely, there are many other flags words floating around in the same blocks of code. Even more once the GPU scheduler arrives. This patch makes it more obvious exactly which flags word is which by renaming 'flags' to 'dispatch_flags'. Note that the bit definitions for this flags word already have an 'I915_DISPATCH_' prefix on them and so are not quite so ambiguous. OTC-Jira: VIZ-1587 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> [danvet: Resolve conflict with Chris' rework of the bb parsing.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Plumb drm_device through page tables operationsMichel Thierry2015-02-251-13/+16
| | | | | | | | | | The next patch in the series will require it for alloc_pt_single. v2: Rebased after s/page_tables/page_table/. Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Create page table allocatorsBen Widawsky2015-02-253-96/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we move toward dynamic page table allocation, it becomes much easier to manage our data structures if break do things less coarsely by breaking up all of our actions into individual tasks. This makes the code easier to write, read, and verify. Aside from the dissection of the allocation functions, the patch statically allocates the page table structures without a page directory. This remains the same for all platforms, The patch itself should not have much functional difference. The primary noticeable difference is the fact that page tables are no longer allocated, but rather statically declared as part of the page directory. This has non-zero overhead, but things gain additional complexity as a result. This patch exists for a few reasons: 1. Splitting out the functions allows easily combining GEN6 and GEN8 code. Page tables have no difference based on GEN8. As we'll see in a future patch when we add the DMA mappings to the allocations, it requires only one small change to make work, and error handling should just fall into place. 2. Unless we always want to allocate all page tables under a given PDE, we'll have to eventually break this up into an array of pointers (or pointer to pointer). 3. Having the discrete functions is easier to review, and understand. All allocations and frees now take place in just a couple of locations. Reviewing, and catching leaks should be easy. 4. Less important: the GFP flags are confined to one location, which makes playing around with such things trivial. v2: Updated commit message to explain why this patch exists v3: For lrc, s/pdp.page_directory[i].daddr/pdp.page_directory[i]->daddr/ v4: Renamed free_pt/pd_single functions to unmap_and_free_pt/pd (Daniel) v5: Added additional safety checks in gen8 clear/free/unmap. v6: Use WARN_ON and return -EINVAL in alloc_pt_range (Mika). v7: Make err_out loop symmetrical to the way we allocate in alloc_pt_range. Also s/page_tables/page_table and correct commit message (Mika) Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v3+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Complete page table structuresBen Widawsky2015-02-254-73/+44
| | | | | | | | | | | | | | | | Move the remaining members over to the new page table structures. This can be squashed with the previous commit if desire. The reasoning is the same as that patch. I simply felt it is easier to review if split. v2: In lrc: s/ppgtt->pd_dma_addr[i]/ppgtt->pdp.page_directory[i].daddr/ v3: Rebase. v4: Rebased after s/page_tables/page_table/. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: page table abstractionsBen Widawsky2015-02-252-92/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we move to dynamic page allocation, keeping page_directory and pagetabs as separate structures will help to break actions into simpler tasks. To help transition the code nicely there is some wasted space in gen6/7. This will be ameliorated shortly. Following the x86 pagetable terminology: PDPE = struct i915_page_directory_pointer_entry. PDE = struct i915_page_directory_entry [page_directory]. PTE = struct i915_page_table_entry [page_tables]. v2: fixed mismatches after clean-up/rebase. v3: Clarify the names of the multiple levels of page tables (Daniel) v4: Addressing Mika's review comments. s/gen8_free_page_directories/gen8_free_page_directory and free the page tables for the directory there. In gen8_ppgtt_allocate_page_directories, do not leak previously allocated pt in case the page_directory alloc fails. Update error return handling in gen8_ppgtt_alloc. v5: Do not leak pt on error in gen6_ppgtt_allocate_page_tables. (Mika) v6: s/page_tables/page_table/. (Mika) Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Add support for edp1.4 low vswingSonika Jindal2015-02-252-8/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | Based upon vbt's vswing preemph settings value select the appropriate translations for edp. v2: Incorporating bspec changes for vswing and preemph levels, adding edp translation table. Removed HSW from selection 9 which is specific to skl and correcting the returning of level2 from max pre emph (Damien) v3: Rebasing on top of renaming patches. Adding level(3,0) since level(2,2) as mentioned in bspec is invalid as per edp spec. Also changed the determining of size of the table selected (Satheesh). v4: Adding level 3 in max voltage selection if low vswing is selected (Satheesh) v5: Add a comment stating that skl_ddi_translations_edp is for eDP 1.4 low vswing panels. v6: Updating recommended DDI translation table for edp 1.4 Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v4) Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> (v6) Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Support for edp low_vswing param in vbtSonika Jindal2015-02-253-0/+9
| | | | | | | | | | | | | | | | | v2: Adding VBT version check for low_vswing field, and correcting parsing v3: (Damien) - Restrain the scope of the 'vswing' variable - Use the more idiomatic "ev_priv->vbt.edp_low_vswing = vswing == 0;" instead of if (foo) var = true; else var = false; - Shorten edp_vswing_premph_setting to edp_vswing_premph to fit in 80 chars - Add the version from which the edp_vswing_premph field is valid in the struct definition Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v2) Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: cleanup some indentingDan Carpenter2015-02-251-2/+3
| | | | | | | | | | | | | | | | | | | | | | Static checkers complain that we should probably add curly braces because, from the indenting, it looks like seq_printf() should be inside the list_for_each_entry() loop. But the code is actually correct, it's just the indenting which is off. Besides fixing the indenting on seq_printf(), I did add curly braces, because generally mult-line indents should have curly braces to make them more readable. The unintended indent was left behind and not unindented in commit d7f46fc4e7323887494db13f063a8e59861fefb0 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Make sure to allocate mininum sizes in the DDBDamien Lespiau2015-02-241-4/+18
| | | | | | | | | | | | | | | | | | I overlooked the fact that we need to allocate a minimum 8 blocks and that just allocating the planes depending on how much they need to fetch from the DDB in proportion of how much memory bw is necessary for the whole display can lead to cases where we don't respect those minima (and thus overrun). So, instead, start by allocating 8 blocks to each active display plane and then allocate the remaining blocks like before. v2: Rebase on top of -nightly Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Enhancing eDP DRRS debug messageRamalingam C2015-02-241-1/+1
| | | | | | | | | When Downclock mode is not found, the same info is added to the corresponding debug log. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Documentation/drm: DocBook integration for DRRSVandana Kannan2015-02-242-0/+106
| | | | | | | | | Adding an overview of DRRS in general and the implementation for eDP DRRS. Also, describing the functions related to eDP DRRS. Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Enable eDP DRRS for CHVDurgadoss R2015-02-242-2/+2
| | | | | | | | | | | | | | | | | This patch enables eDP DRRS for CHV by adding the required IS_CHERRYVIEW() checks. CHV uses the same register bit as VLV. [Vandana]: Since CHV has 2 sets of M_N registers, it will follow the same code path as gen < 8. Added CHV check in dp_set_m_n() [Ram]: Rebased on top of previous patch modifications Signed-off-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Support for RR switching on VLVVandana Kannan2015-02-242-2/+9
| | | | | | | | | | | Definition of VLV RR switch bit and corresponding toggling in set_drrs function. Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bdw: Add support for DRRS to switch RRVandana Kannan2015-02-241-2/+14
| | | | | | | | | | | | | | | | | | | | For Broadwell, there is one instance of Transcoder MN values per transcoder. For dynamic switching between multiple refreshr rates, M/N values may be reprogrammed on the fly. Link N programming triggers update of all data and link M & N registers and the new M/N values will be used in the next frame that is output. V2: [By Ram]: intel_dp_set_m_n() is rewritten to accommodate gen >= 8 [Rodrigo] V3: Coding style correction [Ram] V4: [By Ram] intel_dp_set_m_n modifications are moved into a separate patch, retaining only DRRS related changes here [Rodrigo] Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add support for DRRS in intel_dp_set_m_nRamalingam C2015-02-242-8/+44
| | | | | | | | | | | | | | | | | | | | | | | | Till Gen 7 we have two sets of M_N registers, but Gen 8 onwards we have only one M_N register set. To support DRRS on both scenarios a input parameter to intel_dp_set_m_n is added. In case of DRRS, When platform provides two set of M_N registers for dp, we can program them with two different dividers and switch between them. But when only one such register set is provided, we have to program the required divider M_N value on that registers itself. Two enum members M1_N1 and M2_N2 are defined to represent the above scenarios. M1_N1 : Program dp_m_n on M1_N1 registers dp_m2_n2 on M2_N2 registers (If supported) M2_N2 : Program dp_m2_n2 on M1_N1 registers M2_N2 registers are not supported Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Shift driver's HWSP usage out of reserved rangeThomas Daniel2015-02-241-3/+4
| | | | | | | | | | | | | | | | As of Gen6, the general purpose area of the hardware status page has shrunk and now begins at dword 0x30. i915 driver uses dword 0x20 to store the seqno which is now reserved. So shift our HWSP dwords up into the general purpose range before this bites us. Note that all available documentation just says this is reserved without going into details about what it's used for. Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> [danvet: Add clarification from Thomas that unfortunately Bspec is silent on what "reserverd" precisely means.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Reset logical ring contexts' head and tail during GPU resetThomas Daniel2015-02-243-4/+45
| | | | | | | | | | | | | | | | | | | | Work was getting left behind in LRC contexts during reset. This causes a hang if the GPU is reset when HEAD==TAIL because the context's ringbuffer head and tail don't get reset and retiring a request doesn't alter them, so the ring still appears full. Added a function intel_lr_context_reset() to reset head and tail on a LRC and its ringbuffer. Call intel_lr_context_reset() for each context in i915_gem_context_reset() when in execlists mode. Testcase: igt/pm_rps --run-subtest reset #bdw Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88096 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> [danvet: Flatten control flow in the lrc reset code a notch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Tune IZ hashing when subslices are unbalancedDamien Lespiau2015-02-244-4/+62
| | | | | | | | | | | | | | | | | | | | When one EU is disabled in a particular subslice, we can tune how the work is spread between subslices to improve EU utilization. v2: - Use a bitfield to record which subslice(s) has(have) 7 EUs. That will also make the machinery work if several sublices have 7 EUs. (Jeff Mcgee) - Only apply the different hashing algorithm if the slice is effectively unbalanced by checking there's a single subslice with 7 EUs. (Jeff Mcgee) v3: Fix typo in comment (Jeff Mcgee) Issue: VIZ-3845 Cc: Jeff Mcgee <jeff.mcgee@intel.com> Reviewed-by: Jeff Mcgee <jeff.mcgee@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't reallocate the compressed FB at every framePaulo Zanoni2015-02-241-1/+1
| | | | | | | | | | | | | With the current code we just reallocate the compressed FB at every FBC update: we have X in one frame, then in the other frame we need X again, but we check "needed < have" instead of "needed <= have". v2: Rebase after Jani addressed the other problems described in v1. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: gen5+ can have FBC with multiple pipesPaulo Zanoni2015-02-231-2/+4
| | | | | | | | So allow it. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: HSW+ FBC is tied to pipe APaulo Zanoni2015-02-231-2/+11
| | | | | | | | | | So add code to consider this case. v2: Reorder the series, so drop the possible_framebuffer_bits chunk. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: extract intel_fbc_find_crtc()Paulo Zanoni2015-02-231-17/+29
| | | | | | | | | I want to make this code a little more complicated, so let's extract the function first. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Request full SSEU enablement on Gen9Jeff McGee2015-02-232-2/+58
| | | | | | | | | | | | | | | | | | | | On Gen9 the render power gating can leave slice/subslice/EU in a partially enabled state. We must make an explicit request for full SSEU enablement through the Render Power Clock State register when resuming render work. This register is save/ restored in the logical ring context image for execlist submission mode. Initialize its value in each LRC image to request full enablement according to the device SSEU config. Thanks to Sharma Ankitprasad and Akash Goel for highlighting the issue and proposing the initial fix on which this patch is based. v2: Adjusted the names of the power gating support flags to fit update of an earlier patch. Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: "Akash Goel <akash.goel@intel.com>" Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Add SKL HW status to SSEU statusJeff McGee2015-02-232-0/+70
| | | | | | | | | | | | | | | | | | | | Add a new section to the 'i915_sseu_status' debugfs entry to report the currently enabled counts of slice, subslice, and execution units on the device. The count of enabled subslice per slice represents the most enabled subslice on any one slice for devices where imbalances may exist. Similarly, the count of enabled EU per subslice represents the most enabled EU on any one subslice. Collect this device status for Skylake by reading the Gen9 power gate control ack message registers. Power gate control operates on EU in pairs, therefore our reported counts of enabled EU can be overestimated by one for each pair in which one EU is fused-off. Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Determine SKL slice/subslice/EU infoJeff McGee2015-02-234-1/+124
| | | | | | | | | | | | | | | | | | | | | Read fuse registers to determine the available slice total, subslice total, subslice per slice, EU total, and EU per subslice counts of the SKL device. The EU per subslice attribute is more precisely defined as the maximum EU available on any one subslice, since available EU counts may vary across subslices due to fusing. Set flags indicating the SKL device's slice/subslice/EU (SSEU) power gating capability. Make all values available via debugfs entry 'i915_sseu_status'. v2: Several small clean-ups suggested by Damien. Most notably, used smaller types for the new device info fields to reduce memory usage and improved the clarity/readability of the method used to extract attribute values from the fuse registers. Signed-off-by: Jeff McGee <jeff.mcgee@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/skl: Implement WaDisablePowerCompilerClockGatingDamien Lespiau2015-02-232-2/+11
| | | | | | Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Limit max VCO supported in CHV to 6.48GHzVijay Purushothaman2015-02-231-1/+1
| | | | | | | | As per the recommendation from PHY team, limit the max vco supported in CHV to 6.48 GHz Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add new PHY reg definitions for lock thresholdVijay Purushothaman2015-02-231-0/+10
| | | | | | | | | Added new PHY register definitions to control TDC buffer calibration and digital lock threshold. Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Trim the command parser allocationsChris Wilson2015-02-232-75/+73
| | | | | | | | | | | | | | | | | | Currently, the command parser tries to create a secondary batch exactly as large as the original, and vmap both. This is open to abuse by userspace using extremely large batch objects, but only executing very short batches. For example, this would be if userspace were to implement a command submission ringbuffer. However, we only need to allocate pages for just the contents of the command sequence in the batch - all relocations copied to the secondary batch will reference the original batch and so there can be no access to the secondary batch outside of the explicit execution region. Testcase: igt/gem_exec_big #ivb,byt,hsw Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88308 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: FIFO space query code refactorDave Gordon2015-02-231-7/+12
| | | | | | | | | | | | | | When querying the GTFIFOCTL register to check the FIFO space, the read value must be masked. The operation is repeated explicitly in several places. This change refactors the read-and-mask code into a function call. v2: rebased on top of Mika's forcewake patch set, specifically: [PATCH 8/8] drm/i915: Enum forcewake domains and domain identifiers Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: WARN if drm_handle_vblank is called errornouslyDaniel Vetter2015-02-231-1/+1
| | | | | | | | | | | | | | | | | | | | | KMS drivers are in full control of their irq and vblank handling, if they get a vblank interrupt before drm_vblank_init or after drm_vblank_cleanup that's just a driver bug. For ums driver there's only r128 and radeon which support vblank, and they call drm_vblank_init in their driver load functions. Which again means that userspace can do whatever it wants with interrupt, vblank structures will always be there. So this should never happen, let's catch driver issues with a WARN_ON. Motivated by some discussions with Imre. v2: Use WARN_ON_ONCE as suggested by Imre. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/irq: Don't call ->get_vblank_counter directly from irq_uninstall/cleanupDaniel Vetter2015-02-231-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pipe might already have been shut down, and then it's not a good idea to call hw accessor functions. Instead use the same logic as drm_vblank_off which has all the necessary checks to avoid troubles or inconsistency. Noticed by Imre while reviewing my patches to remove some sanity checks from ->get_vblank_counter. v2: Try harder. disable_and_save can still access the vblank stuff when vblank->enabled isn't set. It has to, since vlbank irq could be disable but the pipe is still on when being called from drm_vblank_off. But we still want to use that code for more code sharing. So add a check for vblank->enabled on top - if that's not set we shouldn't have anyone waiting for the vblank. If we have that's a pretty serious bug. The other issue that Imre spotted is drm_vblank_cleanup. That code again calls disable_and_save and so suffers from the same issues. But really drm_irq_uninstall should have cleaned that all up, so replace the code with WARN_ON. Note that we can't delete the timer cleanup since drivers aren't required to use drm_irq_install/uninstall, but can do their own irq handling. v3: Make it clear that all that gunk in drm_irq_uninstall is really just bandaids for UMS races between the irq/vblank code. In UMS userspace is in control of enabling/disabling interrupts in general and vblanks specifically. v4: Imre observed that KMS drivers all call drm_vblank_cleanup before drm_irq_uninstall (as they should), so again the code in there is dead for KMS (due to dev->num_crtcs == 0 after drm_vblank_cleanup). Or should be, so only WARN for KMS - with UMS userspace could try to do evil things. v5: After more discussion on irc we've gone back to v3: the del_timer_sync is required in all cases in drm_vblank_cleanup, but let's restrict the WARN_ON to kms drivers only. Imre was also concerned that bad things could happen without the disable_and_save call. But we immediately free vblank structures afterwards which makes the save useless. And drm_handle_vblank has a check for dev->num_crtcs to avoid surprises with ums. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: Switch to drm_crtc variants of vblank functionsDaniel Vetter2015-02-233-7/+8
| | | | | | | | | | Where possible right now. Just a small step towards nirvana ... v2: git add. Uggh. Noticed by Imre. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: Flatten DRIVER_MODESET checks in i915_irq.cDaniel Vetter2015-02-231-25/+11
| | | | | | | | UMS is no more! Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: Drop pipe_enable checks in vblank funcsDaniel Vetter2015-02-231-52/+0
| | | | | | | | | | | | | | | With Ville's rework to use drm_crtc_vblank_on/off the core will take care of rejecting drm_vblank_get calls when the pipe is off. Also the core won't call the get_vblank_counter hooks in that case either. And since we've dropped ums support recently we can now remove these hacks, yay! Noticed while trying to answer questions Laurent had about how the new atomic helpers work. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
OpenPOWER on IntegriCloud