- 26 Aug, 2015 26 commits
-
-
Ville Syrjälä authored
A couple of hand rolled ARRAY_SIZE()s caught my eye. Get rid of them. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Simple one: drivers/gpu/drm/i915/i915_debugfs.c:2449:57: warning: Using plain integer as NULL pointer And something a bit more peculiar: drivers/gpu/drm/i915/i915_debugfs.c:4953:18: warning: Variable length array is used. drivers/gpu/drm/i915/i915_debugfs.c:4953:32: warning: Variable length array is used. We pass a 'const int' as the array size which results in the warning, dropping the const gets rid of the warning. Weird, but I think getting rid of the warnings is better than holding on to the const. Signed-off-by:
-
Jani Nikula authored
BXT platform uses live status bits from 0x44440 register to obtain DP status on hotplug. The existing g4x_digital_port_connected() uses a different register and hence misses DP hotplug events on BXT platform. This patch fixes it by using the appropriate register(0x44440) and live status bits(3:5). Based on a patch by Durgadoss R <durgadoss.r@intel.com>, from whom the commit message is shamelessly copy pasted. Reported-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Jani Nikula authored
Choose the right function at the intel_digital_port_connected level. Signed-off-by:
-
Jani Nikula authored
Choose the right function at the intel_digital_port_connected level. Signed-off-by:
-
Jani Nikula authored
Add a common intel_digital_port_connected() that splits out to functions for different platforms. No functional changes. v2: make the function return a boolean Signed-off-by:
-
Jani Nikula authored
With the case added for eDP on port A (always connected from this function's point of view), we should not be hitting any of the default cases in ibx_digital_port_connected, so add MISSING_CASE annotation. Signed-off-by:
-
Jani Nikula authored
We should not be hitting any of the default cases in g4x_digital_port_connected, so add MISSING_CASE annotation and return boolean status. The current behaviour is just cargo culting from the days of yonder when the display port support was added to i915. Signed-off-by:
-
Jani Nikula authored
The function can be made static there. No functional changes. Reviewed-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to DVO. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - clock check against max dotclock moved inside 'if (fixed_mode)' V5: - dot clock check against fixed_mode clock when available Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to DSI. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk variable renamed as max_dotclk - moved dot clock checking inside 'if (fixed_mode)' V5: - dot clock checked against fixed_mode clock Signed-off-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to LVDS. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - moved supported dotclock check from mode_valid() to intel_lvds_init() V5: - dotclock check moved back to mode_valid() function - dotclock check for fixed mode Signed-off-by:
-
Mika Kahola authored
Store max dotclock into dev_priv structure so we are able to filter out the modes that are not supported by our platforms. V2: - limit the max dot clock frequency to max CD clock frequency for the gen9 and above - limit the max dot clock frequency to 90% of the max CD clock frequency for the older gens - for Cherryview the max dot clock frequency is limited to 95% of the max CD clock frequency - for gen2 and gen3 the max dot clock limit is set to 90% of the 2X max CD clock frequency V3: - max_dotclk variable renamed as max_dotclk_freq in i915_drv.h - in intel_compute_max_dotclk() the rounding method changed from round up to round down when computing max dotclock V4: - Haswell and Broadwell supports now dot clocks up to max CD clock frequency Signed-off-by:
-
Ville Syrjälä authored
Add vlv_dport_to_phy() and fix up the return values of vlv_dport_to_channel() and vlv_pipe_to_channel() to use the appropriate enums. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
With DPIO powergating active on CHV, we can't even access the DPIO PLL registers until the lane power state overrides have been enabled. That will happen from the encoder .pre_pll_enable() hook, so move chv_prepare_pll() to happen after that point, which puts it just before chv_enable_pll() actually. Do the same for VLV to avoid accumulating weird differences between the platforms. Both platforms seem happy with the new arrangement. Signed-off-by:
-
Ville Syrjälä authored
dev_priv->chv_phy_control is protected by the power_domains->lock elsewhere, so also grab it when initializing chv_phy_control. Signed-off-by:
-
Ville Syrjälä authored
To implement DPIO lane power gating on CHV we're going to need to access DPIO registers from the cmn power well enable hook. That gets called rather early, so we need to move the DPIO port IOSF sideband port assignment earlier as well. Signed-off-by:
-
Ville Syrjälä authored
Move the CHV clock buffer disable from chv_disable_pll() to the new encoder .post_pll_disable() hook. This is more symmetric since the clock buffer enable happens from the .pre_pll_enable() hook. We'll have more use for the new hook soon. Signed-off-by:
-
Ville Syrjälä authored
The docs give you the impression that the unique transition scale value shouldn't matter when unique transition scale is enabled. But as Imre found on BXT (and I verfied also on BSW) the value does matter. So from now on just program the same value 0x9a always. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
When fractional m2 divider isn't used on CHV the fractional part is ignore by the hardware. Despite that, program the fractional value (0 in this case) to the hardware register just to keep things a bit more consistent. Might at least make register dumps a bit less confusing when there isn't some stale fractional part hanging around. Signed-off-by:
-
Dave Gordon authored
The current versions of these two macros don't work correctly if the argument expression happens to contain a modulo operator (%) -- when stringified, it gets interpreted as a printf formatting character! With a specifically crafted parameter, this could probably cause a kernel OOPS; consider WARN_ON(p%s) or WARN_ON(f %*pEp). Instead, we should use an explicit "%s" format, with the stringified expression as the coresponding literal-string argument. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
With MST there won't be a crtc assigned to the main link encoder, so trying to dig up the pipe_config from there is a recipe for an oops. Instead store the parameters (lane_count and link_rate) in the encoder, and use those values during link training etc. Since those parameters are now assigned only when the link is actually enabled, .compute_config() won't clobber them as it did before. Hardware state readout is still bonkers though as we don't transfer the link parameters from pipe_config intel_dp. We should do that during encoder sanitation. But since we don't even do a proper job of reading out the main link encoder state for MST there's littel point in worrying about this now. Fixes a regression with MST caused by: commit 90a6b7b0 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Jul 6 16:39:15 2015 +0300 drm/i915: Move intel_dp->lane_count into pipe_config v2: Different apporoach that should keep intel_dp_check_mst_status() somewhat less oopsy Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Due to a coherency issue on BXT A steppings we can't guarantee a coherent view of cached (CPU snooped) GPU mappings, so fail such requests. User space is supposed to fall back to uncached mappings in this case. v2: - limit the WA to A steppings, on later stepping this HW issue is fixed v3: - return error instead of trying to work around the issue in kernel, since that could confuse user space (Chris) Testcast: igt/gem_store_dword_batches_loop/cached-mapping Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
By running igt/store_dword_loop_render on BXT we can hit a coherency problem where the seqno written at GPU command completion time is not seen by the CPU. This results in __i915_wait_request seeing the stale seqno and not completing the request (not considering the lost interrupt/GPU reset mechanism). I also verified that this isn't a case of a lost interrupt, or that the command didn't complete somehow: when the coherency issue occured I read the seqno via an uncached GTT mapping too. While the cached version of the seqno still showed the stale value the one read via the uncached mapping was the correct one. Work around this issue by clflushing the corresponding CPU cacheline following any store of the seqno and preceding any reading of it. When reading it do this only when the caller expects a coherent view. v2: - fix using the proper logical && instead of a bitwise & (Jani, Mika) - limit the workaround to A stepping, on later steppings this HW issue is fixed v3: - use a separate get_seqno/set_seqno vfunc (Chris) Testcase: igt/store_dword_loop_render Signed-off-by:
-
Rodrigo Vivi authored
We also need to call the frontbuffer flip to trigger proper invalidations when disabling planes. Otherwise we will miss screen updates when disabling sprites or cursor. On core platforms where HW tracking also works, this issue is totally masked because HW tracking triggers PSR exit however on VLV/CHV that has only SW tracking we miss screen updates when disabling planes. It was caught with kms_psr_sink_crc sprite_plane_onoff and cursor_plane_onoff subtests running on VLV/CHV. This is probably a regression since I can also get this with the manual test case, but with so many changes on atomic modeset I couldn't track exactly when this was introduced. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Arun Siluvery authored
MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM instructions are not really variable length instructions unlike MI_LOAD_REGISTER_IMM where it expects (reg, addr) pairs so use fixed length for these instructions. v2: rebase Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Appease checkpatch as Mika spotted in i915_reg.h - it seems terminally unhappy about i915_cmd_parser.c so that would be a separate patch.] Signed-off-by:
-
- 25 Aug, 2015 1 commit
-
-
Graham Whaley authored
In commit d1675198: drm/i915: Integrate GuC-based command submission the drm.tmpl include lines reference the intel_guc_submission.c but the patch adds the file i915_guc_submission.c. drm.tmpl fails to build with: docproc: .//drivers/gpu/drm/i915/intel_guc_submission.c: No such file or directory Change the file reference to the actual file. Signed-off-by:
Graham Whaley <graham.whaley@linux.intel.com> Signed-off-by:
-
- 14 Aug, 2015 13 commits
-
-
Jani Nikula authored
There's so much scaler debugging messages that it makes other debugging hard. Remove them. Signed-off-by:
-
Dave Gordon authored
This provides a means of reading status and counts relating to GuC actions and submissions. v2: Remove surplus blank line in output [Chris Wilson] v5: Added GuC per-engine submission & seqno statistics v6: Add per-ring statistics to client, refactor client-dumper. Signed-off-by:Alex Dai <yu.dai@intel.com> Reviewed-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by:
-
Alex Dai authored
GuC-based submission is mostly the same as execlist mode, up to intel_logical_ring_advance_and_submit(), where the context being dispatched would be added to the execlist queue; at this point we submit the context to the GuC backend instead. There are, however, a few other changes also required, notably: 1. Contexts must be pinned at GGTT addresses accessible by the GuC i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls. 2. The GuC's TLB must be invalidated after a context is pinned at a new GGTT address. 3. GuC firmware uses the one page before Ring Context as shared data. Therefore, whenever driver wants to get base address of LRC, we will offset one page for it. LRC_PPHWSP_PN is defined as the page number of LRCA. 4. In the work queue used to pass requests to the GuC, the GuC firmware requires the ring-tail-offset to be represented as an 11-bit value, expressed in QWords. Therefore, the ringbuffer size must be reduced to the representable range (4 pages). v2: Defer adding #defines until needed [Chris Wilson] Rationalise type declarations [Chris Wilson] v4: Squashed kerneldoc patch into here [Daniel Vetter] v5: Update request->tail in code common to both GuC and execlist modes. Add a private version of lr_context_update(), as sharing the execlist version leads to race conditions when the CPU and the GuC both update TAIL in the context image. Conversion of error-captured HWS page to string must account for offset from start of object to actual HWS (LRC_PPHWSP_PN). Issue: VIZ-4884 Signed-off-by: -
Dave Gordon authored
Turn on interrupt steering to route necessary interrupts to GuC. v6: Rebased Issue: VIZ-4884 Signed-off-by: -
Dave Gordon authored
A GuC client has its own doorbell and workqueue. It maintains the doorbell cache line, process description object and work queue item. A default guc_client is created for the i915 driver to use for normal-priority in-order submission. Note that the created client is not yet ready for use; doorbell allocation will fail as we haven't yet linked the GuC's context descriptor to the default contexts for each ring (see later patch). v2: Defer adding structure members until needed [Chris Wilson] Rationalise type declarations [Chris Wilson] v5: Add GuC per-engine submission & seqno statistics. Move wq locking to encompass both get_space() and add_item(). Take forcewake lock in host2guc_action() [Tom O'Rourke] v6: Fix GuC doorbell cacheline selection code (the cacheline-within-page calculation was wrong). Rename GuC priorities to make them closer to the names used in the GuC firmware source, matching what the autogenerated versions will (probably) be. Add per-ring statistics to client. Issue: VIZ-4884 Signed-off-by: -
Alex Dai authored
Allocate a GEM object to hold GuC log data. A debugfs interface (i915_guc_log_dump) is provided to print out the log content. v2: Add struct members at point of use [Chris Wilson] v6: Rebased Issue: VIZ-4884 Signed-off-by: -
Alex Dai authored
This adds the first of the data structures used to communicate with the GuC (the pool of guc_context structures). We create a GuC-specific wrapper round the GEM object allocator as all GEM objects shared with the GuC must be pinned into GGTT space at an address that is NOT in the range [0..WOPCM_TOP), as that range of GGTT addresses is not accessible to the GuC (from the GuC's point of view, it's permanently reserved for other objects such as the BootROM & SRAM). Later, we will need to allocate additional GuC-sharable objects for the submission client(s) and the GuC's debug log. v2: Remove redundant initialisation [Chris Wilson] Defer adding struct members until needed [Chris Wilson] Local functions should pass dev_priv rather than dev [Chris Wilson] v5: Invalidate GuC TLB after allocating and pinning a new object v6: Rebased Issue: VIZ-4884 Signed-off-by: -
Dave Gordon authored
GuC submission is basically execlist submission, but with the GuC handling the actual writes to the ELSP and the resulting context switch interrupts. So to describe a context for submission via the GuC, we need one of the same functions used in execlist mode. This commit exposes one such function, changing its name to better describe what it does (it's related to logical ring contexts rather than to execlists per se). v2: Replaces previous "drm/i915: Move execlists defines from .c to .h" v3: Incorporates a change to one of the functions exposed here that was previously part of an internal patch, but which was omitted from the version recently committed to drm-intel-nightly: 7a01a0a2 drm/i915/lrc: Update PDPx registers with lri commands So we reinstate this change here. v4: Drop v3 change, update function parameters due to collision with 8ee36152 drm/i915: Convert execlists_ctx_descriptor() for requests v5: Don't expose execlists_update_context() after all. The current version is no longer compatible with GuC submission; trying to share the execlist version of this function results in both GuC and CPU updating TAIL in the context image, with bad results when they get out of step. The GuC submission path now has its own private version that just updates the ringbuffer start address, and not TAIL or PDPx. v6: Rebased Issue: VIZ-4884 Signed-off-by: -
Alex Dai authored
The new node provides access to the status of the GuC-specific loader; also the scratch registers used for communication between the i915 driver and the GuC firmware. v2: Changes to output formats per Chris Wilson's suggestions v6: Rebased Issue: VIZ-4884 Signed-off-by: -
Alex Dai authored
This fetches the required firmware image from the filesystem, then loads it into the GuC's memory via a dedicated DMA engine. This patch is derived from GuC loading work originally done by Vinit Azad and Ben Widawsky. v2: Various improvements per review comments by Chris Wilson v3: Removed 'wait' parameter to intel_guc_ucode_load() as firmware prefetch is no longer supported in the common firmware loader, per Daniel Vetter's request. Firmware checker callback fn now returns errno rather than bool. v4: Squash uC-independent code into GuC-specifc loader [Daniel Vetter] Don't keep the driver working (by falling back to execlist mode) if GuC firmware loading fails [Daniel Vetter] v5: Clarify WOPCM-related #defines [Tom O'Rourke] Delete obsolete code no longer required with current h/w & f/w [Tom O'Rourke] Move the call to intel_guc_ucode_init() later, so that it can allocate GEM objects, and have it fetch the firmware; then intel_guc_ucode_load() doesn't need to fetch it later. [Daniel Vetter]. v6: Update comment describing intel_guc_ucode_load() [Tom O'Rourke] Issue: VIZ-4884 Signed-off-by: -
Ville Syrjälä authored
We only need the link_bw/rate_select parameters when starting link training, and they should be computed based on the currently active config, so throw them out from intel_dp and just compute on demand. Toss in an extra debug print to see rate_select in addition to link_bw, as the latter may be 0 for eDP 1.4. Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Ville Syrjälä authored
intel_dp->link_bw is going away, so consul the port_clock instead when choosing between TP1 and TP3. Signed-off-by:
-
Ville Syrjälä authored
Currently we clobber intel_dp->lane_count in compute config, which means after a rejected modeset we may no longer be able to retrain the current link. Move lane_count into pipe_config to avoid that. v2: Add missing ':' to the pipe config debug dump Signed-off-by:
-
