- 19 Dec, 2019 7 commits
-
-
Jani Nikula authored
Fix several issues with DSC power domains that did not take DSI transcoders into account: - On TGL+ we need to use PW2 for DSC on pipe A, not transcoder A. There is no longer an eDP transcoder, but there are two DSI transcoders which may be connected to pipe A. - On TGL+ we need to use the pipe, not transcoder, power domains for DSC on pipes other than A. Again, there are DSI transcoders. - On ICL we need to use PW2 for DSC also for DSI transcoders, not just for the eDP transcoder. Using is_pipe_dsc() also adds the warning about ICL pipe A DSC, which does not exist. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191212134728.18432-1-jani.nikula@intel.com
-
Jani Nikula authored
The check for cpu_transcoder != TRANSCODER_A is more magic than necessary, and potentially misleading. Before TGL, DSC is supported on pipe A if, and only if, it's used with eDP or DSI transcoders. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Jani Nikula authored
ICL eDP and DSI transcoders have a DSC engine separate from the pipe. Abstract the register selection and fix it for ICL. Add a warning for pipe A DSC on ICL; it does not exist. Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Andrzej Pietrasiewicz authored
Use the ddc pointer provided by the generic connector. Signed-off-by:
Andrzej Pietrasiewicz <andrzej.p@collabora.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
-
Lucas De Marchi authored
Pass the correct variable as argument. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Clinton Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217230529.25092-3-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Instead of "ungated" use the same name for the variable as the bitfield, making it clearer what's the intent of the checks. Signed-off-by:
-
Lucas De Marchi authored
This allows us to isolate reading and writing to the ICL_DPCLKA_CFGCR0 during the sanitize phase. Signed-off-by:
-
- 18 Dec, 2019 17 commits
-
-
Chris Wilson authored
When doing our global park, we like to be a good citizen and shrink our slab caches (of which we have quite a few now), but each kmem_cache_shrink() incurs a stop_machine() and so ends up being quite expensive, causing machine-wide stalls. While ideally we would like to throw away unused pages in our slab caches whenever it appears that we are idling, doing so will require a much cheaper mechanism. In the meantime use a delayed worked to impose a rate-limit that means we have to have been idle for more than 2 seconds before we start shrinking. References: https://gitlab.freedesktop.org/drm/intel/issues/848Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218094057.3510459-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Only signal the breadcrumbs from inside the irq_work, simplifying our interface and calling conventions. The micro-optimisation here is that by always using the irq_work interface, we know we are always inside an irq-off critical section for the breadcrumb signaling and can ellide save/restore of the irq flags. Signed-off-by:
-
Tvrtko Ursulin authored
Avoid rc6 counter going backward in close to 0% RC6 scenarios like: 15.005477996 114,246,613 ns i915/rc6-residency/ 16.005876662 667,657 ns i915/rc6-residency/ 17.006131417 7,286 ns i915/rc6-residency/ 18.006615031 18,446,744,073,708,914,688 ns i915/rc6-residency/ 19.007158361 18,446,744,073,709,447,168 ns i915/rc6-residency/ 20.007806498 0 ns i915/rc6-residency/ 21.008227495 1,440,403 ns i915/rc6-residency/ There are two aspects to this fix. First is not assuming rc6 value zero means GT is asleep since that can also mean GPU is fully busy and we do not want to enter the estimation path in that case. Second is ensuring monotonicity on the estimation path itself. I suspect what is happening is with extremely rapid park/unpark cycles we get no updates on the real rc6 and therefore have to careful not to unconditionally trust use last known real rc6 when creating a new estimation. v2: * Simplify logic by not tracking the estimate but last reported value. Signed-off-by: -
Ville Syrjälä authored
Move all of haswell_crtc_disable() into the encoder .post_disable() hooks. Now we're left with just calling the .disable() and .post_disable() hooks back to back. I chose to move the code into the .post_disable() hook instead of the .disable() hook as most of the sequence is currently implemented in the .post_disable() hook. We should collapse it all down to just one hook and then the encoders can drive the modeset sequence fully. But that may need some further refactoring as we currently call the ddi .post_disable() hook from mst code and we can't just replace that with a call to the ddi .disable() hook. Should also follow up with similar treatment for the enable sequence but let's start here where it's easier. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191213195217.15168-5-ville.syrjala@linux.intel.comReviewed-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
To make life easier in the future let's pass the old crtc state to intel_crtc_vblank_off() just like we already do for its counterpart intel_crtc_vblank_on(). Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
To make life easier in the future let's pass the old crtc state to skylake_scaler_disable() just like we already do for for its ancestor ironlake_pfit_disable(). Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
HSW+ platforms call encoder .post_disable() and .post_pll_disable() back to back. And since we don't even disable the PLL in between let's just move everything into .post_disable(). intel_dp_mst does forward the .post_disable() call to intel_ddi at the very end of its own .post_disable() hook, so this time MST I shouldn't even break MST by accident. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Remove the pointless vfunc detour for hsw_fdi_link_train() and just call it directly. Also pass the encoder in so we can nuke the silly encoder loop within. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
For the sake of symmetry with the crtc stuff let's add a helper to reset the plane state to sane default values. For the moment this only gets caller from the plane init. Signed-off-by:
-
Ville Syrjälä authored
We have a few places where we want to reset a crtc state to its default values. Let's add a helper for that. We'll need the new __drm_atomic_helper_crtc_state_reset() helper for this to allow us to just reset the state itself without clobbering the crtc->state pointer. And while at it let's zero out the whole thing, except a few choice member which we'll mark as "invalid". And thanks to this we can now nuke intel_crtc_init_scalers(). Signed-off-by:
-
Ville Syrjälä authored
We already have alloc/free helpers for planes, add the same for crtcs. The main benefit is we get to move all the annoying state initialization out of the main crtc_init() flow. Signed-off-by:
-
Ville Syrjälä authored
Let's get rid of the redundant intel_ prefix on our variables. Signed-off-by:
-
Ville Syrjälä authored
Annoyingly __drm_atomic_helper_crtc_reset() does two totally separate things: a) reset the state to defaults values b) assign the crtc->state pointer I just want a) without the b) so let's split out part a) into __drm_atomic_helper_crtc_state_reset(). And of course we'll do the same thing for planes and connectors. v2: Fix conn__state vs. conn_state typo (Lucas) Make code and kerneldoc match for __drm_atomic_helper_plane_state_reset() Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
Chris Wilson authored
For very light workloads that frequently park, acquiring the display power well (required to prevent the dmc from trashing the system) takes longer than the execution. A good example is the igt_coherency selftest, which is slowed down by an order of magnitude in the worst case with powerwell cycling. To prevent frequent cycling, while keeping our fast soft-rc6, use a timer to delay release of the display powerwell. Fixes: 31177017 ("drm/i915/gt: Schedule request retirement when timeline idles") References: https://gitlab.freedesktop.org/drm/intel/issues/848Signed-off-by:
-
Chris Wilson authored
Since obj->frontbuffer is no longer protected by the struct_mutex, as we are processing the execbuf, it may be removed. Mark the intel_frontbuffer as rcu protected, and so acquire a reference to the struct as we track activity upon it. Closes: https://gitlab.freedesktop.org/drm/intel/issues/827 Fixes: 8e7cb179 ("drm/i915: Extract intel_frontbuffer active tracking") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218104043.3539458-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If the whole GT is asleep, we know that each engine must also be asleep and so we can quickly return without checking them all. Signed-off-by:
-
Chris Wilson authored
If we inherit an error along the fence chain, we skip the main work callback and go straight to the error. In the case of the vma bind worker, we only dropped the pinned pages from the worker. In the process, make sure we call the release earlier rather than wait until the final reference to the fence is dropped (as a reference is kept while being listened upon). Signed-off-by:
-
- 17 Dec, 2019 13 commits
-
-
Daniele Ceraolo Spurio authored
The Gen11+ and the legacy function differ in the register and value written to interrupt the GuC. However, while on older gen the value matches a bit on the register, on Gen11+ the value is a SW defined payload that is sent to the FW. Since the FW behaves the same no matter what value we pass to it, we can just write the same thing on all gens and get rid of the function pointer by saving the register offset. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217012316.13271-6-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
Since we started using CT buffers on all gens, the function pointers can only be set to either the _nop() or the _ct() functions. Since the _nop() case applies to when the CT are disabled, we can just handle that case in the _ct() functions and call them directly. v2: keep intel_guc_send() and make the CT send/receive functions work on intel_guc_ct. (Michal) Signed-off-by: -
Daniele Ceraolo Spurio authored
For better isolation of the request tracking from the rest of the CT-related data. v2: split to separate patch, move next_fence to substructure (Michal) Signed-off-by:
-
Daniele Ceraolo Spurio authored
The GuC supports having multiple CT buffer pairs and we designed our implementation with that in mind. However, the different channels are not processed in parallel within the GuC, so there is very little advantage in having multiple channels (independent locks?), compared to the drawbacks (one channel can starve the other if messages keep being submitted to it). Given this, it is unlikely we'll ever add a second channel and therefore we can simplify our code by removing the flexibility. v2: split substructure grouping to separate patch, improve docs (Michal) Signed-off-by:
-
Daniele Ceraolo Spurio authored
We track the status of the GuC much more closely now and we expect the enable/disable functions to be correctly called only once. If this isn't true we do want to flag it as a flow failure (via the BUG_ON in the ctch functions) and not silently ignore the call. Suggested-by:
-
Daniele Ceraolo Spurio authored
The only difference from the GuC POV between guc_communication_stop and guc_communication_disable is that the former can be called after GuC has been reset. Instead of having two separate paths, we can just skip the call into GuC in the disabling path and re-use that. Note that by using the disable() path instead of the stop() one there are two additional changes in SW side for the stop path: - interrupts are now disabled before disabling the CT, which is ok because we do not want interrupts with CT disabled; - guc_get_mmio_msg() is called in the stop case as well, which is ok because if there are errors before the reset we do want to record them. Signed-off-by:
-
Tvrtko Ursulin authored
Get_pid_task() needs to be paired with a put_pid or we leak a pid reference every time a banned client tries to create a context. v2: * task_pid_nr helper exists! (Chris) Signed-off-by:
-
Chris Wilson authored
As we stash a pointer to the HWSP cacheline on the request, when reading it we only need confirm that the cacheline is still valid by checking that the request and timeline are still intact. v2: Protect hwsp_cachline with RCU Signed-off-by:
-
Chris Wilson authored
Since commit e5dadff4 ("drm/i915: Protect request retirement with timeline->mutex"), the request retirement can happen outside of the struct_mutex serialised only by the timeline->mutex. We drop the timeline->mutex on submitting the request (i915_request_add) so after that point, it is liable to be freed. Make sure our local reference is kept alive until we have finished attaching it to the signalers. (Note that this erodes the argument that i915_request_add should consume the reference, but that is a slightly larger patch!) Fixes: e5dadff4 ("drm/i915: Protect request retirement with timeline->mutex") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217134729.3297818-1-chris@chris-wilson.co.uk
-
Hans de Goede authored
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. This commit fixes using the wrong PWM controller on these devices by calling pwm_get() for the right PWM controller based on the VBT dsi.config.pwm_blc bit. Note this is part of a series which contains 2 other patches which renames the PWM lookup for the 1st SoC/LPSS PWM from "pwm_backlight" to "pwm_pmic_backlight" and the PWM lookup for the Crystal Cove PMIC PWM from "pwm_backlight" to "pwm_pmic_backlight". Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-4-hdegoede@redhat.com
-
Hans de Goede authored
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. Since only the i915 driver has access to the VBT, this commit renames the "pwm_backlight" lookup entries for the Crystal Cove PMIC's PWM controller to "pwm_pmic_backlight" so that the i915 driver can do a pwm_get() for the right controller depending on the VBT bit, instead of the i915 driver relying on a "pwm_backlight" lookup getting registered which magically points to the right controller. Acked-by:
Lee Jones <lee.jones@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-3-hdegoede@redhat.com
-
Hans de Goede authored
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. Since only the i915 driver has access to the VBT, this commit renames the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for the right controller depending on the VBT bit, instead of the i915 driver relying on a "pwm_backlight" lookup getting registered which magically points to the right controller. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Chris Wilson authored
Sandybridge is the gen that didn't handle multiple registers in a single LRI packet. Don't forget it! Fixes: 902eb748 ("drm/i915/gt: Tidy up full-ppgtt on Ivybridge") Signed-off-by:
Tomi Sarvela <tomi.p.sarvela@intel.com> Acked-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217091328.3093551-1-chris@chris-wilson.co.uk
-
- 16 Dec, 2019 3 commits
-
-
Chris Wilson authored
We currently use an error-prone mutex_trylock to grab another timeline to find an earlier request along it. However, with a bit of a sleight-of-hand, we can reduce the mutex_trylock to a spin_lock on the immediate request and careful pointer chasing to acquire a reference on the previous request. Signed-off-by:
-
Maya Rashish authored
Signed-off-by:
Maya Rashish <coypu@sdf.org> Reviewed-by:
-
Chris Wilson authored
With a couple more memory barriers dotted around the place we can significantly reduce the MTBF on Ivybridge. Still doesn't really help Haswell though. Signed-off-by:
-
