- 13 Feb, 2015 38 commits
-
-
Damien Lespiau authored
v2: Reorder defines (Ben) v3: More bikesheds, this time re-ordering comments! (Chris) Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> [danvet: Resolve conflict.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
When enabling new platforms, we may not have any W/A to apply, especially that, now, a bunch of them have to be done from the ring. Signed-off-by:
-
Paulo Zanoni authored
Since the mapping from CRTCs to planes is fixed, looking at the CRTC is essentially the same as looking at the plane. Also, the next patches wil start using the frontbuffer_bits macros, and they take the pipe as the parameter instead of the plane, and this could differ on gens 2 and 3. Another nice thing is that we don't risk accidentally initializing things to PLANE_A if we don't set the value before it is used for the first time. But this shouldn't be a problem with the current code. V2: Rebase. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
This may save a few picoseconds on !HAS_FBC platforms. And it also satisfies my OCD. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Paulo Zanoni authored
.. because it would be a waste of time, so move the place where the check is done. Also, with this we won't risk printing "more than one pipe active, disabling compression" or "no output, disabling" when FBC is actually disabled. This patch also represents a small behavior difference when using i915.powersave=0: it is now exactly the same as i915.enable_fbc=0 on this part of the code. V2: Rebase. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Signed-off-by:
-
Nick Hoath authored
Add: WaEnableForceRestoreInCtxtDescForVCS v2: Add stepping check. v3: Fixed stepping check direction. Cleaned up indentation. Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
-
Nick Hoath authored
Fixed the stepping check on WaDisableDgMirrorFixInHalfSliceChicken5 to be for the correct SOC (Skylake) Signed-off-by:
-
Rob Clark authored
In DRM/KMS we are lacking a good way to deal with tiled/compressed formats. Especially in the case of dmabuf/prime buffer sharing, where we cannot always rely on under-the-hood flags passed to driver specific gem-create ioctl to pass around these extra flags. The proposal is to add a per-plane format modifier. This allows to, if necessary, use different tiling patters for sub-sampled planes, etc. The format modifiers are added at the end of the ioctl struct, so for legacy userspace it will be zero padded. v1: original v1.5: increase modifier to 64b v2: Incorporate review comments from the big thread, plus a few more. - Add a getcap so that userspace doesn't have to jump through hoops. - Allow modifiers only when a flag is set. That way drivers know when they're dealing with old userspace and need to fish out e.g. tiling from other information. - After rolling out checks for ->modifier to all drivers I've decided that this is way too fragile and needs an explicit opt-in flag. So do that instead. - Add a define (just for documentation really) for the "NONE" modifier. Imo we don't need to add mask #defines since drivers really should only do exact matches against values defined with fourcc_mod_code. - Drop the Samsung tiling modifier on Rob's request since he's not yet sure whether that one is accurate. v3: - Also add a new ->modifier[] array to struct drm_framebuffer and fill it in drm_helper_mode_fill_fb_struct. Requested by Tvrkto Uruslin. - Remove TODO in comment and add code comment that modifiers should be properly documented, requested by Rob. Cc: Rob Clark <robdclark@gmail.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Signed-off-by: Rob Clark <robdclark@gmail.com> (v1.5) Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Acked-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Ben Widawsky authored
Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ben Widawsky authored
The current code will both potentially print a WARN, and setup part of the PPGTT structure. Neither of these harm the current code, it is simply for clarity, and to perhaps prevent later bugs, or weird debug messages. Signed-off-by:
-
Ben Widawsky authored
In gen8, 32b PPGTT has always had one "pdp" (it doesn't actually have one, but it resembles having one). The #define was confusing as is, and using "PDPE" is a much better description. sed -i 's/GEN8_LEGACY_PDPS/GEN8_LEGACY_PDPES/' drivers/gpu/drm/i915/*.[ch] It also matches the x86 pagetable terminology: PTE = Page Table Entry - pagetable level 1 page PDE = Page Directory Entry - pagetable level 2 page PDPE = Page Directory Pointer Entry - pagetable level 3 page And in the near future (for 48b addressing): PML4E = Page Map Level 4 Entry v2: Expanded information about Page Directory/Table nomenclature. Cc: Daniel Vetter <daniel@ffwll.ch> CC: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Ben Widawsky authored
Signed-off-by:
-
Hoath, Nicholas authored
v2: Don't add WaHdcDisableFetchWhenMasked. Add stepping check for WaForceEnableNonCoherent Signed-off-by:
-
Hoath, Nicholas authored
Move Wa4x4STCOptimizationDisable to gen9_init_workarounds v2: rebase Signed-off-by:
-
Nick Hoath authored
Move WaEnableYV12BugFixInHalfSliceChicken7 to gen9_init_workarounds v2: Add stepping check. Signed-off-by:
-
Hoath, Nicholas authored
v2: Add stepping check for WaDisableSDEUnitClockGating. Signed-off-by:
-
Nick Hoath authored
This one doesn't have one of these nice cryptic names unfortunately. v2: Added missing register bitmap Signed-off-by:
-
Nick Hoath authored
Move WaDisableDgMirrorFixInHalfSliceChicken5 to gen9_init_workarounds v2: Added stepping check v3: Removed unused register bitmap Signed-off-by:
-
Hoath, Nicholas authored
v2: Dont add WaDisableThreadStallDopClockGating as not SKL WA. (Found by Damien Lespiau) Signed-off-by:
-
Hoath, Nicholas authored
Add Skylake stepping Revision IDs definitions. v1: Use existing revision id. Signed-off-by:
-
Hoath, Nicholas authored
Add framework for gen 9 HW WAs v1: Changed SOC specific WA function to gen 9 common function (Req: Damien Lespiau) Signed-off-by:
-
Damien Lespiau authored
We don't want to end up in a state where we track that the pipe has its primary plane enabled when primary plane registers are programmed with values that look possible but the plane actually disabled. Refuse to read out the fb state when the primary plane isn't enabled. Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Damien Lespiau authored
Right now, we get a warning when taking over the firmware fb: [drm:drm_atomic_plane_check] FB set but no CRTC with the following backtrace: [<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm] [<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm] [<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper] [<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm] [<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper] [<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper] [<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] [<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915] [<ffffffff813ad444>] fbcon_init+0x4f4/0x580 That's because we update the plane state with the fb from the firmware, but we never associate the plane to that CRTC. We don't quite have the full DRM take over from HW state just yet, so fake enough of the plane atomic state to pass the checks. v2: Fix the state on which we set the CRTC in the case we're sharing the initial fb with another pipe. (Matt) Signed-off-by: -
Damien Lespiau authored
At the moment we use crtc->base.primary->fb to hold the initial framebuffer allocation, disregarding if it's valid or not. This lead to believe we were actually updating the fb at this point, but it's not true and we haven't even called drm_framebuffer_init() on this fb. Instead, let's store the state in struct intel_initial_plane_config until we know we can reuse that framebuffer. Signed-off-by:
-
Damien Lespiau authored
Tvrtko noticed a new warning on boot: WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]() Call Trace: [<ffffffff8161f10c>] dump_stack+0x4f/0x7b [<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0 [<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20 [<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm] [<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915] [<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915] [<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915] [<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915] [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm] [<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm] [<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70 [<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915] [<ffffffff813ad59c>] pci_device_probe+0x7c/0x100 [<ffffffff81466aad>] driver_probe_device+0x16d/0x380 We cannot take a reference at this point, not before intel_framebuffer_init() and the underlying drm_framebuffer_init(). Introduced in: commit 706dc7b549175e47f23e913b7f1e52874a7d0f56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Feb 3 13:10:04 2015 -0800 drm/i915: Ensure plane->state->fb stays in sync with plane->fb v2: Don't move update_state_fb(). It was moved around because I originally put update_state_fb() in intel_alloc_plane_obj() before finding a better place. (Matt) Reviewed-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Damien Lespiau authored
The code look slightly better this way and will ease the next commit, changing where we take the fb pointer from. Signed-off-by:
-
Damien Lespiau authored
update_state_fb() at the end of intel_find_plane_obj() is misleading as it leads us to believe the update is done for all code path. A successful call to intel_alloc_plane_obj() will return and update_state_fb() is then only needed when we share a fb from another CRTC. Put the update() function there then. Signed-off-by:
-
Jani Nikula authored
The check for previously reserved stolen space size for FBC in i915_gem_stolen_setup_compression() did not take the compression threshold into account. Fix this by storing and comparing to uncompressed size instead. The bug has been introduced in commit 5e59f717 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Jun 30 10:41:24 2014 -0700 drm/i915: Try harder to get FBC Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88975Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Damien Lespiau authored
v2: leave intel_skylake_info alone (Rodrigo, Daniel) Signed-off-by:
-
Damien Lespiau authored
We need to have a separate GT3 struct intel_device_info to declare they have a second VCS. Let's start by splitting the PCI ids per-GT. Signed-off-by:
-
Satheeshakrishna M authored
This patch implements core logic of SKL display power well. v2: Addressed Imre's comments - Added respective DDIs under power well #1 and #2 - Simplified repetitive code in power well programming v3: Implemented Imre's comments - Further simplified power well programming - Made sure that PW 1 is enabled prior to PW 2 v4: Fix minor conflict with the the cherryview support (Damien) v5: Add the PLL power domain to the always on power well (Damien) v6: Disable BIOS power well (Imre) Use power well data for comparison (Imre) Put the PLL power domain into PW1 as its needed for CDCLK (Satheesh, Damien) v7: Addressed Imre's comments - Lowered the time out to 1ms - Added parantheses in macro - Moved debug message and fixed wait_for interval v8: - Add a WARN() when swiching on an unknown power well (Imre, done by Damien) - Whitespace fixes (spaces instead of tabs) (Damien) v9: (Imre, done by Damien) - Merge the register definitions with this patch - Merge the MISC IO power well in this patch v10: (Imre, done by Damien) - Define the Misc I/O power domains to be the power well 1 ones as Misc I/O needs to be enabled with PW1 - Added Transcoder A and VGA domains to PW 2 - Remove the MISC_IO power domains as well in the the always on domains definition - Move Misc I/O power well at the top of the power well list so it's turned on right after PW1. Reviewed-by:Imre Deak <imre.deak@intel.com> Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v3,v6,v7) Signed-off-by:
-
Matt Roper authored
plane->state->fb and plane->fb should always reference the same FB so that atomic and legacy codepaths have the same view of display state. In commit commit db068420560511de80ac59222644f2bdf278c3d5 Author: Matt Roper <matthew.d.roper@intel.com> Date: Fri Jan 30 16:22:36 2015 -0800 drm/i915: Keep plane->state updated on pageflip we already fixed one case where these two pointers could get out of sync. However it turns out there are a few other places (mainly dealing with initial FB setup at boot) that directly set plane->fb and neglect to update plane->state->fb. If we never do a successful update through the atomic pipeline, the RmFB cleanup code will look at the plane->state->fb pointer, which has never actually been set to a legitimate value, and try to clean it up, leading to BUG's. Add a quick helper function to synchronize plane->state->fb with plane->fb (and update reference counts accordingly) and call it everywhere the driver tries to manually set plane->fb outside of the atomic pipeline. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909Signed-off-by: -
Damien Lespiau authored
We already track this in the intel_info struct. Signed-off-by:
-
Shobhit Kumar authored
This isuue got introduced in - commit 24ee0e64 Author: Gaurav K Singh <gaurav.k.singh@intel.com> Date: Fri Dec 5 14:24:21 2014 +0530 drm/i915: Update the DSI enable path to support dual Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Replace the valleyview_set_rps() and gen6_set_rps() calls with intel_set_rps() which itself does the IS_VALLEYVIEW() check. The code becomes simpler since the callers don't have to do this check themselves. Most of the change was performe with the following semantic patch: @@ expression E1, E2, E3; @@ - if (IS_VALLEYVIEW(E1)) { - valleyview_set_rps(E2, E3); - } else { - gen6_set_rps(E2, E3); - } + intel_set_rps(E2, E3); Adding intel_set_rps() and making valleyview_set_rps() and gen6_set_rps() static was done manually. Also valleyview_set_rps() had to be moved a bit avoid a forward declaration. v2: Use a less greedy semantic patch Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by: -
Tvrtko Ursulin authored
Daniel Vetter spotted a bug while reviewing some of my refactoring in this are of the code. I'll quote: """ > @@ -9764,6 +9768,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc, > work->event = event; > work->crtc = crtc; > work->old_fb_obj = intel_fb_obj(old_fb); > + work->old_tiling_mode = to_intel_framebuffer(old_fb)->tiling_mode; Hm, that's actually an interesting bugfix - currently userspace could be sneaky and destroy the old fb immediately after the flip completes and the change the tiling of the underlying object before the unpin work had a chance to run (needs some fudgin with rt prios to starve workers to make this work though). Imo the right fix is to hold a reference onto the fb and not the underlying gem object. With that tiling is guaranteed not to change. """ This patch tries to implement the above proposed change. Signed-off-by:
-
Matt Roper authored
There are two sets of helper functions provided by the DRM core that can implement the .update_plane() and .disable_plane() hooks in terms of a driver's atomic entrypoints. The transitional helpers (which we have been using so far) create a plane state and then use the plane's atomic entrypoints to perform the atomic begin/check/prepare/commit/finish sequence on that single plane only. The full atomic helpers create a top-level atomic state (which is capable of holding multiple object states for planes, crtc's, and/or connectors) and then passes the top-level atomic state through the full "atomic modeset" pipeline. Switching from the transitional to full helpers here shouldn't result in any functional change, but will enable us to exercise/test more of the internal atomic pipeline with the legacy API's used by existing applications. Signed-off-by:
-
Matt Roper authored
Until all drivers have transitioned to atomic, the framebuffer associated with a plane is tracked in both plane->fb (for legacy) and plane->state->fb (for all the new atomic codeflow). All of our modeset and plane updates use drm_plane->update_plane(), so in theory plane->fb and plane->state->fb should always stay in sync and point at the same thing for i915. However we forgot about the pageflip ioctl case, which currently only updates plane->fb and leaves plane->state->fb at a stale value. Surprisingly, this doesn't cause any real problems at the moment since internally we use the plane->fb pointer in most of the places that matter, and on the next .update_plane() call, we use plane->fb to figure out which framebuffer to cleanup. However when we switch to the full atomic helpers for update_plane()/disable_plane(), those helpers use plane->state->fb to figure out which framebuffer to cleanup, so not having updated the plane->state->fb pointer causes things to blow up following a pageflip ioctl. The fix here is to just make sure we update plane->state->fb at the same time we update plane->fb in the pageflip ioctl. Signed-off-by:
-
- 03 Feb, 2015 1 commit
-
-
Daniel Vetter authored
You can _never_ assert that a lock is not held, except in some very restricted corner cases where it's guranteed that your code is running single-threade (e.g. driver load before you've published any pointers leading to that lock). In addition the early return breaks a bunch of testcases since with highly concurrent hangcheck stress tests the reset fails to work and the test doesn't recover and time out. This regression has been introduced in commit b8d24a06 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Wed Jan 28 17:03:14 2015 +0200 drm/i915: Remove nested work in gpu error handling Aside: It is possible to check whether a given task doesn't hold a lock, but only when lockdep is enabled, using the lockdep_assert_held stuff. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908Reviewed-by:
-
- 30 Jan, 2015 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
