- 08 Jul, 2014 5 commits
-
-
Oscar Mateo authored
This is an Execlists preparatory patch, since they make context ID become an overloaded term: - In the software, it was used to distinguish which context userspace was trying to use. - In the BSpec, the term is used to describe the 20-bits long field the hardware uses to it to discriminate the contexts that are submitted to the ELSP and inform the driver about their current status (via Context Switch Interrupts and Context Status Buffers). Initially, I tried to make the different meanings converge, but it proved impossible: - The software ctx->id is per-filp, while the hardware one needs to be globally unique. - Also, we multiplex several backing states objects per intel_context, and all of them need unique HW IDs. - I tried adding a per-filp ID and then composing the HW context ID as: ctx->id + file_priv->id + ring->id, but the fact that the hardware only uses 20-bits means we have to artificially limit the number of filps or contexts the userspace can create. The ctx->user_handle renaming bits are done with this Cocci patch (plus manual frobbing of the struct declaration): @@ struct intel_context c; @@ - (c).id + c.user_handle @@ struct intel_context *c; @@ - (c)->id + c->user_handle Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE and change the type to unsigned 32 bits. v2: s/handle/user_handle and change the type to uint32_t as suggested by Chris Wilson. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Signed-off-by:Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Oscar Mateo authored
We have already advanced that Logical Ring Contexts have their own kind of backing objects, but everything will be better explained in the Execlists series. For now, suffice it to say that the current backing object is only ever used with the render ring, so we're making this fact more explicit (which is a good reason on its own). As for the is_initialized flag, we only use to signify that the render state has been initialized (a.k.a. golden context, a.k.a. null context). It doesn't mean anything for the other engines, so make that distinction obvious. Done with the following Coccinelle patch (plus manual frobbing of the struct): @@ struct intel_context c; @@ - (c).obj + c.legacy_hw_ctx.rcs_state @@ struct intel_context *c; @@ - (c)->obj + c->legacy_hw_ctx.rcs_state @@ struct intel_context c; @@ - (c).is_initialized + c.legacy_hw_ctx.initialized @@ struct intel_context *c; @@ - (c)->is_initialized + c->legacy_hw_ctx.initialized This Execlists prep-work patch has been suggested by Chris Wilson and Daniel Vetter separately. Initially, it was two separate patches: drm/i915: Rename ctx->obj to ctx->rcs_state drm/i915: Make it obvious that ctx->id is merely a user handle Signed-off-by: -
Oscar Mateo authored
This is preparatory work for Execlists: we plan to use it later to allocate our own context objects (since Logical Ring Contexts do not have the same kind of backing objects). No functional changes. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Imre Deak authored
To achieve further power savings during system freeze (aka connected standby, or s0ix) we have to send a PCI_D1 opregion notification. As the information about the state we're entering (system freeze, suspend to ram or suspend to disk) is only available through the ACPI subsystem, make this support depend on the relevant kconfig option. Things will still work if this option isn't set, albeit with less than optimial power saving. This also fixes a compile breakage when the option is not set introduced in commit e5747e3a Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 12 08:35:47 2014 -0700 drm/i915: send proper opregion notifications on suspend/resume Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Chris Wilson authored
Make the assumption that media workloads are not as latency sensitive for __wait_seqno, and that upclocking the GPU does not affect the BLT engine. Under that assumption, we only wait to forcibly upclock the GPU when we are stalling for results from the render pipeline. Signed-off-by:
-
- 07 Jul, 2014 35 commits
-
-
Jesse Barnes authored
With the new checks in place, we can see we're doing things backwards, so fix them up per the spec. Signed-off-by:
-
Rodrigo Vivi authored
Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ben Widawsky authored
As Ville points out, it's possible/probable we don't actually need this. Potentially, this validates the letter of the spec, and not the spirit. Ville: > I discussed this on irc w/ Ben, and I was suggesting we don't need to > poll. Polling apparently can be used as a workaround for certain > hardware issues, but it looks like those issues shouldn't affect us, > for the momemnt at least. So my suggestion was to try w/o polling > first (since there could be some power cost to polling) and add the > poll bit if problems arise. Rodrigo: Spec suggests this as an W/A for GT3. However semaphores didn't worked in my BDW GT2 on Signal Mode. So pool mode is definitely needed. Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
Simple debugfs file to display the current state of semaphores. This is useful if you want to see the state without hanging the GPU. NOTE: This patch is optional to the series. NOTE2: Like the GPU error state collection, the reads are currently incoherent. v2 (Rodrigo): * Iterate only on active rings. * s/ring_buffer/engine_cs. Reviewed-by:
-
Ben Widawsky authored
Since the semaphore information is in an object, just dump it, and let the user parse it later. NOTE: The page being used for the semaphores are incoherent with the CPU. No matter what I do, I cannot figure out a way to read anything but 0s. Note that the semaphore waits are indeed working. v2: Don't print signal, and wait (they should be the same). Instead, print sync_seqno (Chris) v3: Free the semaphore error object (Chris) v4: Fix semaphore offset calculation during error state collection (Ville) v5: VCS2 rebase Make semaphore object error capture coding style consistent (Ville) Do the proper math for the signal offset (Ville) v6: Fix small conflicts on rebase and s/ring_buffer/engine_cs (Rodrigo) Reviewed-by:
-
Ben Widawsky authored
v2: s/ring_buffer/engine_cs (Rodrigo) Reviewed-by:
-
Rodrigo Vivi authored
Ipehr just carries Dword 0 and on Gen 8, offsets are located on Dword 2 and 3 of MI_SEMAPHORE_WAIT. This implementation was based on Ben's work and on Ville's suggestion for Ben Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to wait on is all well defined by the table in the previous patch. There is nothing else different from previous GEN's semaphore synchronization code. v2: Update macros to not require the other ring's ring->id (Chris) v3: Add missing VCS2 gen8_ring_wait init besides s/ring_buffer/engine_cs (Rodrigo) Reviewed-by: -
Ben Widawsky authored
Semaphore signalling works similarly to previous GENs with the exception that the per ring mailboxes no longer exist. Instead you must define your own space, somewhere in the GTT. The comments in the code define the layout I've opted for, which should be fairly future proof. Ie. I tried to define offsets in abstract terms (NUM_RINGS, seqno size, etc). NOTE: If one wanted to move this to the HWSP they could. I've decided one 4k object would be easier to deal with, and provide potential wins with cache locality, but that's all speculative. v2: Update the macro to not need the other ring's ring->id (Chris) Update the comment to use the correct formula (Chris) v3: Move the macros the ringbuffer.h to prevent churn in next patch (Ville) v4: Fixed compilation rebase conflict commit 1ec9e26d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Feb 14 14:01:11 2014 +0100 drm/i915: Consolidate binding parameters into flags v5: VCS2 rebase Replace hweight_long with hweight32 v6 (Rodrigo): * Add missed VC2 gen8 ring signal init * fixing conflicst on rebase * minor fixes on address table * remove WARN_ON Reviewed-by:
-
Ben Widawsky authored
With the ring mask we now have an easy way to know the number of rings in the system, and therefore can accurately predict the number of dwords to emit for semaphore signalling. This was not possible (easily) previously. There should be no functional impact, simply fewer instructions emitted. While we're here, simply do the round up to 2 instead of the fancier rounding we did before, which rounding up per mbox, ie 4. This also allows us to drop the unnecessary MI_NOOP, so not really 4, 3. v2: Use 3 dwords instead of 4 (Ville) Do the proper calculation to get the number of dwords to emit (Ville) Conditionally set .sync_to when semaphores are enabled (Ville) v3: Rebased on VCS2 Replace hweight_long with hweight32 (Ville) v4: Pull out the accidentally squashed hunk from the next patch after rebase (Daniel). v5: Fix conflict after rebase (Rodrigo) Reviewed-by:
-
Ben Widawsky authored
Gen8 has already had some differentiation with how it handles rings. Semaphores bring yet more differences, and now is as good a time as any to do the split. Also, since gen8 doesn't actually use semaphores up until this point, put the proper "NULL" values in for the mbox info. v2: v1 had a stale commit message v3: Move everything in the is_semaphore_enabled() check v4: VCS2 rebase Remove double assignment of signal in render ring (Ville) v5: Adding missed VCS2 signal init on gen8+ (Rodrigo) Reviewed-by:
-
Rodrigo Vivi authored
ring index calculation table was out of date after other rings were added, although the formula is flexible and scale when adding new rings. So this patch just update the comments and add a brief explanation why to use sync_seqno[ring index]. Signed-off-by:
-
Rodrigo Vivi authored
It just fix a typo. v2: removing underscore to let this like all other ring names (Oscar) Cc: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by (v1): Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by:
-
John Harrison authored
The 'i915_driver_preclose()' function has a parameter called 'file_priv'. However, this is misleading as the structure it points to is a 'drm_file' not a 'drm_i915_file_private'. It should be named just 'file' to avoid confusion. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
-
Daniel Vetter authored
The always-on power well pixel path on haswell is routed such that it bypasses the panel fitter when we use is. Which means the pfit CRC source won't work in that configuration. Add a new disallow-bypass flags to the pfit pipe config state and set it when we want to use the pf CRC. Results in a bit of flicker, but should get the job done. We'll also undo do it afterwards to make sure other tests arent' negatively affected. Totally untested due to lack of hsw laptops around here. v2: s/disallow_bypass/force_power_well_on/ to avoid a double negative (Damien). v3: force_thru because roadsigns. v4: Don't forget the power wells! Also note that until the runtime pm for DPMS series is fully merged the simple disable/enable trick won't work since the ->crtc_mode_set callback is still required to do nasty things. This stuff is tricky, but I think by both fixing up get_crtc_power_domains and the debugfs wa code we should always grab/drop the additional power well correctly. v5: Wrap in () as suggested by Damien to avoid setting reserved values for the edp transcoder path on bdw+ References: https://bugs.freedesktop.org/show_bug.cgi?id=72864 Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Tested-by:
-
Michel Thierry authored
The workaround to limit SDE poly depth FIFO to 2 is not applied because 3D Chicken-3 mask bit is not set. WaLimitSizeOfSDEPolyFifo is only for BDW-A and could be removed. Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Egbert Eich authored
Since the root cause is understood now and with the fix commit 564ed191 Author: Imre Deak <imre.deak@intel.com> Date: Fri Jun 13 14:54:21 2014 +0300 drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode in place the magic for G4x chipsets introduced with commit commit 61bc95c1 Author: Egbert Eich <eich@suse.com> Date: Mon Mar 4 09:24:38 2013 -0500 DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. to avoided occasional screen blanking on mode changes can finally be removed. It's been verified that Imre's fix also resolves the said issue. Signed-off-by:
Egbert Eich <eich@suse.de> Tested-by:
Stefan Dirsch <sndirsch@suse.de> Signed-off-by:
-
Rodrigo Vivi authored
As pointed out before we don't have a reliable way to read back ips status on BDW without the risk to disable it when reading. However now we are pretending that IPS on BDW is always on and getting people confused about it. So this patch allows people to know if ips was ever attempted to be enabled. Even if the current status is impossible to be ascertain. v2: (spotted by Paulo): * A version that at least compiles * with more clear messages * let Cheryview on the safe side until we aren't sure that checking ips state on ips won't disable it. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We're forgetting to unpin the last_context from the ggtt at GPU reset time. This leads to the vma pin_count leaking at every reset if the last context wasn't the ring default context. Further use of the same context will trigger the pin_count check in i915_gem_object_pin() and userspace will be faced with EBUSY as a result. This plaques kms_flip rather badly since it performs lots of resets, and every fd has its own default context these days. Fix the problem by properly unpinning the last context at reset. This regression seems to back to commit acce9ffa Author: Ben Widawsky <ben@bwidawsk.net> Date: Fri Dec 6 14:11:03 2013 -0800 drm/i915: Better reset handling for contexts Testcase: igt/gem_ctx_exec/reset-pin-leak Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Dave Airlie authored
The digital ports from Ironlake and up have the ability to distinguish between long and short HPD pulses. Displayport 1.1 only uses the short form to request link retraining usually, so we haven't really needed support for it until now. However with DP 1.2 MST we need to handle the short irqs on their own outside the modesetting locking the long hpd's involve. This patch adds the framework to distinguish between short/long to the current code base, to lay the basis for future DP 1.2 MST work. This should mean we get better bisectability in case of regression due to the new irq handling. v2: add GM45 support (untested, due to lack of hw) Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Todd Previte <tprevite@gmail.com> [danvet: Fix conflicts in i915_irq.c with Oscar Mateo's irq handling race fixes and a trivial one in intel_drv.h with the psr code.] Signed-off-by:
-
Imre Deak authored
Blanking/unblanking the console in a loop on an Asus T100 sometimes leaves the console blank. After some digging I found that applying commit 61bc95c1 Author: Egbert Eich <eich@suse.com> Date: Mon Mar 4 09:24:38 2013 -0500 DRM/i915: On G45 enable cursor plane briefly after enabling the display plane. fixed VLV too. In my case the problem seemed to happen already during the previous crtc disabling and went away if I disabled self-refresh mode before disabling the primary plane. The root cause for this is that updates from the shadow to live plane control register are blocked at vblank time if the memory self-refresh mode (aka max-fifo mode on VLV) is active at that moment. The controller checks at frame start time if the CPU is in C0 and the self-refresh mode enable bit is set and if so activates self-reresh mode, otherwise deactivates it. So to make sure that the plane truly gets disabled before pipe-off we have to: 1. disable memory self-refresh mode 2. disable plane 3. wait for vblank 4. disable pipe 5. wait for pipe-off v2: - add explanation for the root cause from HW team (Cesar Mancini et al) - remove note about the CPU C7S state, in my latest tests disabling it alone didn't make a difference - add vblank between disabling plane and pipe (Ville) - apply the same workaround for all gmch platforms (Ville) Signed-off-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Atm it's possible that we enable the memory self-refresh mode before the watermark levels used by this mode are programmed with valid values. So move the enabling after we programmed the WM levels. Signed-off-by:
-
Imre Deak authored
This functionality will be also needed by an upcoming patch, so factor it out. As a bonus this also makes things a bit more uniform across platforms. Note that this also changes the register read-modify-write to a simple write during disabling. This is what we do during enabling anyway and according to the spec all the relevant bits are reserved-MBZ or reserved with a 0 default value. v2: - unchanged v3: - fix missing cxsr disabling on pineview (Deepak) Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Now that the CMNRESET deassert is part of the cmnlane power well, intel_reset_dpio() is called too late to make any difference. We've deasserted CMNRESET by that time, and so the off+on toggle w/a will never kick in. Move the workaround to intel_power_domains_init_hw() where it gets called before we enable the init power domain. Signed-off-by:
-
Ville Syrjälä authored
Remove the clutter in __vlv_set_power_well() by moving the cmnlane handling into custom enable/disable hooks for the cmnlane. Signed-off-by:
-
Ville Syrjälä authored
We have a slightly different way of readoing out the cdclk in gmbus_set_freq(). Kill that and just call .get_display_clock_speed(). Also need to remove the GMBUSFREQ update from intel_i2c_reset() since that gets called way too early. Let's do it in intel_modeset_init_hw() instead, and also pull the initial vlv_cdclk_freq update there from init_clock gating. Signed-off-by:
-
Ville Syrjälä authored
If someone is interested in the current cdclk frquency it should be stable and not in process of changing frquency. Warn if the current and requested cdclk don't match in .get_display_clock_spee() on vlv. Signed-off-by:
-
Ville Syrjälä authored
VLV Punit doesn't support the 400MHz cdclk option, so we bypass the Punit and poke at CCK directly. However we forgot to wait for the frequeency change to complete. Poll the CCK clock status to make sure the clock has changed before we fire up any pipes. Signed-off-by:
-
Ville Syrjälä authored
Drop the cdclk frequency to 200MHz on vlv when all pipes are off. In theory we should be able to use 200MHz also when the pixel clock is at most 90% of 200MHz. However in practice all we seem to get is a solid color picture or an otherwise corrupted display. Signed-off-by:
-
Ville Syrjälä authored
Depending on the HPLL frequency one of the supported cdclk frquencies is either 320MHz or 333MHz. Figure out which one it is to accurately pick the minimal required cdclk. This would also avoid a warning from the cdclk code where it compares the actual cdclk read out from the hardware with a value that was calculated using valleyview_calc_cdclk(). Signed-off-by:
-
Ville Syrjälä authored
We have a standard hook for reading out the current cdclk. Move the VLV code from valleyview_cur_cdclk() to .get_display_clock_speed(). Signed-off-by:
-
Ville Syrjälä authored
Avoid using magic values for CCK frequency bits. Also the mask we were using for the requested frequency was one bit too short. Fix it up. Note: This also fixes the #define for a mask (spotted by Jesse in his review). Signed-off-by:
-
Ville Syrjälä authored
Use kHz units in vlv cdclk code since that's more customary. Also replace the precomputed 90% values with *9/10 computation for extra clarity. Signed-off-by:
-
Daniel Vetter authored
Due to Dave's vacation drm-next hasn't opened yet for 3.17 so I couldn't move my drm-intel-next queue forward yet like I usually do. Just pull in the latest upstream -rc to unblock patch merging - I don't want to needlessly rebase my current patch pile really and void all the testing we've done already. Signed-off-by: -
Daniel Vetter authored
Jani apparently didn't rebase onto latest drm-intel-next so a merge is in order. Signed-off-by:
-
