- 28 Aug, 2018 9 commits
-
-
Manasi Navare authored
This patch fixes the PPS4 and PPS5 register definition macros that were resulting into an incorect MMIO address. Fixes: 2efbb2f0 ("i915/dp/dsc: Add DSC PPS register definitions") Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824014807.14681-1-manasi.d.navare@intel.com
-
Dhinakaran Pandiyan authored
ICL requires two planes for scanning out a NV12 framebuffer. Do not advertize support for creating NV12 framebuffers until required plane programming is implemented. v2: Do not allow adding buffers. Check inside skl_plane_has_planar (Ville) Bspec: Plane Planar YUV programming (18566) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824203856.17700-2-dhinakaran.pandiyan@intel.com
-
Dhinakaran Pandiyan authored
skl_plane_has_planar is hard to read, simplify the logic by checking for support in the order of platform, pipe and plane. No change in functionality intended. v2: Fix logic for primary plane (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Y/Yf tiling can't be used with IF-ID. We already reject uncompressed Y/Yf but we should also reject them when compressed. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
-
Ville Syrjälä authored
.check_plane() already gets the plane state, so we can dig out the plane from there if needed. No need in passing it separately. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Ville Syrjälä authored
gcc is too smart for us and doesn't evaluate BUILD_BUG_ON()s in unused static inlines. Collect them up in one static inline and actually call it to make sure gcc sees it. Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Rodrigo Vivi authored
Now that we have a generic caller let's simplify it and clean up the intel_psr.c code a bit. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
No functional change. But let's get first i915 pointer directly from intel_dp so we can clean up a lot of code later. Signed-off-by:
-
Daniele Ceraolo Spurio authored
We currently verify that all doorbells can be registered with GuC and HW but don't check that all works as expected after a db ring. Do a nop ring of all doorbells to make sure we haven't misprogrammed any WQ or stage descriptor data. This will also help validating upcoming changes in the db programming flow. Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Acked-by:
Katarzyna Dec <katarzyna.dec@intel.com> Signed-off-by:
-
- 27 Aug, 2018 2 commits
-
-
Dhinakaran Pandiyan authored
Added bspec reference, aligned text and documented the function. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
CI runs show PSR2 does not go to IDLE with selective update enabled on all PSR exit triggers. Specifically, logs indicate the hardware enters "SLEEP Selective Update" and not "IDLE Reset state', like the kernel expects, when vblank interrupts are enabled. This check was added for PSR1 but incorrectly extended to PSR2, remove the check as it breaks tests and prints out misleading error messages. v2: Split out non-code changes (Rodrigo) Cc: Tarun Vyas <tarun.vyas@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: c43dbcbb ("drm/i915/psr: Lockless version of psr_wait_for_idle") Signed-off-by:
-
- 25 Aug, 2018 1 commit
-
-
Jan-Marek Glogowski authored
This re-applies the workaround for "some DP sinks, [which] are a little nuts" from commit 1a36147b ("drm/i915: Perform link quality check unconditionally during long pulse"). It makes the secondary AOC E2460P monitor connected via DP to an acer Veriton N4640G usable again. This hunk was dropped in commit c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") Fixes: c85d200e ("drm/i915: Move SST DP link retraining into the ->post_hotplug() hook") [Cleaned up commit message, added stable cc] Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Jan-Marek Glogowski <glogow@fbihome.de> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20180825191035.3945-1-lyude@redhat.com
-
- 24 Aug, 2018 4 commits
-
-
Paulo Zanoni authored
There's no need for that forward declaration. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-4-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
Use the nice helper function to make the implementation simpler. v2: Rebase. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (v1) Signed-off-by:
-
Paulo Zanoni authored
None of the current lookup_power_well() callers are actually checking for NULL return values, they all just use the pointer right away. The first idea was to replace these theoretical segfaults with a BUG() since this would at least make our code a little more explicit to the reader. It was suggested that just converting the BUG() to a WARN() and returning any power well would probably be better since it would still keep the system running while at the same time exposing the driver bug. We can only hit this NULL/BUG()/WARN() condition if we try to lookup a power well that isn't defined on a given platform. If that ever happens, we have to fix our code, making it lookup the correct power well. Because of this, I don't think it's worth trying to implement error checking in every caller. Improving our CI system will be a better use of our time once a bug is found in the wild. v2: Avoid the BUG() with a WARN() return a random PW (Michal). Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Paulo Zanoni authored
Unlike the other ports, TC ports are not available to use as soon as we get a hotplug. The TC PHYs can be shared between multiple controllers: display, USB, etc. As a result, handshaking through FIA is required around connect and disconnect to cleanly transfer ownership with the controller and set the type-C power state. This patch implements the flow sequences described by our specification. We opt to grab ownership of the ports as soon as we get the hotplugs in order to simplify the interactions and avoid surprises in the user space side. We may consider changing this in the future, once we improve our testing capabilities on this area. v2: * This unifies the DP and HDMI patches so we can discuss everything at once so people looking at random single patches can actually understand the direction. * I found out the spec was updated a while ago. There's a small difference in the connect flow and the patch was updated for that. * Our spec also now gives a good explanation on what is really happening. As a result, comments were added. * Add some more comments as requested by Rodrigo (Rodrigo). v3: * Downgrade a DRM_ERROR that shouldn't ever happen but we can't act on in case it does (Chris). BSpec: 21750, 4250. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 23 Aug, 2018 2 commits
-
-
Rodrigo Vivi authored
We use kzalloc to allocate the write_buf that we use for i2c transfer on hdcp write. But it seems that we are forgetting to free the memory that is not needed after i2c transfer is completed. Reported-by:
Brian J Wood <brian.j.wood@intel.com> Fixes: 2320175f ("drm/i915: Implement HDCP for HDMI") Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Signed-off-by:
-
Imre Deak authored
For S0ix we want to deinit power domains (and so deactivate the DMC firmware) exactly when the platform supports the DC9 state. To reach S0ix we need DC9 on these platforms (for which the DMC FW needs to be deactivated) while to reach S0ix on the rest of the DMC platforms we need DC6 (which needs the DMC FW to stay active). Simplify the condition accordingly so it will be automatically correct for upcoming DC9 platforms like ICL. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 22 Aug, 2018 7 commits
-
-
Dhinakaran Pandiyan authored
Rename PLANE_CTL_DECOMPRESSION_ENABLE to resemble the bpsec name - PLANE_CTL_RENDER_DECOMPRESSION_ENABLE Suggested-by:
-
Dhinakaran Pandiyan authored
Code looks cleaner with modifiers hidden inside this wrapper. v2: Remove const qualifier (Ville) Signed-off-by:
-
Azhar Shaikh authored
Log the PSR mode/revision (PSR1 or PSR2) in the debugfs file i915_edp_psr_status. Suggested-by:
Azhar Shaikh <azhar.shaikh@intel.com> Reviewed-by:
-
Ville Syrjälä authored
The workaround was supposed to look at the plane destination coordinates. Currently it's looking at some mixture of src and dst coordinates that doesn't make sense. Fix it up. Signed-off-by:
-
Dhinakaran Pandiyan authored
gen8_de_irq_postinstall() wasn't masking the IRQ bit before passing the debug flag to psr_irq_control(). This check was missed when new debug bits were defined in 'commit c44301fc ("drm/i915: Allow control of PSR at runtime through debugfs, v6")'. Instead of ANDing the irq bit in all the callers, move it to the callee. v2: Rebased. Fixes: c44301fc ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-3-dhinakaran.pandiyan@intel.com
-
Dhinakaran Pandiyan authored
We print the last attempted entry and last exit timestamps only when IRQ debug is requested. This check was missed when new debug flags were added in 'commit c44301fc ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Fixes: c44301fc ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Dhinakaran Pandiyan authored
Knowing the status of the PSR HW state machine is useful for debug, especially since we are seeing errors with PSR2 in CI. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 21 Aug, 2018 1 commit
-
-
Chris Wilson authored
Since we no longer maintain our read position in the CSB pointers register, it always returns 0 and not where we last read up to. As a result the CSB probing in the state dumper starts from 0, either missing entries or showing stale one. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821101138.15822-1-chris@chris-wilson.co.uk
-
- 20 Aug, 2018 5 commits
-
-
Manasi Navare authored
PLLs are the source clocks for the DDIs so in order to determine the ddi clock we need to check the PLL configuration. For MG PHy Ports (C - F), depending on whether it is a TBT PLL or MG PLL the link lock can be obtained from the the PLL divisors based on the specification. v2 (from Paulo): * Make the algorithm look more like what's in the spec, also document where we differ form the spec and why. * Make the code a little more consistent with our coding style. Reviewed-by:
-
Manasi Navare authored
drm/i915/icl: Implement HSDIV_RATIO of MG_CLKTOP2_HSCLKCTL_PORT reg as separate divider value defines The register value of Divider Ratio for high speed divider (hsdiv_ratio) in MG_CLKTOP2_HSCLKCTL_PORT register is not same as the actual numerical value of the divider. So this patch implements separate divider value defines for that field. icl_mg_pll_find_divisors() can use these defines instead of magic register values. The new defines are going to be used in the next patch. v2 (from Paulo): * Rebase. * Make it look a little more like the rest of our code. v3 (from Paulo): * Make hsdiv u32 now that it's a bit field (José). Reviewed-by:
James Ausmus <james.ausmus@intel.com> Signed-off-by:
-
Chris Wilson authored
If the display has been disabled by modparam, we still want to connect together the HW bits and bobs with the associated drivers so that we can continue to manage their runtime power gating. Fixes: 10810944 ("drm/i915: Check num_pipes before initializing audio component") Signed-off-by:
-
Fredrik Schön authored
100 ms is not enough time for the LSPCON adapter on Intel NUC devices to settle. This causes dropped display modes at boot or screen reconfiguration. Empirical testing can reproduce the error up to a timeout of 190 ms. Basic boot and stress testing at 200 ms has not (yet) failed. Increase timeout to 400 ms to get some margin of error. Changes from v1: The initial suggestion of 1000 ms was lowered due to concerns about delaying valid timeout cases. Update patch metadata. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107503 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1570392 Fixes: 357c0ae9 ("drm/i915/lspcon: Wait for expected LSPCON mode to settle") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v4.11+ Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Fredrik Schön <fredrik.schon@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180817200728.8154-1-fredrik.schon@gmail.com
-
Imre Deak authored
After commit 2cd9a689 ("drm/i915: Refactor intel_display_set_init_power() logic") it makes more sense to check the power domain/well refcounts after enabling the power domains functionality. Before that it's guaranteed that most power wells (in the INIT domain) will have a reference held, so not an interesting state. While at it also add the check after the init_hw/fini_hw, disable and suspend/resume steps. Make the test optional on a Kconfig option since it may add substantial overhead: on VLV/CHV the corresponding PUNIT reg access for each power well may take up to 20ms. v2: - Add the state check to more spots. (Chris) v3: - During suspend check the state before deiniting display core. Afterwards DC states are disabled (and so the dc_off power well is enabled) even though we don't hold a reference on it. - Do the test conditionally based on a new Kconfig option. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 17 Aug, 2018 1 commit
-
-
Anusha Srivatsa authored
Let us reuse the already defined has_csr check and not redefine it. The main difference is that in effect this will flip .has_csr to 1 (via GEN9_FEATURES which GEN11_FEATURES pulls in). Suggested-by:
-
- 16 Aug, 2018 7 commits
-
-
Chris Wilson authored
Show the reset depth (the tasklet disable count) in the GEM_TRACE to indicate when we might not expect tasklets to be flushed. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180815135827.25869-1-chris@chris-wilson.co.uk
-
Lucas De Marchi authored
Instead of defining all registers twice, define just a PCH_GPIO_BASE that has the same address as PCH_GPIO_A and use that to calculate all the others. This also brings VLV and !HAS_GMCH_DISPLAY in line, doing the same thing. v2: Fix GMBUS registers to be relative to gpio base; create GPIO() macro to return a particular gpio address and move the enum out of i915_reg.h (suggested by Jani) v3: Move base offset inside the GPIO() macro so the GMBUS defines don't actually need to be changed (suggested by Daniel/Ville) v4: Move definition of i915_gpio to intel_display.h and remove GMBUS/GPIO handling from gvt since now they have their own defines. Signed-off-by:Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Lucas De Marchi authored
The definition on i915_reg.h is going to change to depend on dev_priv->gpio_mmio_base being properly initialized. Define our own macros since init_generic_mmio_info() is called before than gpio_mmio_base being set. Cc: intel-gvt-dev@lists.freedesktop.org Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Lucas De Marchi authored
This is the only place that they are being used - the others use the GMBUS* macros that rely on dev_priv being already properly initialized. Cc: intel-gvt-dev@lists.freedesktop.org Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Imre Deak authored
The device global init_power_on flag is somewhat arbitrary and makes debugging power refcounting problems difficult. Instead arrange things so that all display power domain get has a corresponding put call. After this change we have the following sequences: driver loading: intel_power_domains_init_hw(); <other init steps> intel_power_domains_enable(); driver unloading: intel_power_domains_disable(); <other uninit steps> intel_power_domains_fini_hw(); system suspend: intel_power_domains_disable(); <other suspend steps> intel_power_domains_suspend(); system resume: intel_power_domains_resume(); <other resume steps> intel_power_domains_enable(); at other times while the driver is loaded: intel_display_power_get(); ... intel_display_power_put(); Suggested-by:
-
Chris Wilson authored
Currently, we cancel the extra wakeref we have for !runtime-pm devices inside power_wells_fini_hw. However, this is not strictly paired with the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may be called on errors paths before we even call runtime_pm_enable). Make the symmetry more explicit and include a check that we do release all of our rpm wakerefs. v2: Fixup transfer of ownership back to core whilst keeping our wakeref count balanced. Signed-off-by:
-
Chris Wilson authored
The context owns both the ppgtt and the vma within it, and our activity tracking on the context ensures that we do not release active ppgtt. As the context fulfils our obligations for active memory tracking, we can relinquish the reference from the vma. This fixes a silly transient refleak from closed vma being kept alive until the entire system was idle, keeping all vm alive as well. Reported-by:
-
- 15 Aug, 2018 1 commit
-
-
Chris Wilson authored
As the only error is for a programming error in constructing the static tables describing the register values, replace the error code propagation with an assert. Signed-off-by:
-
