summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/i915_drv.h
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Mark AML 0x87CA as ULXVille Syrjälä2019-04-031-1/+2
| | | | | | | | | | | | | | | | | | | | commit 4b9a3932e7ba929baa231231e61874c7a56f8959 upstream. If I'm reading the spec right AML 0x87CA is a Y SKU, so it should be marked as ULX in our old style terminology. Cc: stable@vger.kernel.org Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: c0c46ca461f1 ("drm/i915/aml: Add new Amber Lake PCI ID") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322204944.23613-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 57b1c4460dc46a00f6ec439f3f11d670736b0209) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* drm/i915: Update DRIVER_DATE to 20181204Jani Nikula2018-12-041-2/+2
| | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Allocate a common scratch pageChris Wilson2018-12-041-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Currently we allocate a scratch page for each engine, but since we only ever write into it for post-sync operations, it is not exposed to userspace nor do we care for coherency. As we then do not care about its contents, we can use one page for all, reducing our allocations and avoid complications by not assuming per-engine isolation. For later use, it simplifies engine initialisation (by removing the allocation that required struct_mutex!) and means that we can always rely on there being a scratch page. v2: Check that we allocated a large enough scratch for I830 w/a Fixes: 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") # v4.18.20 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108850 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181204141522.13640-1-chris@chris-wilson.co.uk Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.18.20+
* drm/i915: Fuse per-context workaround handling with the common frameworkTvrtko Ursulin2018-12-041-15/+0
| | | | | | | | | | | | | | | | | | | | | | Convert the per context workaround handling code to run against the newly introduced common workaround framework and fuse the two to use the existing smarter list add helper, the one which does the sorted insert and merges registers where possible. This completes migration of all four classes of workarounds onto the common framework. Existing macros are kept untouched for smaller code churn. v2: * Rename to list name ctx_wa_list and move from dev_priv to engine. v3: * API rename and parameters tweaking. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203133357.10341-1-tvrtko.ursulin@linux.intel.com
* drm/i915: Record GT workarounds in a listTvrtko Ursulin2018-12-041-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To enable later verification of GT workaround state at various stages of driver lifetime, we record the list of applicable ones per platforms to a list, from which they are also applied. The added data structure is a simple array of register, mask and value items, which is allocated on demand as workarounds are added to the list. This is a temporary implementation which later in the series gets fused with the existing per context workaround list handling. It is separated at this stage since the following patch fixes a bug which needs to be as easy to backport as possible. Also, since in the following patch we will be adding a new class of workarounds (per engine) which can be applied from interrupt context, we straight away make the provision for safe read-modify-write cycle. v2: * Change dev_priv to i915 along the init path. (Chris Wilson) * API rename. (Chris Wilson) v3: * Remove explicit list size tracking in favour of growing the allocation in power of two chunks. (Chris Wilson) v4: Chris Wilson: * Change wa_list_finish to early return. * Copy workarounds using the compiler for static checking. * Do not bother zeroing unused entries. * Re-order struct i915_wa_list. v5: * kmalloc_array. * Whitespace cleanup. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203133319.10174-1-tvrtko.ursulin@linux.intel.com
* drm/i915: Move display device info capabilities to its own structJosé Roberto de Souza2018-12-031-11/+11
| | | | | | | | | | | | | This helps separate what capabilities are display capabilities. v3: Moving display struct right after flags (Lucas) Cc: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181130232048.14216-2-jose.souza@intel.com
* drm/i915: Add HAS_DISPLAY() and use itJosé Roberto de Souza2018-12-031-0/+2
| | | | | | | | | | Right now it is decided if GEN has display by checking the num_pipes, so lets make it explicit and use a macro. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181130232048.14216-1-jose.souza@intel.com
* drm/i915/psr: Get pipe id following atomic guidelinesJosé Roberto de Souza2018-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | As stated in struct drm_encoder, crtc field should only be used by non-atomic drivers. So here caching the pipe id in intel_psr_enable() what is way more simple and efficient than at every call to intel_psr_flush()/invalidate() get the drm.mode_config.connection_mutex lock to safely be able to get the pipe id by reading drm_connector_state.crtc. This should fix the null pointer dereference crash below as the previous way to get the pipe id was prone to race conditions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105959 Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128072838.22773-1-jose.souza@intel.com
* drm/i915/dp: Disable DSC in source by disabling DSS CTL bitsManasi Navare2018-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | 1. Disable Left/right VDSC branch in DSS Ctrl reg depending on the number of VDSC engines being used 2. Disable joiner in DSS Ctrl reg v4: * Remove encoder, make crtc_state const (Ville) v3 (From Manasi): * Add Disable PG2 for VDSC on eDP v2 (From Manasi): * Use old_crtc_state to find dsc params * Add a condition to disable only if dsc state compression is enabled * Use correct DSS CTL regs Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-12-manasi.d.navare@intel.com
* drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enablingManasi Navare2018-11-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After encoder->pre_enable() hook, after link training sequence is completed, PPS registers for DSC encoder are configured using the DSC state parameters in intel_crtc_state as part of DSC enabling routine in the source. DSC enabling routine is called after encoder->pre_enable() before enbaling the pipe and after compression is enabled on the sink. v7: * Remove unnecessary comments, leftovers (Ville) * No need for explicit val &= ~ (Ville) v6: intel_dsc_enable to be part of pre_enable hook (Ville) v5: * make crtc_state const (Ville) v4: * Use cpu_transcoder instead of encoder->type for using EDP transcoder DSC registers(Ville) * Keep all PSS regs together (Anusha) v3: * Configure Pic_width/2 for each VDSC engine when two VDSC engines per pipe are used (Manasi) * Add DSC slice_row_per_frame in PPS16 (Manasi) v2: * Enable PG2 power well for VDSC on eDP Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> [manasi: fixup the line longer than 100 chars while applying] Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-8-manasi.d.navare@intel.com
* drm/i915/dp: Add DSC params and DSC config to intel_crtc_stateManasi Navare2018-11-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | Basic DSC parameters and DSC configuration data needs to be computed for each of the requested mode during atomic check. This is required since for certain modes, valid DSC parameters and config data might not be computed in which case compression cannot be enabled for that mode. For that reason we need to add these params and config structure to the intel_crtc_state so that if valid this state information can directly be used while enabling DSC in atomic commit. v2: * Rebase on drm-tip (Manasi) Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-1-manasi.d.navare@intel.com
* drm/i915: Move ddb/wm programming into plane update/disable hooks on skl+Ville Syrjälä2018-11-281-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | On SKL+ the plane WM/BUF_CFG registers are a proper part of each plane's register set. That means accessing them will cancel any pending plane update, and we would need a PLANE_SURF register write to arm the wm/ddb change as well. To avoid all the problems with that let's just move the wm/ddb programming into the plane update/disable hooks. Now all plane registers get written in one (hopefully atomic) operation. To make that feasible we'll move the plane ddb tracking into the crtc state. Watermarks were already tracked there. v2: Rebase due to input CSC v3: Split out a bunch of junk (Matt) v4: Add skl_wm_add_affected_planes() to deal with cursor special case and non-zero wm register reset value v5: Drop the unrelated for_each_intel_plane_mask() fix (Matt) Remove the redundant ddb memset() (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v3 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181127165900.31298-1-ville.syrjala@linux.intel.com
* drm/i915: Disable PSR when a PSR aux error happenJosé Roberto de Souza2018-11-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | While PSR is active hardware will do aux transactions by it self to wakeup sink to receive a new frame when necessary. If that transaction is not acked by sink, hardware will trigger this interruption. So let's disable PSR as it is a hint that there is problem with this sink. The removed FIXME was asking to manually train the link but we don't need to do that as by spec sink should do a short pulse when it is out of sync with source, we just need to make sure it is awaken and the SDP header with PSR inactive set it will trigger the short pulse with a error set in the link status. v3: added workarround to fix scheduled work starvation cause by to frequent PSR error interruption v4: only setting irq_aux_error as we don't care in clear it and not using dev_priv->irq_lock as consequence. v5: rebased: using edp_psr_shift() Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-4-jose.souza@intel.com
* drm/i915: Do not enable PSR in the next modeset after a errorJosé Roberto de Souza2018-11-221-0/+1
| | | | | | | | | | | | When we detect a error and disable PSR, it is kept disabled until the next modeset but as the sink already show signs that it do not properly work with PSR lets disabled it for good to avoid any additional flickering. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-3-jose.souza@intel.com
* drm/i915: Update DRIVER_DATE to 20181122Jani Nikula2018-11-221-1/+1
| | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Update DRIVER_DATE to 20181122Jani Nikula2018-11-221-2/+2
| | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: extract fixed point math to i915_fixed.hJani Nikula2018-11-201-138/+1
| | | | | | | | | | | Reduce bloat in one of the bigger header files. Fix some indentation while at it. No functional changes. v2: Add include guards (Joonas) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116120729.7580-1-jani.nikula@intel.com
* Revert "drm/i915/perf: add a parameter to control the size of OA buffer"Joonas Lahtinen2018-11-191-1/+0
| | | | | | | | | | | | Userspace portion is still missing. This reverts commit cd956bfcd0f58d20485ac0a785415f7d9327a95f. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116135510.13807-1-joonas.lahtinen@linux.intel.com
* drm/i915/bios: make the aux channel macros private to the vbt parserJani Nikula2018-11-151-7/+0
| | | | | | | | | | Hide the aux channel macros in intel_vbt_defs.h now that their use has been abstracted in intel_bios_port_aux_ch(). Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-3-jani.nikula@intel.com
* drm/i915: remove unused DDC PIN macrosJani Nikula2018-11-151-4/+0
| | | | | | | | Their user has vanished in the course of history. Remove. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-2-jani.nikula@intel.com
* drm/i915/bios: rename intel_aux_ch() to intel_bios_port_aux_ch()Jani Nikula2018-11-151-1/+1
| | | | | | | | | Conform to function naming in intel_bios.c. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-1-jani.nikula@intel.com
* drm/i915: Determine DSI panel orientation from VBTVille Syrjälä2018-11-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | VBT appears to have two (or possibly three) ways to indicate the panel rotation. The first is in the MIPI config block, but that apparenly usually (maybe always?) indicates 0 degrees despite the actual panel orientation. The second way to indicate this is in the general features block, which can just indicate whether 180 degress rotation is used. The third might be a separate rotation data block, but that is not at all documented so who knows what it may contain. Let's try the first two. We first try the DSI specicic VBT information, and it it doesn't look trustworthy (ie. indicates 0 degrees) we fall back to the 180 degree thing. Just to avoid too many changes in one go we shall also keep the hardware readout path for now. If this works for more than just my VLV FFRD the question becomes how many of the panel orientation quirks are now redundant? v2: Move the code into intel_dsi.c (Jani) Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181022142015.4026-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com>
* drm/i915: remove padding from struct skl_wm_levelPaulo Zanoni2018-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reduces the size of struct skl_wm_level from 6 to 4, which reduces the size of struct skl_plane_wm from 104 to 70, which reduces the size of struct skl_pipe_wm from 524 to 356. A reduction of 168 padding bytes per pipe. This will increase even more the next time we bump I915_MAX_PLANES. v2: Paste the pahole output provided by Lucas: $ pahole -s -C skl_wm_level drivers/gpu/drm/i915/i915.o struct skl_wm_level { bool plane_en; /* 0 1 */ /* XXX 1 byte hole, try to pack */ uint16_t plane_res_b; /* 2 2 */ uint8_t plane_res_l; /* 4 1 */ /* size: 6, cachelines: 1, members: 3 */ /* sum members: 4, holes: 1, sum holes: 1 */ /* padding: 1 */ /* last cacheline: 6 bytes */ }; Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181016220133.26991-3-paulo.r.zanoni@intel.com
* drm/i915/cnl+: Move the combo PHY init/uninit code to a new fileImre Deak2018-11-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | Similarly to the GEN9_LP DPIO PHY code keep the CNL+ combo PHY code in a separate file. No functional change. v2: - Use SPDX license tag instead of boilerplate. (Rodrigo) v3: - Use MIT instead of GPL-2.0 license. (Ville) Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-3-imre.deak@intel.com
* drm/i915: Add short HPD IRQ storm detection for non-MST systemsLyude Paul2018-11-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unfortunately, it seems that the HPD IRQ storm problem from the early days of Intel GPUs was never entirely solved, only mostly. Within the last couple of days, I got a bug report from one of our customers who had been having issues with their machine suddenly booting up very slowly after having updated. The amount of time it took to boot went from around 30 seconds, to over 6 minutes consistently. After some investigation, I discovered that i915 was reporting massive amounts of short HPD IRQ spam on this system from the DisplayPort port, despite there not being anything actually connected. The symptoms would start with one "long" HPD IRQ being detected at boot: [ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0 [ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long [ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0 [ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long [ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0 [ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long [ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long … followed by constant short IRQs afterwards: [ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected [ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event. [ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3] [ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085 [ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 The customer's system in question has a GM45 GPU, which is apparently well known for hotplugging storms. So, workaround this impressively broken hardware by changing the default HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and short IRQs count for 1. This makes it so that 5 long IRQs will trigger an HPD storm, and on systems with short HPD storm detection 50 short IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of constant pulsing, which seems like a good middleground between being too sensitive and not being sensitive enough (which would cause visible stutters in userspace every time a storm occurs). And just to be extra safe: we don't enable this by default on systems with MST support. There's too high of a chance of MST support triggering storm detection, and systems that are new enough to support MST are a lot less likely to have issues with IRQ storms anyway. As a note: this patch was tested using a ThinkPad T450s and a Chamelium to simulate the short IRQ storms. Changes since v1: - Don't use two separate thresholds, just make long IRQs count for 10 each and short IRQs count for 1. This simplifies the code a bit - Ville Syrjälä Changes since v2: - Document @long_hpd in intel_hpd_irq_storm_detect, no functional changes Changes since v4: - Remove !! in long_hpd assignment - Ville Syrjälä - queue_hp = true - Ville Syrjälä Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106213017.14563-6-lyude@redhat.com
* drm/i915: Update DRIVER_DATE to 20181102Jani Nikula2018-11-021-2/+2
| | | | Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Configure AUX_CH_CTL when enabling the AUX power domainImre Deak2018-11-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Most of the AUX_CH_CTL flags are concerned with DP AUX transfer parameters. As opposed to this the flag specifying the thunderbolt vs. non-thunderbolt mode of the port is not related to AUX transfers at all (rather it's repurposed to enable either TBT or non-TBT PHY HW blocks). The programming has to be done before enabling the corresponding AUX power well, so make it part of the power well code. v3: - Use existing enable/disable helpers instead of opencoding. (Jose) - Fix type of is_tc_tbt to remain a bitfield. (Lucas) - Add comment describing the is_tc_tbt power well flag. (Lucas) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108548 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-8-imre.deak@intel.com
* drm/i915: Move intel_aux_ch() to intel_bios.cImre Deak2018-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | From ICL onwards all the DDI/TypeC ports - even working in HDMI mode - need to know their corresponding AUX channel, so move the corresponding helper to a common place. No functional change. v4: - Fix 'no space is necessary after a cast' checkpatch warn. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-2-imre.deak@intel.com
* drm/i915: Kill GEN_FOREVERRodrigo Vivi2018-10-291-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit ac657f6461e5 ("drm/i915: Introduce IS_GEN macro") introduced GEN_FOREVER that was never used. My first attempt was to rename it to FOREVER since GEN is already part of the macro. Then I used coccinelle to change all -INTEL_GEN(e1) >= e2 +INTEL_GEN_RANGE(e1, e2, FOREVER) -INTEL_GEN(e1) <= e2 +INTEL_GEN_RANGE(e1, 0, e2) and I liked it. However I didn't like very much the remaining INTEL_GEN(dev_priv) < n and: INTEL_GEN(e1) < n INTEL_GEN_RANGE(e1, 0, n - 1) didn't make much sense either. So INTEL_GEN use for > or < seems a better unified way for unlimited bounds. So, no reason to keep GEN_FOREVER here. Let's kill before someone start using it. v2: Remove remaining GEN_FOREVER forgotten in a comment. (Daniel) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181026195143.20353-2-rodrigo.vivi@intel.com
* drm/i915: Don't apply the 16Gb DIMM wm latency w/a to BXT/GLKVille Syrjälä2018-10-241-1/+0
| | | | | | | | | | | | | | | | | | | | | The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to the appropriate platforms. This was especially harsh on GLK since we don't even try to read the DIMM information on that platforms, hence valid_dimm was always false and thus we always tried to apply the w/a. Furthermore the w/a pushed the level 0 latency above the level 1 latency, which doesn't really make sense. v2: Do the check when populating is_16gb_dimm (Mahesh) Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 86b592876cb6 ("drm/i915: Implement 16GB dimm wa for latency level-0") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181023182102.31549-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
* drm/i915/perf: add a parameter to control the size of OA bufferLionel Landwerlin2018-10-231-0/+1
| | | | | | | | | | | | | | | | | | | | | The way our hardware is designed doesn't seem to let us use the MI_RECORD_PERF_COUNT command without setting up a circular buffer. In the case where the user didn't request OA reports to be available through the i915 perf stream, we can set the OA buffer to the minimum size to avoid consuming memory which won't be used by the driver. v2: Simplify oa buffer size exponent selection (Chris) Reuse vma size field (Lionel) v3: Restrict size opening parameter to values supported by HW (Chris) v4: Drop out of date comment (Matt) Add debug message when buffer size is rejected (Matt) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181023100707.31738-5-lionel.g.landwerlin@intel.com
* drm/i915/perf: pass stream to vfuncs when possibleLionel Landwerlin2018-10-231-4/+3
| | | | | | | | | | | We want to use some of the properties of the perf stream to program the hardware in a later commit. v2: Pass only perf stream as argument (Matthew) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181023100707.31738-4-lionel.g.landwerlin@intel.com
* drm/i915/perf: remove redundant oa buffer initializationLionel Landwerlin2018-10-231-17/+0
| | | | | | | | | | | We initialize the OA buffer everytime we enable the OA unit (first call in gen[78]_oa_enable), so we don't need to initialize when preparing the metric set. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181023100707.31738-3-lionel.g.landwerlin@intel.com
* drm/i915: move intel connector specific functions to intel_connector.cJani Nikula2018-10-101-2/+0
| | | | | | | | | | Now that we have intel_connector.c, move the connector specific functions from intel_display.c there. Fix a few checkpatch complaints while at it. No functional changes. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181010075205.7713-2-jani.nikula@intel.com
* drm/i915/psr: Remove alpm from i915_psrJosé Roberto de Souza2018-10-051-1/+0
| | | | | | | | | | | | ALPM is a requirement and we don't need to keep it's cached, what were done in commit 97c9de66ca80 ("drm/i915/psr: Fix ALPM cap check for PSR2") but the alpm was not removed from i915_psr. Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181003205031.32474-7-jose.souza@intel.com
* drm/i915: Add new AML_ULX support listLee, Shawn C2018-10-051-0/+2
| | | | | | | | | | | | According to patch "drm/i915/aml: Introducing Amber Lake platform" (e364672477a1). Add a new marco for AML ULX GT2 devices. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1538034499-31256-1-git-send-email-shawn.c.lee@intel.com
* drm/i915: Add plane alpha blending support, v2.Maarten Lankhorst2018-10-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Add plane alpha blending support with the different blend modes. This has been tested on a icl to show the correct results, on earlier platforms small rounding errors cause issues. But this already happens case with fully transparant or fully opaque RGB8888 fb's. The recommended HW workaround is to disable alpha blending when the plane alpha is 0 (transparant, hide plane) or 0xff (opaque, disable blending). This is easy to implement on any platform, so just do that. The tests for userspace are also available, and pass on gen11. Changes since v1: - Change mistaken < 0xff0 to 0xff00. - Only set PLANE_KEYMSK_ALPHA_ENABLE when plane alpha < 0xff00, ignore blend mode. - Rework disabling FBC when per pixel alpha is used. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [mlankhorst: Change MISSING_CASE default to explicit alpha disable (mattrope)] Link: https://patchwork.freedesktop.org/patch/msgid/20180815103405.22679-1-maarten.lankhorst@linux.intel.com Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
* drm/i915: Reserve some priority bits for internal useChris Wilson2018-10-011-1/+1
| | | | | | | | | | | In the next few patches, we will want to give a small priority boost to some requests/queues but not so much that we perturb the user controlled order. As such we will shift the user priority bits higher leaving ourselves a few low priority bits for our internal bumping. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181001123204.23982-3-chris@chris-wilson.co.uk
* drm/i915: Remove i915.enable_ppgtt overrideChris Wilson2018-09-271-6/+8
| | | | | | | | | | | | | | | | | | | Now that we are confident in providing full-ppgtt where supported, remove the ability to override the context isolation. v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted. v3: s/USES/HAS/ to match usage and reject attempts to load the module on old GVT-g setups that do not provide support for full-ppgtt. v4: Insulate ABI ppGTT values from our internal enum (later plans involve moving ppGTT depth out of the enum, thus potentially breaking ABI unless we document the current values). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Zhi Wang <zhi.a.wang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926201222.5643-1-chris@chris-wilson.co.uk
* drm/i915: Trim partial view sg listsTvrtko Ursulin2018-09-271-0/+2
| | | | | | | | | | | | Partial views are small but there can be many of them, and since the sg list space for them is allocated pessimistically, we can save some slab by trimming the unused tail entries. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180926080353.20867-1-tvrtko.ursulin@linux.intel.com
* drm/i915/csr: keep max firmware size together with firmare name and versionJani Nikula2018-09-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | Move max firmware size to the same if ladder with firmware name and required version. This allows us to detect the missing max size for a platform without actually loading the firmware, and makes the whole thing easier to maintain. We need to move the power get earlier to allow for early return in the missing platform case. While at it, extend the comment on why we return with the reference held on errors. We also need to move the module parameter override later to reuse the max firmware size, which is independent of the override. v2: Add comment on why we leak the wakeref on errors (Chris) v3: Rebase Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926133414.22073-2-jani.nikula@intel.com
* drm/i915/csr: keep firmware name and required version togetherJani Nikula2018-09-271-0/+1
| | | | | | | | | | | Having two separate if ladders gets increasingly hard to maintain. Put them together. v2: Rebase Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926133414.22073-1-jani.nikula@intel.com
* Merge drm/drm-next into drm-intel-next-queuedJani Nikula2018-09-261-0/+1
|\ | | | | | | | | | | | | Catch up in general, and get DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT specifically. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * Merge tag 'drm-misc-next-2018-09-13' of ↵Dave Airlie2018-09-141-0/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 4.20: UAPI Changes: - Add host endian variants for the most common formats (Gerd) - Fail ADDFB2 for big-endian drivers that don't advertise BE quirk (Gerd) - clear smem_start in fbdev for drm drivers to avoid leaking fb addr (Daniel) Cross-subsystem Changes: Core Changes: - fix drm_mode_addfb() on big endian machines (Gerd) - add timeline point to syncobj find+replace (Chunming) - more drmP.h removal effort (Daniel) - split uapi portions of drm_atomic.c into drm_atomic_uapi.c (Daniel) Driver Changes: - bochs: Convert open-coded portions to use helpers (Peter) - vkms: Add cursor support (Haneen) - udmabuf: Lots of fixups (mostly cosmetic afaict) (Gerd) - qxl: Convert to use fbdev helper (Peter) Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Chunming Zhou <david1.zhou@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Peter Wu <peter@lekensteyn.nl> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> From: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20180913130254.GA156437@art_vandelay
| | * drm: Add drm/drm_util.h header fileDaniel Vetter2018-09-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a bunch of neat little macros all over the place which should move to kernel.h. But some of them died in bikesheds on lkml, and we need a decent home for them. Start out by moving the for_each_if macro there. v2: Rename to drm_util.h instead (Dave&Sean) Cc: Sean Paul <seanpaul@chromium.org> Acked-by: Sean Paul <seanpaul@chromium.org> Cc: Dave Airlie <airlied@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180905135711.28370-1-daniel.vetter@ffwll.ch
| | * drm/i915: Interactive RPS modeChris Wilson2018-08-061-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RPS provides a feedback loop where we use the load during the previous evaluation interval to decide whether to up or down clock the GPU frequency. Our responsiveness is split into 3 regimes, a high and low plateau with the intent to keep the gpu clocked high to cover occasional stalls under high load, and low despite occasional glitches under steady low load, and inbetween. However, we run into situations like kodi where we want to stay at low power (video decoding is done efficiently inside the fixed function HW and doesn't need high clocks even for high bitrate streams), but just occasionally the pipeline is more complex than a video decode and we need a smidgen of extra GPU power to present on time. In the high power regime, we sample at sub frame intervals with a bias to upclocking, and conversely at low power we sample over a few frames worth to provide what we consider to be the right levels of responsiveness respectively. At low power, we more or less expect to be kicked out to high power at the start of a busy sequence by waitboosting. Prior to commit e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request") whenever we missed the frame or stalled, we would immediate go full throttle and upclock the GPU to max. But in commit e9af4ea2b9e7, we relaxed the waitboosting to only apply if the pipeline was deep to avoid over-committing resources for a near miss. Sadly though, a near miss is still a miss, and perceptible as jitter in the frame delivery. To try and prevent the near miss before having to resort to boosting after the fact, we use the pageflip queue as an indication that we are in an "interactive" regime and so should sample the load more frequently to provide power before the frame misses it vblank. This will make us more favorable to providing a small power increase (one or two bins) as required rather than going all the way to maximum and then having to work back down again. (We still keep the waitboosting mechanism around just in case a dramatic change in system load requires urgent uplocking, faster than we can provide in a few evaluation intervals.) v2: Reduce rps_set_interactive to a boolean parameter to avoid the confusion of what if they wanted a new power mode after pinning to a different mode (which to choose?) v3: Only reprogram RPS while the GT is awake, it will be set when we wake the GT, and while off warns about being used outside of rpm. v4: Fix deferred application of interactive mode v5: s/state/interactive/ v6: Group the mutex with its principle in a substruct Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111 Fixes: e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk (cherry picked from commit 60548c554be2830d29d2533dad0ac8133347ee51) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
* | | drm/i915: Update DRIVER_DATE to 20180921Joonas Lahtinen2018-09-211-1/+1
| | | | | | | | | | | | Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
* | | drm/i915: Update DRIVER_DATE to 20180921Joonas Lahtinen2018-09-211-2/+2
| | | | | | | | | | | | Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
* | | drm/i915: pass dev_priv to i915_gem_cleanup_stolenMatthew Auld2018-09-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It really wants dev_priv anyway, also now matches i915_gem_init_stolen. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180920142707.19659-2-matthew.auld@intel.com
* | | drm/i915/execlists: Use coherent writes into the context imageChris Wilson2018-09-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | That we use a WB mapping for updating the RING_TAIL register inside the context image even on !llc machines has been a source of consternation for every reader. It appears to work on bsw+, but it may just have been that we have been incredibly bad at detecting the errors. v2: With extra enthusiasm. v3: Drop force of map type for pinned default_state as by the time we pin it, the map type is always WB and doesn't conflict with the earlier use by ce->state. v4: Transfer engine->default_state from MAP_WC to MAP_WB on creation so we do not need the MAP_FORCE littered around the backends Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180914123504.2062-3-chris@chris-wilson.co.uk
OpenPOWER on IntegriCloud