- 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:
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>
-
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:
Jani Nikula <jani.nikula@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 20 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:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-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:
Mika Kuoppala <mika.kuoppala@intel.com> 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 <daniel.vetter@intel.com>
-
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:
-
Daniel Vetter authored
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:
-
Daniel Vetter authored
At driver load we need to tell the vblank code about the state of the pipes, so that the logic around reject vblank_get when the pipe is off works correctly. Thus far i915 used drm_vblank_off, but one of the side-effects of it is that it also saves the vblank counter. And for that it calls down into the ->get_vblank_counter hook. Which isn't really a good idea when the pipe is off for a few reasons: - With runtime pm the register might not respond. - If the pipe is off some datastructures might not be around or unitialized. The later is what blew up on gen3: We look at intel_crtc->config to compute the vblank counter, and for a disabled pipe at boot-up that's just not there. Thus far this was papered over by a check for intel_crtc->active, but I want to get rid of that (since it's fairly race, vblank hooks are called from all kinds of places). So prep for that by adding a _reset functions which only does what we really need to be done at driver load: Mark the vblank pipe as off, but don't do any vblank counter saving or event flushing - neither of that is required. v2: Clarify the code flow slightly as suggested by Ville. v3: Fix kerneldoc spelling, spotted by Laurent. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v2) Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 13 Feb, 2015 12 commits
-
-
Daniel Vetter authored
Signed-off-by: -
Andreas Ruprecht authored
Commit 03dae59c ("drm/i915: Ditch UMS config option") removed CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still references this option in two #ifndef statements. As an undefined config option will always be 'false', we can drop the #ifndefs alltogether and adapt the printed error message. This inconsistency was found with the undertaker tool. Signed-off-by:
Andreas Ruprecht <rupran@einserver.de> [danvet: Undo logging change as requested by Jani.] Reviewed-by:
-
Damien Lespiau authored
I have no idea how that crept in, but we need to do the write from the ring and this is a masked register. Two fixes in 1! Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
-
Damien Lespiau authored
It's always a good idea to keep static analysis happy (also because it prompts doing the check like I proposed :), this time smatch complains: drivers/gpu/drm/i915/intel_ringbuffer.c:891 gen9_init_workarounds() warn: always true condition '((->dev->pdev->revision) >= (0)) => (0-255 >= 0)' That's because revision is a u8. Tweak a bit the condition then. Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
-
Damien Lespiau authored
This W/A is put in a gen9 specific function because it may well be needed on other gen9 platforms. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Mika Kuoppala authored
We use the pid of the process which opened our device when we track which was the culprit of the gpu hang. But as that file descriptor might get inherited, we might blame the wrong process when we record the error state. Track process identifiers in requests to always find the correct offender. v2: Track only user processes (Chris) Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
