- 25 Sep, 2015 1 commit
-
-
Geliang Tang authored
Leak a task reference in i915_ppgtt_info(), add put_task_struct() to fix it. Introduced by commit 1c60fef5 Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:30 2013 -0800 drm/i915: Dump all ppgtt Signed-off-by:
Geliang Tang <geliangtang@163.com> [danvet: Add note provided by Jani about which commit introduced this issue.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 Sep, 2015 1 commit
-
-
Chris Wilson authored
When preallocating a stolen object during early initialisation, we may be running before we have setup the the global GTT VM state, in particular before we have initialised the range manager and associated lists. As this is the case, we defer binding the stolen object until we call i915_gem_setup_global_gtt(). Not only should we defer the binding, but we should also defer the VM list manipulation. Fixes regression uncovered by commit a2cad9df Author: Michał Winiarski <michal.winiarski@intel.com> Date: Wed Sep 16 11:49:00 2015 +0200 drm/i915/gtt: Do not initialize drm_mm twice. Whilst I am here remove the duplicate work leaving dangling pointers from the error path... v2: Typos galore before coffee. Reported-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92099Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Michał Winiarski <michal.winiarski@intel.com> Tested-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 23 Sep, 2015 38 commits
-
-
Nick Hoath authored
Remove extraneous request cancel in request allocation failure path in intel_lr_context_deferred_alloc (Tvrtko Ursulin) Regression from: commit e84fe803 Author: Nick Hoath <nicholas.hoath@intel.com> Date: Fri Sep 11 12:53:46 2015 +0100 drm/i915: Split alloc from init for lrc Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
v2: Rebase. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
Just adding the rotated UV plane at the end of the rotated Y plane. v2: Rebase. Signed-off-by:
-
Tvrtko Ursulin authored
By providing a start offset into the source array of pages, and returning the end position in the scatter-gather table, we will be able to append the UV plane to the rotated mapping in later patches. v2: Rebase. Signed-off-by:
-
Tvrtko Ursulin authored
This will be needed for NV12 support. v2: Rebase. Signed-off-by:
-
Arun Siluvery authored
Cc: Nick Hoath <nicholas.hoath@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ville Syrjälä authored
FIXME: Should there be a WARN(i != 9) or something, or what does the entry 9 comment mean? Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
intel_sdvo_select_ddc_bus() and intel_sdvo_select_i2c_bus() have no used for the passed in 'reg', so just drop it. Signed-off-by:
-
Ville Syrjälä authored
Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT and DEVICE_TYPE_DIGITAL_OUTPUT when trying to determine the presence of eDP based on the VBT child device type. Apparently a significant portion of VLV systems have these bits set incorrectly, and so we currently fail to detect eDP on said systems. This is based on an earlier patch [1] from Andreas Lampersperger. Instead of ignoring the bits just on VLV as was done in the orignal patch, we now ignore them for all platforms. We should still have enough bits in there to avoid false positives (unless the VBT is totally bonkers). Quoting the orignal patch: > When the i915.ko identify an eDP output on a valleyview > board, it should be more slackly. The reason for that is, > that BIOS DATA TABLES generated with intel BMP (Binary > Modification Program) do not set bits for NOT_HDMI or > DIGITAL_OUTPUT on the device type. Due to Adolfo > Sanchez from Intel EMGD, this is not possible. > To solve this problem and enable i915.ko on embedded > vlv boards with eDP, we ignore this two bits. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-June/069416.html Cc: Andreas Lampersperger <lampersperger.andreas@heidenhain.de> Cc: "Sanchez, AdolfoX" <adolfox.sanchez@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We don't support eDP on g4x, so let's not even look at the VBT to determine the port type, just in case the VBT is bonkers on some g4x machines and indicates the precense of eDP. Signed-off-by:
-
Egbert Eich authored
An HPD interrupt may fire while we are in a function that changes the PORT_HOTPLUG_EN register - especially when an HPD interrupt storm occurs. Since the interrupt handler changes the enabled HPD lines when it detects such a storm the read-modify-write cycles may interfere. To avoid this, shiled the rmw cycles with IRQ save spinlocks. Changes since v1: - Implement a function which takes care of accessing PORT_HOTPLUG_EN. Signed-off-by:
Egbert Eich <eich@suse.de> Signed-off-by:
-
Dongwon Kim authored
We can calculate BXT values correctly from GFX fuse values without hardcoding special limits. Cc: Imre Deak <imre.deak@intel.com> Cc: Matthew D Roper <matthew.d.roper@intel.com> Signed-off-by:
Dongwon Kim <dongwon.kim@intel.com> Reviewed-by:
-
Michał Winiarski authored
It would be initialized just moments later by i915_init_vm. Rearrange the code such that i915_init_vm() is next to its callers inside i915_gem_gtt (and so we can make it static). After removing the dance around the files, it is clear that we are repeating some work inside the initializers (such as calling drm_mm_init() multiple times), so take advantage of the refactor to also remove some redundant code and clean up the interface. v2: Commit msg update, s/i915_init_vm/i915_address_space_init, move to i915_gem_gtt.c, init address_space during i915_gem_setup_global_gtt for ggtt. v3: Do not init global_link - we are adding it to vm_list moments later, make i915_address_space_init static, use OOP style parameter order. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: -
Ville Syrjälä authored
Finally managed to dig up enough hints as to where the stolen reserved stuff lives on ctg/elk. So add the code to decode it. This was a combination of old chipset specs, diggin up an old elk grits release with an ctg/elk AubLoad etc. This was only tested on an elk as I don't have a ctg here unfortunately. This leaves ilk as the only platform that doesn't have a way to detect this stuff. Looking at the register contents on my ilk, it might be that the elk way works there too, but I can't be sure since I can't affect the amount of reserved memory on that machine, and if I am to trust the register contents, by default it would reserve 0 bytes. v2: s/WARN_ON_ONCE/WARN_ON/ since it's in one time init code anyway (Paulo) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
I only tested this on BDW and SKL, but since the register description is the same ever since gen4, let's assume that all gens take the same register format. If that's not true, then hopefully someone will bisect a bug to this patch and we'll fix it. Notice that the wrong fence offset register just means that the hardware tracking will be wrong. Testcases: - igt/kms_frontbuffer_tracking/fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt - igt/kms_frontbuffer_tracking/fbc-2p-primscrn-pri-shrfb-draw-mmap-gtt v2: - Add intel_crtc->adjusted_{x,y} so this code can work independently of intel_gen4_compute_page_offset(). (Ville). - This version also works on SKL. Signed-off-by: -
Paulo Zanoni authored
This commit is essentially a rewrite of "drm/i915: Check pixel format for fbc" from Ville Syrjälä. The idea is the same, but the code is different due to all the changes that happened since his original patch. So any bugs are due to my bad rewrite. v2: - Drop the alpha formats (Ville). v3: - Drop the stale comment (Ville). Testcases: igt/kms_frontbuffer_tracking/*fbc*-${format_name}-draw-* Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: -
Paulo Zanoni authored
This WA is only for HSW/BDW. Reviewed-by:
-
Paulo Zanoni authored
The spec says the register should have that value for the entire time that FBC is enabled, so apply the WA before we enable FBC. Notice that we also have this WA for ILK/SNB, but it is implemented at init_clock_gating(). I could move the IVB/HSW/BDW WA code to init_clock_gating() too, but since we recently had some complaints about WAs not staying after being set, I'm going to play safe and keep this here for now. Reviewed-by:
-
Paulo Zanoni authored
BSpec says we shouldn't enable FBC on HSW/BDW when the pipe pixel rate exceeds 95% of the core display clock. v2: - HSW also needs the WA (Ville). - Add the WA name (Ville). - Use the current cdclk (Ville). Signed-off-by:
-
Paulo Zanoni authored
And also print the threshold. I was surprised to see a log message claiming the CFB size was 32mb when there was less than 24mb available for it. Reviewed-by:
-
Paulo Zanoni authored
The FBC hardware for these platforms doesn't have access to the bios_reserved range, so it always assumes the maximum (8mb) is used. So avoid this range while allocating. This solves a bunch of FIFO underruns that happen if you end up putting the CFB in that memory range. On my machine, with 32mb of stolen, I need a 2560x1440 mode for that. Testcase: igt/kms_frontbuffer_tracking/fbc-* (given the right setup) Signed-off-by:
-
Paulo Zanoni authored
Don't allow FBC for cases where the spec says we can't FBC. v2: - Just WARN_ON() the strides that should have been caught earlier (Daniel) - Make it a new function since I expect this to grow more. v3: - Document which IGT test is exercised by this. v4: - Implement the restrictions for gens 2-6 too (Ville). - Fix off-by-one mistake (Ville). Testcase: igt/kms_frontbuffer_tracking/fbc-badstride Signed-off-by: -
Paulo Zanoni authored
Always update the currrent crtc, fb and vertical offset after calling enable_fbc. We were forgetting to do so along the failure paths when enabling fbc synchronously. Fix this with a new helper to enable_fbc() and update the state simultaneously. v2: Improve commit message (Chris). v3: Constify struct drm_framebuffer (Ville). Reviewed-by:
-
Maarten Lankhorst authored
The scaler_id in intel_pipe_config_compare should not be checked when adjusting in intel_pipe_config_compare. The hw scaler id may be changed in intel_update_pipe_config. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
Sagar Arun Kamble authored
Cc: Alex Dai <yu.dai@intel.com> Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Cc: Akash Goel <akash.goel@intel.com> Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by:
Alex Dai <yu.dai@intel.com> Signed-off-by:
-
Sagar Arun Kamble authored
Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Cc: Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Sagar Arun Kamble authored
Enable TO mode for RC6 for SKL till D0 and BXT till A0. Cc: Tom O'Rourke <Tom.O'Rourke@intel.com> Cc: Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Sagar Arun Kamble authored
WaRsDisableCoarsePowerGating: Coarse Power Gating (CPG) needs to be disabled for platforms prior to BXT B0 and SKL GT3/GT4 till E0. v2: Added GT3/GT4 Check. Change-Id: Ia3c4c16e050c88d3e259f601054875c812d69c3a Signed-off-by:
-
Sagar Arun Kamble authored
It will be usefull to specify w/a that affects only SKL GT3 and GT4. Signed-off-by:
-
Jesse Barnes authored
Looks like this was introduced in: commit d1675198 Author: Alex Dai <yu.dai@intel.com> Date: Wed Aug 12 15:43:43 2015 +0100 drm/i915: Integrate GuC-based command submission This patch assumed LRC contexts and HWS layout, which is incorrect on platforms without execlists. This can lead to a crash in GPU error state readout on those platforms. I don't see a bug filed for this, but there may be one that I haven't found. v2: fixup offset handling for error capture fix (Dave) Cc: Alex Dai <yu.dai@intel.com> Reviewed-by:
Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Ville Syrjälä authored
intel_modeset_readout_hw_state() seems like the more appropriate place for populating the scanline_offset and timestamping constants than intel_sanitize_crtc() since they are basically part of the state we read out. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
