- 26 Feb, 2015 2 commits
-
-
Akash Goel authored
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>
-
Ander Conselvan de Oliveira authored
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:
-
- 25 Feb, 2015 12 commits
-
-
Matt Roper authored
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:
-
Matt Roper authored
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 31c946e8 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:
-
John Harrison authored
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:
-
John Harrison authored
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 authored
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:
-
Michel Thierry authored
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:
-
Ben Widawsky authored
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:
-
Ben Widawsky authored
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 authored
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:
-
Sonika Jindal authored
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:
-
Sonika Jindal authored
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:
-
Dan Carpenter authored
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 d7f46fc4 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:
-
- 24 Feb, 2015 8 commits
-
-
Damien Lespiau authored
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ramalingam C authored
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:
-
Vandana Kannan authored
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:
-
Durgadoss R authored
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 authored
Definition of VLV RR switch bit and corresponding toggling in set_drrs function. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Vandana Kannan authored
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:
Pradeep Bhat <pradeep.bhat@intel.com> Signed-off-by:
-
Ramalingam C authored
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:
-
Thomas Daniel authored
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:
-
- 23 Feb, 2015 18 commits
-
-
Thomas Daniel authored
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=88096Signed-off-by:
-
Damien Lespiau authored
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:
-
Paulo Zanoni authored
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:
-
Paulo Zanoni authored
So allow it. Reviewed-by:
-
Paulo Zanoni authored
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 authored
I want to make this code a little more complicated, so let's extract the function first. Reviewed-by:
-
Jeff McGee authored
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 authored
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 authored
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: -
Damien Lespiau authored
Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
-
Vijay Purushothaman authored
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:
-
Vijay Purushothaman authored
Added new PHY register definitions to control TDC buffer calibration and digital lock threshold. Signed-off-by:
-
Chris Wilson authored
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=88308Signed-off-by:
-
Dave Gordon authored
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:
-
Daniel Vetter authored
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 authored
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
UMS is no more! Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
