#
156adfa5 |
|
20-Sep-2023 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/i915/irq: Clear GFX_MSTR_IRQ as part of IRQ reset Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C behavior. If we do not properly reset them, we would miss delivery of interrupts if a pending bit is set when enabling IRQs. As an example, the display part of our probe routine contains paths where we wait for vblank interrupts. If a display interrupt was already pending when enabling IRQs, we would time out waiting for the vblank. Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ reset. v2: - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt) BSpec: 50875, 54028 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230920195351.59421-2-gustavo.sousa@intel.com
|
#
129ebb54 |
|
08-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: move all PCH irq postinstall calls to display code Unify on making the calls from display code. Need to add an if ladder in gen8_de_irq_postinstall() for now, but the function looks like it could be overall be better split by platform. Something for the future. The display version check for mtp seems a bit suspect, but this matches current code. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fe51744aec9e2f465caf0d699b8a15591859f89e.1691509966.git.jani.nikula@intel.com
|
#
fcc02c75 |
|
08-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: add ilk_de_irq_postinstall() Add a dedicated de postinstall function. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f4a8570881e9be28a2406134b2898b8680f9e765.1691509966.git.jani.nikula@intel.com
|
#
1007337f |
|
08-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: add dg1_de_irq_postinstall() Add a dedicated de postinstall function. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/cb6bb860fb7596d6b37c3e1e4c7657064d2d747a.1691509966.git.jani.nikula@intel.com
|
#
1486d040 |
|
08-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: add dedicated intel_display_irq_init() Continue splitting display from the rest. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/45c247c9f5104f3e25bd8913644402a11ec3afaf.1691509966.git.jani.nikula@intel.com
|
#
72e9abc3 |
|
26-Jun-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/uncore: add intel_uncore_regs() helper Add a helper for accessing uncore->regs instead of doing it directly. This will help display code reuse with the xe driver. Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230627095128.208071-1-jani.nikula@intel.com
|
#
2b874a02 |
|
15-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: split out display irq handling Split (non-hotplug) display irq handling out of i915_irq.[ch] into display/intel_display_irq.[ch]. v3: - Preserve [I915_MAX_PIPES] harder (kernel test robot) v2: - Rebase - Preserve [I915_MAX_PIPES] in functions (kernel test robot) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-3-jani.nikula@intel.com
|
#
da38ba98 |
|
15-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: split out hotplug irq handling Split hotplug irq handling out of i915_irq.[ch] into display/intel_hotplug_irq.[ch]. The line between the new intel_hotplug_irq.[ch] and the existing intel_hotplug.[ch] needs further clarification, but the first step is to move the stuff out of i915_irq.[ch]. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-2-jani.nikula@intel.com
|
#
08d8f430 |
|
15-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: convert gen8_de_irq_handler() to void The return value is not used for anything. Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230515101738.2399816-1-jani.nikula@intel.com
|
#
685282a3 |
|
04-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: relocate gmbus and dp aux irq handlers Move gmbus and dp aux irq handlers to their respective files. It should be up to them what to do with the irq, not the generic irq code. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e825385fc03cb3d53c1f0b66712eea42dad69d59.1683219363.git.jani.nikula@intel.com
|
#
c0f3faaf |
|
27-Apr-2023 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/i915/mtl: Define mask for DDI AUX interrupts Xe_LPD+ defines interrupt bits for only DDI ports in the DE Port Interrupt registers. The bits for Type-C ports are defined in the PICA interrupt registers. BSpec: 50064 Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-10-mika.kahola@intel.com
|
#
476f62b8 |
|
18-Apr-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: use explicit includes for i915_reg.h and i915_irq.h A lot of places include i915_reg.h implicitly via i915_irq.h, which gets included implicitly via intel_display_trace.h. Remove the includes from the headers, and include i915_reg.h and i915_irq.h explicitly where needed. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230419094243.366821-1-jani.nikula@intel.com
|
#
a823c5a8 |
|
17-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reuse <platform>_hotplug_mask() in .hpd_detection_setup() Replace the hardcoded masks with just a loop over all hpd pins using the <platform>_hotplug_mask() functions. v2: Deal with mtp Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v1 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-5-ville.syrjala@linux.intel.com
|
#
d28cdc43 |
|
17-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_hpd_enable_detection() Add a mechanism by which we can enable the HPD sense for individual encoders. This will be used during eDP probing to figure out if anything is actually connected. The normal intel_hpd_irq_setup() thing doesn't work since we only do that after probing the outputs, and we only enable HPD sense for encoders that were successfully probed. The other idea that crossed my minds was to just turn on HPD sense for all pins before output probing and let hpd_irq_setup() clean it up afterwards. But that doesn't work for BXT/GLK where the HPD invert information comes from the VBT child device. So looks like this really needs to be per-encoder. v2: Give it a better name (Jani) v3: Deal with mtl Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v2 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-3-ville.syrjala@linux.intel.com
|
#
40d06b0f |
|
17-Apr-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce <platform>_hotplug_mask() Pair each <platform>_hotplug_enables() function with a corresponding <platform>_hotplug_mask() function so that we can determine right bits to clear on a per hpd_pin basis. We'll need this for turning on HPD sense for a specific encoder rather than just all of them. v2: Drop the unused 'i915' param (Jani) v3: Drop the _foo_hotplug_enables() redirection too v4: Deal with mtp Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v3 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-2-ville.syrjala@linux.intel.com
|
#
d1f3b5e9 |
|
17-Apr-2023 |
Andi Shyti <andi.shyti@linux.intel.com> |
drm/i915: Make IRQ reset and postinstall multi-gt aware In multi-gt systems IRQs need to be reset and enabled per GT. This might add some redundancy when handling interrupts for engines that might not exist in every tile, but helps to keep the code cleaner and more understandable. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417235356.1291060-1-andi.shyti@linux.intel.com
|
#
86a1758d |
|
13-Apr-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: rename intel_display_driver_* functions Follow the usual naming conventions. v2: - Also rename references in comments (Gustavo) Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6ff7b76018bf4cf611037d7bf027c975cddfe2af.1681465222.git.jani.nikula@intel.com
|
#
babde06d |
|
13-Apr-2023 |
Mika Kahola <mika.kahola@intel.com> |
drm/i915/mtl: MTL PICA hotplug detection PICA is used for DP alt mode and TBT modes. Hotplug interruption is routed from PICA chip to south display engine and from there to north display engine. This patch adds functionality to enable hotplug detection for all Type-C ports (4 ports available). Differently from HPD in south display, PICA provides a dedicated HPD control register for each supported port, so we loop over ports ourselves instead of using intel_hpd_hotplug_enables() or intel_get_hpd_pins(). BSpec: 49305, 55726, 65107, 65300 Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-6-radhakrishna.sripada@intel.com
|
#
7f6947fd |
|
30-Mar-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/psr: split out PSR regs to a separate file Clean up i915_reg.h by splitting out PSR regs to display/intel_psr_regs.h. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230331090949.2858951-2-jani.nikula@intel.com
|
#
04500bfd |
|
16-Mar-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/fdi: split out FDI regs to a separate file Clean up i915_reg.h by splitting out FDI regs to display/intel_fdi_regs.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bba37e46d767e2193d49d1d2e289040c6bf8229b.1678973282.git.jani.nikula@intel.com
|
#
dded35ac |
|
02-Mar-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix SKL DDI A digital port .connected() SKL doesn't have any north DE hotplug stuff. Currently we're trying to read DDI A live state from the BDW north DE bit, instead of the approproate south DE bit. Fix it. And for good measure clear the pointer to the north hpd pin array, so that we'll actually notice if some other place is also using the wrong thing. 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/20230302161013.29213-3-ville.syrjala@linux.intel.com
|
#
95ccb25e |
|
01-Mar-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: remove unnecessary intel_pm.h includes As intel_pm.[ch] used to contain much more, intel_pm.h was included in a lot of places. Many of them are now unnecessary. Remove. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ab9a7147b0cd63d95b9f27ed40615b9c9be18f84.1677678803.git.jani.nikula@intel.com
|
#
e7e12f6e |
|
25-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Mask page table errors on gen2/3 with FBC FBC on gen2/3 seems to trigger page table errors. No visual artifacts are visible, and essentially the same FBC code works on gen4 so these seem entirely spurious. There are also hints in gen3 bspec indicating that certain bits in PGTBL_ER are just not wired up correctly in the hardware. Ideally we'd want to mask out only the bogus bits, but sadly there is no mask for PGTBL_ER, and instead we are forced to mask out all page table errors via EMR :( Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-6-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
|
#
3687ce75 |
|
25-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract {i9xx,i965)_error_mask() Pull the EMR calculation into small helpers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-5-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
|
#
d1e89592 |
|
25-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Dump PGTBL_ER on gen2/3/4 error interrupt PGTBL_ER contains the individual reasons for the page table error interrupt. Dump it out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-4-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
|
#
839259b8 |
|
25-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Undo rmw damage to gen3 error interrupt handler The gen2/gen3 irq code is supposed to be identical apart from the 32bit vs. 16bit access width. The recent change to intel_de_rmw() ruined that symmetry. Restore it to avoid needless mental gymnastics when comparing the two codepaths. And while at it remove the extra eir!=0 check that somehow ended up in the gen2 codepath only. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125185234.21599-3-ville.syrjala@linux.intel.com Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
|
#
9151c85c |
|
07-Feb-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Replace intel_bios_is_port_hpd_inverted() with intel_bios_encoder_hpd_invert() intel_bios_is_port_hpd_inverted() is only used on bxt/glk on which we always have encoder->devdata available. So consult that instead of digging around in vbt.ports[]. And rename the function to match the common pattern. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
dfefe7bc |
|
07-Feb-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass the whole encoder to hotplug_enables() bxt_hotplug_enables() needs to dig out not only the hpd_pin but also the VBT child device info, so let's just pass in the whole encoder to avoid having to look things up multiple times. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
62fe4515 |
|
16-Jan-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: split out vblank/scanline code to intel_vblank.[ch] The vblank/scanline code is fairly isolated in i915_irq.c. Split it out to new intel_vblank.[ch]. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3e3e9016f5135dccae5110c291ba048567622e7a.1673873708.git.jani.nikula@intel.com
|
#
f087cfe6 |
|
18-Dec-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence Starting from ICL, the default for MIPI GPIO sequences seems to be using native GPIOs i.e. GPIOs available in the GPU. These native GPIOs reuse many pins that quite frankly seem scary to poke based on the VBT sequences. We pretty much have to trust that the board is configured such that the relevant HPD, PP_CONTROL and GPIO bits aren't used for anything else. MIPI sequence v4 also adds a flag to fall back to non-native sequences. v5: - Wrap SHOTPLUG_CTL_DDI modification in spin_lock() in icp_irq_handler() too (Ville) - References instead of Closes issue 6131 because this does not fix everything v4: - Wrap SHOTPLUG_CTL_DDI modification in spin_lock_irq() (Ville) v3: - Fix -Wbitwise-conditional-parentheses (kernel test robot <lkp@intel.com>) v2: - Fix HPD pin output set (impacts GPIOs 0 and 5) - Fix GPIO data output direction set (impacts GPIOs 4 and 9) - Reduce register accesses to single intel_de_rwm() References: https://gitlab.freedesktop.org/drm/intel/-/issues/6131 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219105955.4014451-1-jani.nikula@intel.com
|
#
9a4cea62 |
|
14-Dec-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: ratelimit errors in display engine irq While debugging page table faults it's useful not to kill the machine with thousands of error mesages. Ratelimit all errors in gen8_de_irq_handler(). Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221215001459.3759580-1-lucas.demarchi@intel.com
|
#
963bbdb3 |
|
18-Dec-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence Starting from ICL, the default for MIPI GPIO sequences seems to be using native GPIOs i.e. GPIOs available in the GPU. These native GPIOs reuse many pins that quite frankly seem scary to poke based on the VBT sequences. We pretty much have to trust that the board is configured such that the relevant HPD, PP_CONTROL and GPIO bits aren't used for anything else. MIPI sequence v4 also adds a flag to fall back to non-native sequences. v5: - Wrap SHOTPLUG_CTL_DDI modification in spin_lock() in icp_irq_handler() too (Ville) - References instead of Closes issue 6131 because this does not fix everything v4: - Wrap SHOTPLUG_CTL_DDI modification in spin_lock_irq() (Ville) v3: - Fix -Wbitwise-conditional-parentheses (kernel test robot <lkp@intel.com>) v2: - Fix HPD pin output set (impacts GPIOs 0 and 5) - Fix GPIO data output direction set (impacts GPIOs 4 and 9) - Reduce register accesses to single intel_de_rwm() References: https://gitlab.freedesktop.org/drm/intel/-/issues/6131 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219105955.4014451-1-jani.nikula@intel.com (cherry picked from commit f087cfe6fcff58044f7aa3b284965af47f472fb0) Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
c27a2b52 |
|
15-Nov-2022 |
Jiri Slaby (SUSE) <jirislaby@kernel.org> |
drm/i915: remove circ_buf.h includes The last user of macros from that include was removed in 2018 by the commit below. Fixes: 6cc42152b02b ("drm/i915: Remove support for legacy debugfs crc interface") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221115070302.4064-1-jirislaby@kernel.org
|
#
a10234fd |
|
09-Nov-2022 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Partial abandonment of legacy DRM logging macros Convert some usages of legacy DRM logging macros into versions which tell us on which device have the events occurred. v2: * Don't have struct drm_device as local. (Jani, Ville) v3: * Store gt, not i915, in workaround list. (John) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221109104633.2579245-1-tvrtko.ursulin@linux.intel.com
|
#
ad7632ff |
|
01-Nov-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: make gen2_irq_init()/gen2_irq_reset() static The gen2 irq functions aren't used outside of i915_irq.h. Make them static, and remove the useless macro wrappers. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b28f45ef4ef69ab7a6f96ffa3fa3118994667332.1667383630.git.jani.nikula@intel.com
|
#
f7435467 |
|
17-Oct-2022 |
Andrzej Hajda <andrzej.hajda@intel.com> |
drm/i915: fix clear mask in GEN7_MISCCPCTL update GEN7_DOP_CLOCK_GATE_ENABLE bit should be cleared, not inverse. The bug was introduced during conversion to intel_uncore_rmw helper. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Fixes: 8cee664d3eb6f8 ("drm/i915: use proper helper for register updates") Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221017085525.3898649-1-andrzej.hajda@intel.com
|
#
8cee664d |
|
06-Oct-2022 |
Andrzej Hajda <andrzej.hajda@intel.com> |
drm/i915: use proper helper for register updates There is special helper for register read/modify/write. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221006163200.2803722-5-andrzej.hajda@intel.com
|
#
e58c2cac |
|
06-Oct-2022 |
Andrzej Hajda <andrzej.hajda@intel.com> |
drm/i915/display: Use intel_uncore alias if defined Alias is shorter and more readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221006163200.2803722-3-andrzej.hajda@intel.com
|
#
3703060d |
|
06-Oct-2022 |
Andrzej Hajda <andrzej.hajda@intel.com> |
drm/i915/display: remove drm_device aliases drm_device pointers are unwelcome. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221006204844.2831303-1-andrzej.hajda@intel.com
|
#
71690148 |
|
22-Sep-2022 |
Gustavo Sousa <gustavo.sousa@intel.com> |
drm/i915: Move hotplug inversion logic into separate helper Use *_hpd_invert() helpers whenever possible to isolate logic specific to hotplug inversion from common HPD setup logic to improve readability and maintainability of the source code. While we only define dg1_hpd_invert() here, future platforms are likely to have different hotplug inversion needs, thus it makes sense grouping different implementations under a common suffix. v2: Fix coding style and prefer to use small *_hdp_invert() helpers instead of a generic one. CC: Jani Nikula <jani.nikula@linux.intel.com> CC: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220922164949.163985-1-gustavo.sousa@intel.com
|
#
dd890d42 |
|
16-Sep-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/hotplug: refactor hotplug init slightly Rename intel_hpd_init_work() to the more generic intel_hpd_init_early(), and move the hotplug storm initialization there. This lets us move the HPD_STORM_DEFAULT_THRESHOLD macro to intel_hotplug.c too. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220916130634.3781122-2-jani.nikula@intel.com
|
#
03d2c54d |
|
06-Sep-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/mtl: Use primary GT's irq lock for media GT When we hook up interrupts (in the next patch), interrupts for the media GT are still processed as part of the primary GT's interrupt flow. As such, we should share the same IRQ lock with the primary GT. Let's convert gt->irq_lock into a pointer and just point the media GT's instance at the same lock the primary GT is using. v2: - Point media's gt->irq_lock at the primary GT lock properly. (Daniele) - Fix jump target for intel_root_gt_init_early errors. (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220906234934.3655440-14-matthew.d.roper@intel.com Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
7249dfcb |
|
29-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move opregion to display.opregion Move display opregion related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a0ceb5148835fa3e0828786ae491fcd11e2e77ff.1661779055.git.jani.nikula@intel.com
|
#
5a4dd6f0 |
|
24-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move hotplug to display.hotplug Move display hotplug related members under drm_i915_private display sub-struct. Rename struct i915_hotplug to intel_hotplug while at it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c1c7562a31c115e9d6a131861e4ca9c97d4f7e09.1661346845.git.jani.nikula@intel.com
|
#
203eb5a9 |
|
24-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move and group gmbus members under display.gmbus Move display gmbus related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9379e4d8982c1ddea215a3f602f08a4055928c7c.1661346845.git.jani.nikula@intel.com
|
#
5a04eb5b |
|
24-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move hotplug_funcs to display.funcs Move display hotplug functions under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1cf677f1d02b8b621ec41ff77fe5de26d4f6954a.1661346845.git.jani.nikula@intel.com
|
#
78f48aa6 |
|
16-Aug-2022 |
Bo Liu <liubo03@inspur.com> |
drm/i915/irq: Fix a "the the" typo There is an unexpected word "the" in the file i915_irq.c, fix it. Signed-off-by: Bo Liu <liubo03@inspur.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220816094919.5419-1-liubo03@inspur.com
|
#
ddcf980f |
|
21-Jul-2022 |
Anusha Srivatsa <anusha.srivatsa@intel.com> |
drm/i915: Pass drm_i915_private struct instead of gt for gen11_gu_misc_irq_handler/ack() gen11_gu_misc_irq_handler() and gen11_gu_misc_ack() do nothing tile specific. v2: gen11_gu_misc_irq_ack() tile agnostic like gen11_gu_misc_irq_handler() (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220721225100.693589-1-anusha.srivatsa@intel.com
|
#
b320c7b7 |
|
21-Jul-2022 |
Slark Xiao <slark_xiao@163.com> |
drm: Fix typo 'the the' in comment Replace 'the the' with 'the' in the comment. Signed-off-by: Slark Xiao <slark_xiao@163.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220721062345.46842-1-slark_xiao@163.com
|
#
3c0deb14 |
|
17-Feb-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/reg: split out icl_dsi_regs.h The ICL DSI registers have fairly isolated usage. Split the register macros to a separate file. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-4-jani.nikula@intel.com
|
#
2f8a6699 |
|
17-Feb-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/dg2: Enable 5th port DG2 supports a 5th display output which the hardware refers to as "TC1," even though it isn't a Type-C output. This behaves similarly to the TC1 on past platforms with just a couple minor differences: * DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on ICP/TGP/ADP. * DG2 doesn't need the hpd inversion setting that we had to use on DG1 v2: intel_ddi_init(dev_priv, PORT_TC1); [Matt] Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-3-lucas.demarchi@intel.com
|
#
24524e3f |
|
09-Feb-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move the DRIVER_* macros to i915_driver.[ch] The macros are more at home in i915_driver.[ch]. v2: Rebase 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/20220209123121.3337496-1-jani.nikula@intel.com
|
#
7e97596c |
|
03-Feb-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/hpd: hide struct intel_hotplug_funcs With intel_hpd_irq_setup() in i915_irq.c, struct intel_hotplug_funcs is also only needed there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9a10dbca7ad298dde62b83f76e0df43a67bceeef.1643896905.git.jani.nikula@intel.com
|
#
0d6419e9 |
|
27-Jan-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Move GT registers to their own header file This is a huge, chaotic mass of registers copied over as-is without any real cleanup. We'll come back and organize these better, align on consistent coding style, remove dead code, etc. in separate patches later that will be easier to review. v2: - Add missing include in intel_pxp_irq.c v3: - Correct a few indentation errors (Lucas) - Minor conflict resolution Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-6-matthew.d.roper@intel.com
|
#
96e4c3c0 |
|
12-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Bump DSL linemask to 20 bits Since tgl PIPE_DSL has 20 bits for the scanline. Let's bump our definition to match. And while at it let's also add the define for the current field readback. We can also get rid of the gen2 vs. gen3+ nonsense since none of the extra bits ever did anything and just always read as zero. And now we extend all platforms to use the tgl+ 20 bits deinition, but again that is fine since all the bits used to be mbz and always read as zero on all the platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
2cbc876d |
|
14-Dec-2021 |
Michał Winiarski <michal.winiarski@intel.com> |
drm/i915: Use to_gt() helper Use to_gt() helper consistently throughout the codebase. Pure mechanical s/i915->gt/to_gt(i915). No functional changes. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211214193346.21231-10-andi.shyti@linux.intel.com
|
#
fd2b94a5 |
|
08-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/trace: split out display trace to a separate file Add display/intel_display_trace.[ch] for defining display tracepoints. The main goal is to reduce cross-includes between gem and display. It would be possible split up tracing even further, but that would lead to more boilerplate. We end up having to include intel_crtc.h in a few places because it was pulled in implicitly via intel_de.h -> i915_trace.h -> intel_crtc.h, and that's no longer the case. There should be no changes to tracepoints. v3: - Rebase v2: - Define TRACE_INCLUDE_PATH relative to define_trace.h (Chris) - Remove useless comments (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7862ad764fbd0748d903c76bc632d3d277874e5b.1638961423.git.jani.nikula@intel.com
|
#
7794b6de |
|
01-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/crtc: rename intel_get_crtc_for_pipe() to intel_crtc_for_pipe() The "get" in the name implies reference counting, remove it. This also makes the function conform to naming style. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6105d0ff44efac3c999af6382e4b0729e251f1e1.1638366969.git.jani.nikula@intel.com
|
#
7d938bc0 |
|
12-Nov-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up DPINVGTT/VLV_DPFLIPSTAT bits Use REG_BIT() & co. for DPINVTT/VLV_DPFLIPSTAT bits. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-9-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
fd4d7904 |
|
28-Oct-2021 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: rework some irq functions to take intel_gt as argument We'll be adding multi-tile support soon; on multi-tile platforms interrupts are per-tile and every tile has the full set of interrupt registers. In this commit we start passing intel_gt instead of dev_priv for the functions that are related to Xe_HP irq handling. Right now we're still passing tile 0 everywhere, but in later patches we'll start actually passing the correct tile. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-authored-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211029032817.3747750-2-matthew.d.roper@intel.com
|
#
cd030c7c |
|
28-Sep-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: constify hotplug function vtable. Use a macro to avoid mistakes, this type of macro is only used in a couple of places. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/af229c1e8ec894f177b344ab77b90e32c33428de.1632869550.git.jani.nikula@intel.com
|
#
de1677c5 |
|
28-Sep-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915: split irq hotplug function from display vtable This provide a service from irq to display, so make it separate Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/05f533064709764dff8bcfef6a58f9a8482dc5bb.1632869550.git.jani.nikula@intel.com
|
#
ad26451a |
|
27-Aug-2021 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Drop PSR support from HSW and BDW At this point is sure that HSW and BDW will never have PSR enabled by default, so here dropping it from device info and cleaning up code. v2: - enable psr support for display 9 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210827174253.51122-1-jose.souza@intel.com
|
#
9e6dcf33 |
|
18-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: reduce inlines to reduce header dependencies Presumably if the compiler is smart, it does not generate an extra function call to the update functions that are now static. 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/594f628740717cda5ef407a26ea03129c22ddc12.1629281426.git.jani.nikula@intel.com
|
#
8b46cc65 |
|
10-Aug-2021 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915: Tweaked Wa_14010685332 for all PCHs dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix state. The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked Wa_14010685332 sequence for every PCH since PCH_CNP. v2: - removed RKL from comment and simplified condition. [Rodrigo] Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210810113112.31739-2-anshuman.gupta@intel.com
|
#
938a8a9a |
|
28-Jul-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: remove explicit CNL handling from i915_irq.c Remove special handling of PORT_F in i915_irq.c and only do it for DISPLAY_VER == 11. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-17-lucas.demarchi@intel.com
|
#
3176fb66 |
|
21-Jul-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/dg2: Add fake PCH As with DG1, DG2 has an ICL-style south display interface provided on the same PCI device. Add a fake PCH to ensure DG2 takes the appropriate codepaths for south display handling. Bspec: 54871, 50062, 49961, 53673 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-11-matthew.d.roper@intel.com
|
#
22e26af7 |
|
21-Jul-2021 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: Fork DG1 interrupt handler The current interrupt handler is getting increasingly complicated and Xe_HP changes will bring even more complexity. Let's split off a new interrupt handler starting with DG1 (i.e., when the master tile interrupt register was added to the design) and use that as the basis for the new Xe_HP changes. Now that we track the hardware IP's release number as well as the version number, we can also properly define DG1 has version "12.10" and replace the has_master_unit_irq feature flag with an IP version test. Bspec: 50875 Cc: Daniele Spurio Ceraolo <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-5-matthew.d.roper@intel.com
|
#
91b96f00 |
|
01-Jul-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Drop all references to DRM IRQ midlayer Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt functions directly. v2: * also remove an outdated comment * move IRQ fix into separate patch * update Fixes tag (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-3-tzimmermann@suse.de
|
#
27e4b467 |
|
01-Jul-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Use the correct IRQ during resume The code in xcs_resume() probably didn't work as intended. It uses struct drm_device.irq, which is allocated to 0, but never initialized by i915 to the device's interrupt number. Change all calls to synchronize_hardirq() to intel_synchronize_irq(), which uses the correct interrupt. _hardirq() functions are not needed in this context. v5: * go back to _hardirq() after PCI probe reported wrong context; add rsp comment v4: * switch everything to intel_synchronize_irq() (Daniel) v3: * also use intel_synchronize_hardirq() at another callsite v2: * wrap irq code in intel_synchronize_hardirq() (Ville) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-2-tzimmermann@suse.de
|
#
ac1723c1 |
|
25-Jun-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Track IRQ state in local device state Replace usage of struct drm_device.irq_enabled with the driver's own state field struct drm_i915_private.irq_enabled. The field in the DRM device structure is considered legacy and should not be used by KMS drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210625082222.3845-7-tzimmermann@suse.de
|
#
f15f01a7 |
|
09-Jun-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/intel_crtc/crtc/ Clear out the straggler 'intel_crtc' variables. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-7-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
b8441b28 |
|
10-Aug-2021 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915: Tweaked Wa_14010685332 for all PCHs dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix state. The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked Wa_14010685332 sequence for every PCH since PCH_CNP. v2: - removed RKL from comment and simplified condition. [Rodrigo] Fixes: b896898c7369 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210810113112.31739-2-anshuman.gupta@intel.com (cherry picked from commit 8b46cc6577f4bbef7e5909bb926da31d705f350f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
3dd6c11b |
|
01-Jul-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Drop all references to DRM IRQ midlayer Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt functions directly. v2: * also remove an outdated comment * move IRQ fix into separate patch * update Fixes tag (Daniel) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-3-tzimmermann@suse.de (cherry picked from commit 91b96f0008a2d66d76b525556e4818f5a4a089e4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
320ad343 |
|
01-Jul-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Use the correct IRQ during resume The code in xcs_resume() probably didn't work as intended. It uses struct drm_device.irq, which is allocated to 0, but never initialized by i915 to the device's interrupt number. Change all calls to synchronize_hardirq() to intel_synchronize_irq(), which uses the correct interrupt. _hardirq() functions are not needed in this context. v5: * go back to _hardirq() after PCI probe reported wrong context; add rsp comment v4: * switch everything to intel_synchronize_irq() (Daniel) v3: * also use intel_synchronize_hardirq() at another callsite v2: * wrap irq code in intel_synchronize_hardirq() (Ville) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210701173618.10718-2-tzimmermann@suse.de (cherry picked from commit 27e4b467d94e216b365da388358c9407af818662) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
651e7d48 |
|
05-Jun-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: replace IS_GEN and friends with GRAPHICS_VER This was done by the following semantic patch: @@ expression i915; @@ - INTEL_GEN(i915) + GRAPHICS_VER(i915) @@ expression i915; expression E; @@ - INTEL_GEN(i915) >= E + GRAPHICS_VER(i915) >= E @@ expression dev_priv; expression E; @@ - !IS_GEN(dev_priv, E) + GRAPHICS_VER(dev_priv) != E @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + GRAPHICS_VER(dev_priv) == E @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_GRAPHICS_VER(dev_priv, from, until) @def@ expression E; identifier id =~ "^gen$"; @@ - id = GRAPHICS_VER(E) + ver = GRAPHICS_VER(E) @@ identifier def.id; @@ - id + ver It also takes care of renaming the variable we assign to GRAPHICS_VER() so to use "ver" rather than "gen". Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210606045050.103862-2-lucas.demarchi@intel.com
|
#
8bcc0840 |
|
25-May-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/xelpd: Enhanced pipe underrun reporting XE_LPD brings enhanced underrun recovery: the hardware can somewhat mitigate underruns by using an interpolated replacement pixel (soft underrun) or the previous pixel (hard underrun). Furthermore, underruns can now be caused downstream by the port, even if the pipe itself is operating properly. The interrupt register and PIPE_STATUS register give us extra bits to recognize hard/soft underruns and determine whether the underrun was caused by the port, so we'll use that information to print some more descriptive errors when underruns occur. v2: - Keep ICL's PIPE_STATUS defined separately from the old GMCH pipe status register. (Ville) - Only read/clear the PIPE_STATUS register on platforms with display ver >= 11. (Lucas) v3: - Actually enable+unmask all the new underrun interrupts, clear stale bits out from PIPE_STATUS before enabling the interrupts, report all FIFO underruns errors at once, rename a bunch of stuff to unconfuse vs. PIPESTAT. (Ville) Bspec: 50335 Bspec: 50366 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210526000656.3060314-2-matthew.d.roper@intel.com
|
#
0669a6e1 |
|
21-May-2021 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Move CS interrupt handler to the backend The different submission backends each have their own preferred behaviour and interrupt setup. Let each handle their own interrupts. This becomes more useful later as we to extract the use of auxiliary state in the interrupt handler that is backend specific. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210521183215.65451-4-matthew.brost@intel.com
|
#
1649a4cc |
|
11-May-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/xelpd: Define plane capabilities XE_LPD's plane support is identical to RKL and ADL-S --- 5 universal + 1 cursor with NV12 UV support on planes 1-3 and NV12 Y support on planes 4-5. v2: - Drop the extra 90/270 rotation check in skl_plane_check_fb(); the DRM property code will already prevent userspace from passing us values that weren't advertised. (Lucas) Bspec: 53657 Bspec: 49251 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-3-matthew.d.roper@intel.com
|
#
20fe778f |
|
11-May-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/xelpd: Handle proper AUX interrupt bits XE_LPD has new AUX interrupt bits for DDI-D and DDI-E that take the spots that were used by TC5/TC6 on Display12 platforms. While we're at it, let's convert the bit definitions for all TGL+ aux bits over to the modern REG_BIT() notation. v2: - Maintain bit order rather than logical order. (Lucas) - Convert surrounding code to REG_BIT() notation. (Lucas) Bspec: 50064 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210512042144.2089071-2-matthew.d.roper@intel.com
|
#
7785ae0b |
|
30-Apr-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't include intel_de.h from intel_display_types.h Hoist the intel_de.h include from intel_display_types.h one level up. I need this in order to untangle the include order so that I can add tracepoints into intel_de.h. This little cocci script did most of the work for me: @find@ @@ ( intel_de_read(...) | intel_de_read_fw(...) | intel_de_write(...) | intel_de_write_fw(...) ) @has_include@ @@ ( #include "intel_de.h" | #include "display/intel_de.h" ) @depends on find && !has_include@ @@ + #include "intel_de.h" #include "intel_display_types.h" @depends on find && !has_include@ @@ + #include "display/intel_de.h" #include "display/intel_display_types.h" Cc: Cooper Chiou <cooper.chiou@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.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/20210430143945.6776-1-ville.syrjala@linux.intel.com
|
#
93e7e61e |
|
12-Apr-2021 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/display: rename display version macros While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
|
#
2446e1d6 |
|
07-Apr-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate IS_GEN9_{BC,LP} Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com (cherry picked from commit 70bfb30743d5da73058b0a2271e9c127a84fb494) [Jani: cherry picked to topic branch to reduce conflicts] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
a844cfbe |
|
08-Apr-2021 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915: Skip display interruption setup when display is not available Return ealier in the functions doing interruption setup for GEN8+ also adding a warning in gen8_de_irq_handler() to let us know that something else is still missing. Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210408203150.237947-1-jose.souza@intel.com
|
#
70bfb307 |
|
07-Apr-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate IS_GEN9_{BC,LP} Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com
|
#
373abf1a |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Convert INTEL_GEN() to DISPLAY_VER() as appropriate in i915_irq.c Convert the display-specific usage of INTEL_GEN, while leaving the non-display usage as-is for now. In the near-future we'll probably want to think about moving display interrupt handling to its own file under the display/ directory. v2: - Use new IS_DISPLAY_VER() macro. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-6-matthew.d.roper@intel.com
|
#
2c6afc36 |
|
04-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Return zero as the scanline counter for disabled pipes We print the scanline counters as unsigned integers so the -1 here just makes the debugs/traces look a bit messy. Zero seems equally valid for this usecase. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
cec3295b |
|
16-Feb-2021 |
Lyude Paul <lyude@redhat.com> |
drm/i915/icp+: Use icp_hpd_irq_setup() instead of spt_hpd_irq_setup() While reviewing patches for handling workarounds related to gen9 bc, Imre from Intel discovered that we're using spt_hpd_irq_setup() on ICP+ PCHs despite it being almost the same as icp_hpd_irq_setup(). Since we need to be calling icp_hpd_irq_setup() to ensure that CML-S/TGP platforms function correctly anyway, let's move platforms using PCH_ICP which aren't handled by gen11_hpd_irq_setup() over to icp_hpd_irq_setup(). Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210217025337.1929015-2-lyude@redhat.com
|
#
59b7cb44 |
|
17-Feb-2021 |
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> |
drm/i915/gen9bc: Handle TGP PCH during suspend/resume For Legacy S3 suspend/resume GEN9 BC needs to enable and setup TGP PCH. v2: * Move Wa_14010685332 into it's own function - vsyrjala * Add TODO comment about figuring out if we can move this workaround - imre v3: * Rename cnp_irq_post_reset() to cnp_display_clock_wa() * Add TODO item mentioning we need to clarify which platforms this workaround applies to * Just use ibx_irq_reset() in gen8_irq_reset(). This code should be functionally equivalent on gen9 bc to the code v2 added * Drop icp_hpd_irq_setup() call in spt_hpd_irq_setup(), this looks to be more or less identical to spt_hpd_irq_setup() minus additionally enabling one port. Will update i915 to use icp_hpd_irq_setup() for ICP in a separate patch. v4: * Revert Wa_14010685332 system list in comments to how it was before * Add back HAS_PCH_SPLIT() check before calling ibx_irq_reset() Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210217180016.1937401-1-lyude@redhat.com
|
#
a22af61d |
|
09-Feb-2021 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Rename for_each_intel_encoder.*_can_psr to for_each_intel_encoder.*_with_psr for_each_intel_encoder.*_"can_psr" sounds strange, in my opinion "with_psr" is better. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-1-jose.souza@intel.com
|
#
b64d6c51 |
|
04-Feb-2021 |
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> |
drm/i915/display: Support PSR Multiple Instances It is a preliminary work for supporting multiple EDP PSR and DP PanelReplay. And it refactors singleton PSR to Multi Transcoder supportable PSR. And this moves and renames the i915_psr structure of drm_i915_private's to intel_dp's intel_psr structure. It also causes changes in PSR interrupt handling routine for supporting multiple transcoders. But it does not change the scenario and timing of enabling and disabling PSR. And it not support multiple pipes with a single transcoder PSR case yet. v2: Fix indentation and add comments v3: Remove Blank line v4: Rebased v5: Rebased and Addressed Anshuman's review comment. - Move calling of intel_psr_init() to intel_dp_init_connector() v6: Address Anshuman's review comments - Remove wrong comments and add comments for a limit of supporting of a single pipe PSR v7: Update intel_psr_compute_config() for supporting multiple transcoder PSR on BDW+ v8: Address Anshuman's review comments - Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn() v9: Fix commit message v10: Rebased v11: Address Jose's review comment. - Reorder calling order of intel_psr2_program_trans_man_trk_ctl(). - In order to reduce changes keep the old name for drm_i915_private. - Change restrictions of multiple instances of PSR. v12: Address Jose's review comment. - Change the calling of intel_psr2_program_trans_man_trk_ctl() into commit_pipe_config(). - Change a checking order of CAN_PSR() and connector_status to original on i915_psr_sink_status_show(). - Drop unneeded intel_dp_update_pipe() function. - In order to wait a specific encoder which belong to crtc_state on intel_psr_wait_for_idle(), add checking of encoder. - Add an whitespace to comments. v13: Rebased and Address Jose's review comment. - Add and use for_each_intel_psr_enabled_encoder() macro. - In order to use correct frontbuffer_bit for each pipe, fix intel_psr_invalidate() and intel_psr_flush(). - Remove redundant or unneeded codes. - Update comments. v14: Address Jose's review comment - Add and use for_each_intel_encoder_can_psr() macro and for_each_intel_encoder_mask_can_psr() macro. - Add source_support member variable into intel_psr structure. - Update CAN_PSR() macro that checks source_support. - Move encoder's PSR availity check to psr_init() from psr_compute_config(). - Remove redundant or unneeded codes. v15: Remove wrong mutex lock/unlock of PSR from intel_psr2_program_trans_man_trk_ctl() Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204134015.419036-1-gwan-gyeong.mun@intel.com
|
#
8ff5446a |
|
28-Jan-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Remove references to struct drm_device.pdev Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v6: * also remove assignment in selftests/ in a later patch (Chris) v5: * remove assignment in later patch (Chris) v3: * rebased v2: * move gt/ and gvt/ changes into separate patches Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-2-tzimmermann@suse.de
|
#
a75816e8 |
|
29-Jan-2021 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Add HAS_D12_PLANE_MINIMIZATION - As RKL and ADL-S only have 5 planes, primary and 4 sprites and the cursor plane, let's group the handling together under HAS_D12_PLANE_MINIMIZATION. - Also use macro to select pipe irq fault error mask. BSpec: 49251 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129182945.217078-5-aditya.swarup@intel.com
|
#
fa58c9e4 |
|
25-Jan-2021 |
Anusha Srivatsa <anusha.srivatsa@intel.com> |
drm/i915/adl_s: Add Interrupt Support ADLS follows ICP/TGP like interrupts. v2: Use "INTEL_PCH_TYPE(dev_priv) >= PCH_ICP" of hpd_icp (Lucas) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210125140753.347998-4-aditya.swarup@intel.com
|
#
6ede6b06 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flips for vlv/chv Add support for async flips on vlv/chv. Unlike all the other platforms vlv/chv do not use the async flip bit in DSPCNTR and instead we select between async vs. sync flips based on the surface address register. The normal DSPSURF generates sync flips DSPADDR_VLV generates async flips. And as usual the interrupt bits are different from the other platforms. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-12-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
4bb18054 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flip for ilk/snb Add support for async flips on ivb/hsw. Again no need for any workarounds and just have to deal with the interrupt bits being shuffled around a bit. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-11-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
2a636e24 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flip for ivb/hsw Add support for async flips on ivb/hsw. Unlike bdw+ we don't need any workarounds to disable async flips. Apart from that the only real difference from the bdw implementation is the location of the flip_done interrupt bits. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-10-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
cda195f1 |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement async flips for bdw Implement async flip support for BDW. The implementation is similar to the skl+ code. And just like skl/bxt/glk bdw also needs the disable w/a, thus we need to plumb the desired state of the async flip all the way down to i9xx_plane_ctl_crtc(). According to the spec we do need to bump the surface alignment to 256KiB for this. Async flips require an X-tiled buffer so we don't have to worry about linear. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-9-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
7a2ec4a0 |
|
22-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix vblank timestamps with VRR To get sensible vblank timestamping behaviour we need to feed the vmax based timings to the vblank code, otherwise it'll chop off the scanline counter when it exceeds the minumum vtotal. Additionally with VRR we have three cases to consider when we generate the vblank timestamp: 1) we are in vertical active -> nothing special needs to be done, just return the current scanout position and the core will calculate the timestamp corresponding to the past time when the current vertical active started 2) we are in vertical blank and no push has been sent -> the hardware will keep extending the vblank presumably to its maximum length, so we make the timestmap match the expected time when the max length vblank will end. Since the timings used for this are now based on vmax nothing special actually needs to be done 3) we are in vblank and a push has been sent so the vblank is about to terminate -> presumably we want the timestmap to accurately reflect when the vblank will terminate, so we use the sampled frame timestamp vs. current timestamp to guesstimate how far along the vblank exit we are, and then we adjust the reported scanout position accordingly so that the core will see that the vblank is close to ending. v2: * Fix the else if (use_scanline_Counter) (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-17-manasi.d.navare@intel.com
|
#
06d6fda5 |
|
22-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_crtc_scanlines_since_frame_timestamp() Extract intel_crtc_scanlines_since_frame_timestamp() from __intel_get_crtc_scanline_from_timestamp(). We'll reuse this for VRR vblank timestamps. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-5-manasi.d.navare@intel.com
|
#
8693ee2e |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add plane vfuncs to enable/disable flip_done interrupt Prepare for more platforms with async flip support by turning the flip_done interrupt enable/disable into plane vfuncs. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-6-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
33ef04fa |
|
11-Jan-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop redundant parens Drop the pointless extra parens. Cc: Karthik B S <karthik.b.s@intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-4-ville.syrjala@linux.intel.com Reviewed-by: Karthik B S <karthik.b.s@intel.com>
|
#
4294fa5f |
|
04-Dec-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reduce duplicated switch cases in hpd code With GEN11_HOTPLUG_CTL_LONG_DETECT(), SHOTPLUG_CTL_DDI_HPD_LONG_DETECT() and ICP_TC_HPD_LONG_DETECT() taking the hpd_pin as their argument we can remove some duplication in the long_detect() switch statements. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204182309.14213-1-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
#
2939eb06 |
|
30-Nov-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: replace I915_READ()/WRITE() with intel_uncore_read()/write() Arguably some of these should use intel_de_read() or intel_de_write(), however not all. Prioritize I915_READ() and I915_WRITE() removal in general over migrating to the pedantically correct replacements right away. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201130111601.2817-8-jani.nikula@intel.com
|
#
e5346a1f |
|
27-Nov-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
Revert "drm/i915: re-order if/else ladder for hpd_irq_setup" We now use ilk_hpd_irq_setup for all GMCH platforms that do not have hotplug. These are early gen3 and gen2 devices that now explode on boot as they try to access non-existent registers. Fixes: 794d61a19090 ("drm/i915: re-order if/else ladder for hpd_irq_setup") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201127145748.29491-1-chris@chris-wilson.co.uk
|
#
2ccf2e03 |
|
27-Nov-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
Revert "drm/i915: re-order if/else ladder for hpd_irq_setup" We now use ilk_hpd_irq_setup for all GMCH platforms that do not have hotplug. These are early gen3 and gen2 devices that now explode on boot as they try to access non-existent registers. Fixes: 794d61a19090 ("drm/i915: re-order if/else ladder for hpd_irq_setup") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201127145748.29491-1-chris@chris-wilson.co.uk (cherry picked from commit e5346a1ff38a405c14ce8e595269e9b7dcfbb2e9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
9c6508b9 |
|
10-Dec-2020 |
Thomas Gleixner <tglx@linutronix.de> |
drm/i915/pmu: Replace open coded kstat_irqs() copy Driver code has no business with the internals of the irq descriptor. Aside of that the count is per interrupt line and therefore takes interrupts from other devices into account which share the interrupt line and are not handled by the graphics driver. Replace it with a pmu private count which only counts interrupts which originate from the graphics card. To avoid atomics or heuristics of some sort make the counter field 'unsigned long'. That limits the count to 4e9 on 32bit which is a lot and postprocessing can easily deal with the occasional wraparound. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://lore.kernel.org/r/20201210194043.957046529@linutronix.de
|
#
b896898c |
|
10-Nov-2020 |
Bob Paauwe <bob.j.paauwe@intel.com> |
drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms The WA specifies that we need to toggle a SDE chicken bit on and then off as the final step in preparation for s0ix entry. Bspec: 33450 Bspec: 8402 However, something is happening after we toggle the bit that causes the WA to be invalidated. This makes dispcnlunit1_cp_xosc_clkreq active being already in s0ix state i.e SLP_S0 counter incremented. Tweaking the Wa_14010685332 by setting the bit on suspend and clearing it on resume turns down the dispcnlunit1_cp_xosc_clkreq. B.Spec has Documented this tweaked sequence of WA as an alternative. Let keep this tweaked WA for Gen11 platforms and keep untweaked WA for other platforms which never observed this issue. v2 (MattR): - Change the comment on the workaround to give PCH names rather than platform names. Although the bspec is setup to list workarounds by platform, the hardware team has confirmed that the actual issue being worked around here is something that was introduced back in the Cannon Lake PCH and carried forward to subsequent PCH's. - Extend the untweaked version of the workaround to include PCH_CNP as well. Note that since PCH_CNP is used to represent CMP, this will apply on CML and some variants of RKL too. - Cap the untweaked version of the workaround so that it won't apply to "fake" PCH's (i.e., DG1). The issue we're working around really is an issue in the PCH itself, not the South Display, so it shouldn't apply when there isn't a real PCH. v3: - use intel_de_rmw(). [Rodrigo] Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201110121700.4338-1-anshuman.gupta@intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
9a450b68 |
|
06-Nov-2020 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Do not setup hpd without display Now that hpd/display related calls are split from the rest in intel_irq_init(), skip all of that in case we don't have display. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-8-lucas.demarchi@intel.com
|
#
96bd87b7 |
|
06-Nov-2020 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: move display-related to the end of intel_irq_init() In intel_irq_init() move what's display/hpd related after what is gt and guc. This makes it easier to support !HAS_DISPLAY() in future. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-7-lucas.demarchi@intel.com
|
#
794d61a1 |
|
06-Nov-2020 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: re-order if/else ladder for hpd_irq_setup Use the convention of new platforms first. No need to special case HAS_GMCH() since that stopped being true at the lattest on gen8 (for cherryview). Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201106225531.920641-6-lucas.demarchi@intel.com
|
#
a0a6d8cb |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Get rid of ibx_irq_pre_postinstall() ibx_irq_pre_postinstall() looks totally pointless. We can just init both SDEIMR and SDEIER at the same time before enabling the master interrupt. It's equally racy as the other order due to doing all of this from the postinstall stage with the interrupt handler already in place. That is, safe with MSI but racy with shared legacy interrupts. Fortunately we should have MSI on all ilk+. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-20-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
#
9696f041 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use GEN3_IRQ_INIT() to init south interrupts in icp+ No reason not to use GEN3_IRQ_INIT() on icp+. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-19-ville.syrjala@linux.intel.com
|
#
2ea63927 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable hpd logic only for ports that are present Let's enable the hardware hpd logic only for the ports we can actually use. In theory this may save some miniscule amounts of power, and more importantly it eliminates a lot if platform specific codepaths since the generic thing can now deal with any combination of ports being present on each SKU. v2: Deal with DG1 v3: Deal with DG1 some more Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-18-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
#
e76ab2cf |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove per-platform IIR HPD masking We no longer unmask all HPD irqs, so we can drop the ugly per-platform HPD IIR masking. IMR will prevent unsupported bits from appearing in IIR. v2: Deal with DG1 Include "HOTPLUG" in the mask names (Lucas) v3: Fix typos in subject Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-17-ville.syrjala@linux.intel.com
|
#
9a55a620 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rename 'tmp_mask' Replace this silly tmp_mask with hotplug_trigger/te_trigger where appropriate. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-16-ville.syrjala@linux.intel.com
|
#
f6576e46 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't enable hpd detection logic from irq_postinstall() No reason that I can see why we should enable the hpd detection logic already during irq postinstall phase. We don't even do this on all the platforms. We just need it before we actually enable the hotplug interrupts in .hpd_irq_setup(), and in fact we already do it there as well. Let's just eliminate the redundant early setup. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-15-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
#
52c7f5f1 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split gen11_hpd_detection_setup() into tc vs. tbt variants No reason to stuff both type-c and tbt into the same function. Let's split this so we may more easily handle platforms that lack the tbt spefific bits. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-14-ville.syrjala@linux.intel.com
|
#
a0e066b8 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Relocate intel_hpd_{enabled,hotplug}_irqs() Move intel_hpd_{enabled,hotplug}_irqs() closes to the beginning of the file so we can use them in more places. No functional changes. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-13-ville.syrjala@linux.intel.com
|
#
97011359 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/tc_port/hpd_pin/ in icp+ TC hotplug bits Parametrize the icp+ TC HPD bits using hpd_pin rather than tc_port so it's clear what kind of an animal we're dealing with. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-12-ville.syrjala@linux.intel.com
|
#
5b76e860 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/tc_port/hpd_pin/ in GEN11_{TC,TBT}_HOTPLUG() Use hpd_pin instead of tc_port in the GEN11_{TC,TBT}_HOTPLUG() to make it clear what they refer to. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-11-ville.syrjala@linux.intel.com
|
#
5f371a81 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/port/hpd_pin/ for icp+ ddi hpd bits Use hpd_pin instead of port in the parametrized ICP+ DDI HPD macros. Makes it clear what these refer to. v2: Handle DG1 Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-10-ville.syrjala@linux.intel.com
|
#
e5abaab3 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce GEN8_DE_PORT_HOTPLUG() Unify the BDW/BXT hotplug bits. BDW only has port A, but that matches BXT port A so we can shar the same macro for both. v2: Remember the gvt Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-9-ville.syrjala@linux.intel.com
|
#
8625b221 |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Parametrize BXT_DE_PORT_HP_DDI with hpd_pin Use hpd_pin to parametrize BXT_DE_PORT_HP_DDI() to make it clear these have nothing to do with DDI ports or PHYs as such. The only thing that matters is the HPD pin assignment. v2: Remember the gvt Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-8-ville.syrjala@linux.intel.com
|
#
320c670c |
|
28-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/PORT_TC/TC_PORT_/ Make the namespacing for enum tc_port better by adding the TC_ to the actual enum values. v2: Drop the extra TC (Lucas) Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201028213323.5423-2-ville.syrjala@linux.intel.com
|
#
b18c1eb9 |
|
21-Oct-2020 |
Clinton A Taylor <clinton.a.taylor@intel.com> |
drm/i915/dg1: invert HPD pins HPD pins are inverted for DG1 platform. Bspec: 49956 Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Clinton A Taylor <clinton.a.taylor@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021082034.3170478-3-lucas.demarchi@intel.com
|
#
229f31e2 |
|
21-Oct-2020 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/dg1: add hpd interrupt handling DG1 has one more combo phy port, no TC and all irq handling goes through SDE, like for MCC. v2: Also change intel_hpd_pin_default() to include DG1 mapping v3, v4: Rebase on hpd refactor Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021082034.3170478-2-lucas.demarchi@intel.com
|
#
e44adb5d |
|
21-Oct-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reset the interrupt mask on disabling interrupts As we disable the interrupt during suspend, also reset the irq_mask to short-circuit subsystems that later try to turn off their interrupt source. <4>[ 101.816730] i915 0000:00:02.0: drm_WARN_ON(!intel_irqs_enabled(dev_priv)) <4>[ 101.816853] WARNING: CPU: 3 PID: 4241 at drivers/gpu/drm/i915/i915_irq.c:343 ilk_update_display_irq+0xb3/0x130 [i915] v2: Reset irq_mask for i8xx_irq_reset as well, and split patch to focus on only i915->irq_mask Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201022114246.28566-1-chris@chris-wilson.co.uk
|
#
c6073d4c |
|
21-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up the irq enable/disable for ilk rps Let's unmask the PCU event irq _after_ we've set up the hardware and software to deal with the fallout. We can also drop the PCU event bit from DEIER except when we need it for rps. And on the disable side we replace the hand rolled (and unlocked) DEIER/IIR/IMR frobbing with ilk_disable_display_irq(). Ocd does require me to reorder it to be symmetric with the enable path however. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-5-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a9922912 |
|
21-Oct-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Do gen5_gt_irq_postinstall() before enabling the master interrupt Let's make sure the lower level interrupt bits are all lined up before we flip on the master interrupt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201021131443.25616-4-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
33267703 |
|
24-Sep-2020 |
Vandita Kulkarni <vandita.kulkarni@intel.com> |
drm/i915/dsi: Enable software vblank counter In case of DSI cmd mode, we get hw vblank counter updated after the TE comes in, if we try to read the hw vblank counter in te handler we wouldnt have the udpated vblank counter yet. This will lead to a state where we would send the vblank event to the user space in the next te, though the frame update would have completed in the first TE duration itself. Hence switch to using software timestamp based vblank counter. v2: Use mode_flags from crtc_state (Ville) Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-6-vandita.kulkarni@intel.com
|
#
00acb329 |
|
24-Sep-2020 |
Vandita Kulkarni <vandita.kulkarni@intel.com> |
drm/i915/dsi: Add TE handler for dsi cmd mode. In case of dual link, we get the TE on slave. So clear the TE on slave DSI IIR. If we are operating in TE_GATE mode, after we do a frame update, the transcoder will send the frame data to the panel, after it receives a TE. Whereas if we are operating in NO_GATE mode then the transcoder will immediately send the frame data to the panel. We are not dealing with the periodic command mode here. v2: Pass only relevant masked bits to the handler (Jani) v3: Fix the check for cmd mode in TE handler function. v4: Use intel_handle_vblank instead of drm_handle_vblank (Jani) v3: Use static on handler func (Jani) Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-4-vandita.kulkarni@intel.com
|
#
9c9e97c4 |
|
24-Sep-2020 |
Vandita Kulkarni <vandita.kulkarni@intel.com> |
i915/dsi: Configure TE interrupt for cmd mode Configure TE interrupt as part of the vblank enable call flow. v2: Hide the private flags check inside configure_te (Jani) v3: Fix the position of masking de_port_masked for DSI_TE. v4: Simplify the caller of configure_te (Jani) v5: Clear IIR, remove the usage of private_flags v6: including icl_dsi header is not needed Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200924124209.17916-3-vandita.kulkarni@intel.com
|
#
1288f9b0 |
|
21-Sep-2020 |
Karthik B S <karthik.b.s@intel.com> |
drm/i915: Add enable/disable flip done and flip done handler Add enable/disable flip done functions and the flip done handler function which handles the flip done interrupt. Enable the flip done interrupt in IER. Enable flip done function is called before writing the surface address register as the write to this register triggers the flip done interrupt Flip done handler is used to send the page flip event as soon as the surface address is written as per the requirement of async flips. The interrupt is disabled after the event is sent. v2: -Change function name from icl_* to skl_* (Paulo) -Move flip handler to this patch (Paulo) -Remove vblank_put() (Paulo) -Enable flip done interrupt for gen9+ only (Paulo) -Enable flip done interrupt in power_well_post_enable hook (Paulo) -Removed the event check in flip done handler to handle async flips without pageflip events. v3: -Move skl_disable_flip_done out of interrupt handler (Paulo) -Make the pending vblank event NULL in the beginning of flip_done_handler to remove sporadic WARN_ON that is seen. v4: -Calculate timestamps using flip done time stamp and current timestamp for async flips (Ville) v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter' static.(Reported-by: kernel test robot <lkp@intel.com>) -Fix the typo in commit message. v6: -Revert back to old time stamping code. -Remove the break while calling skl_enable_flip_done. (Paulo) v7: -Rebased. v8: -Rebased. v9: -Use struct drm_i915_private *i915 in new code. (Ville) -Use intel_crtc instead of drm_crtc. (Ville) -Do not mix the flip done and vblank hooks. (Ville) v10: -Rebased. Signed-off-by: Karthik B S <karthik.b.s@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200921110210.21182-2-karthik.b.s@intel.com
|
#
6d3144eb |
|
30-Jun-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_hpd_hotplug_irqs() Introduce intel_hpd_hotplug_irqs() as a partner to intel_hpd_enabled_irqs(). There's no need to care about the encoders which we're not exposing, so we can avoid hardcoding the masks in various places. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-12-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
da51e4ba |
|
30-Jun-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce HPD_PORT_TC<n> Make a clean split between hpd pins for DDI vs. TC. This matches how the actual hardware is split. And with this we move the DDI/PHY->HPD pin mapping into the encoder init instead of having to remap yet again in the interrupt code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-11-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
815f4ef2 |
|
30-Jun-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split icp_hpd_detection_setup() into ddi vs. tc parts No reason to stuff both DDI and TC port handling into the same function. Split it into two. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-9-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
1db9f992 |
|
30-Jun-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Configure GEN11_{TBT,TC}_HOTPLUG_CTL for ports TC5/6 gen11_hpd_detection_setup() is missing ports TC5/6. Add them. TODO: Might be nice to only enable the hpd detection logic for ports we actually have. Should be rolled out for all platforms if/when done... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-8-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
a52bfcdd |
|
30-Jun-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Nuke the redundant TC/TBT HPD bit defines We have nice parametrized GEN11_{TC,TBT}_HOTPLUG() so nuke the overlapping defines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200630215601.28557-7-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
b3786b29 |
|
31-Jul-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Distinguish the virtual breadcrumbs from the irq breadcrumbs On the virtual engines, we only use the intel_breadcrumbs for tracking signaling of stale breadcrumbs from the irq_workers. They do not have any associated interrupt handling, active requests are passed to a physical engine and associated breadcrumb interrupt handler. This causes issues for us as we need to ensure that we do not actually try and enable interrupts and the powermanagement required for them on the virtual engine, as they will never be disabled. Instead, let's specify the physical engine used for interrupt handler on a particular breadcrumb. v2: Drop b->irq_armed = true mocking for no interrupt HW Fixes: 4fe6abb8f513 ("drm/i915/gt: Ignore irq enabling on the virtual engines") Signed-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/20200731154834.8378-4-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
f619e516 |
|
13-Jul-2020 |
Anusha Srivatsa <anusha.srivatsa@intel.com> |
drm/i915/dg1: Remove SHPD_FILTER_CNT register programming Bspec asks us to remove the special programming of the SHPD_FILTER_CNT register which we have been doing since CNP+. Bspec: 49305 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713182321.12390-5-lucas.demarchi@intel.com
|
#
97b492f5 |
|
13-Jul-2020 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/dg1: add support for the master unit interrupt DG1 has master unit interrupt register which is used to indicate the correct source of interrupt. v2: fix coding style on register definition Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Daniele Spurio Ceraolo <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200713182321.12390-4-lucas.demarchi@intel.com
|
#
1e8110a6 |
|
17-Jun-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Extend Wa_14010685332 to all ICP+ PCH's This workaround now also applies to TGL and RKL, so extend the PCH test to just capture everthing ICP and beyond. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200617180006.4130501-1-matthew.d.roper@intel.com Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
|
#
a3005c2e |
|
12-Jun-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl+: Fix hotplug interrupt disabling after storm detection Atm, hotplug interrupts on TypeC ports are left enabled after detecting an interrupt storm, fix this. Reported-by: Kunal Joshi <kunal1.joshi@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/351 Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964 Cc: Kunal Joshi <kunal1.joshi@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612121731.19596-1-imre.deak@intel.com (cherry picked from commit 587a87b9d7e94927edcdea018565bc1939381eb1) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
587a87b9 |
|
12-Jun-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/icl+: Fix hotplug interrupt disabling after storm detection Atm, hotplug interrupts on TypeC ports are left enabled after detecting an interrupt storm, fix this. Reported-by: Kunal Joshi <kunal1.joshi@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/351 Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964 Cc: Kunal Joshi <kunal1.joshi@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200612121731.19596-1-imre.deak@intel.com
|
#
562ddcb7 |
|
03-Jun-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/rkl: Don't try to access transcoder D There are a couple places in our driver that loop over transcoders A..D for gen11+; since RKL only has three pipes/transcoders, this can lead to unclaimed register reads/writes. We should add checks for transcoder existence where appropriate. v2: Move one transcoder check that wound up in the wrong function after conflict resolution. It belongs in bdw_get_trans_port_sync_config rather than bxt_get_dsi_transcoder_state. v3: Switch loops to use for_each_cpu_transcoder_masked() since this iterator already checks the platform's transcoder mask for us. (Ville) Cc: Aditya Swarup <aditya.swarup@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200603211529.3005059-10-matthew.d.roper@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
c48a798a |
|
01-Jun-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Trim the ironlake+ irq handler Ever noticed that our interrupt handlers are where we spend most of our time on a busy system? In part this is unavoidable as each interrupt requires to poll and reset several registers, but we can try and do so as efficiently as possible. Function old new delta ilk_irq_handler 2317 2156 -161 v2: Restore the irqreturn_t ret Function old new delta ilk_irq_handler.cold 63 72 +9 ilk_irq_handler 2221 2080 -141 A slight improvement in the baseline overnight as well! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601140355.20243-1-chris@chris-wilson.co.uk
|
#
af157b76 |
|
29-Apr-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stop using mode->private_flags Replace the use of mode->private_flags with a truly private bitmaks in our own crtc state. We also need a copy in the crtc itself so the vblank code can get at it. We already have scanline_offset in there for a similar reason, as well as the vblank->hwmode which is assigned via drm_calc_timestamping_constants(). Fortunately we now have a nice place for doing the crtc_state->crtc copy in intel_crtc_update_active_timings() which gets called both for modesets and init/resume readout. The one slightly iffy spot is the INHERITED flag which we want to preserve until userspace/fb_helper does the first proper commit after actually calling .detecti() on the connectors. Otherwise we don't have the full sink capabilities (audio,infoframes,etc.) when .compute_config() gets called and thus we will fail to enable those features when the first userspace commit happens. The only internal commit we do prior to that should be from intel_initial_commit() and there we can simply preserve the INHERITED flag from the readout. v2: Deal with INHERITED in sanitize_watermarks() as well CC: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Emil Velikov <emil.l.velikov@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429103904.11727-1-ville.syrjala@linux.intel.com
|
#
2992b543 |
|
21-May-2020 |
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> |
drm/i915/ehl: Extend w/a 14010685332 to JSP/MCC This is a permanent w/a for JSL/EHL.This is to be applied to the PCH types on JSL/EHL ie JSP/MCC Bspec: 52888 v2: Fixed the wrong usage of logical OR(ville) v3: Removed extra braces, changed the check(jose) Signed-off-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200521064448.29522-1-swathi.dhanavanthri@intel.com
|
#
99e2d8bc |
|
04-May-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/rkl: Limit number of universal planes to 5 RKL only has five universal planes, plus a cursor. Since the bottom-most universal plane is considered the primary plane, set the number of sprites available on this platform to 4. In general, the plane capabilities of the remaining planes stay the same as TGL. However the NV12 Y-plane support moves down to the new top two planes and now only the bottom three planes can be used for NV12 UV. Bspec: 49181 Bspec: 49251 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504225227.464666-8-matthew.d.roper@intel.com
|
#
0398993b |
|
07-May-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stash hpd status bits under dev_priv Instead of constnantly having to figure out which hpd status bit array to use let's store them under dev_priv. Should perhaps take this further and stash even more stuff to make the hpd handling more abstract yet. v2: Remeber cnp (Imre) Add MISSING_CASE() for unknown PCHs (Imre) Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200507114808.6150-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
4457a9db |
|
04-May-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/tgl+: Fix interrupt handling for DP AUX transactions Unmask/enable AUX interrupts on all ports on TGL+. So far the interrupts worked only on port A, which meant each transaction on other ports took 10ms. Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504075828.20348-1-imre.deak@intel.com (cherry picked from commit 054318c7e35f1d7d06b216143fff5f32405047ee) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
9b2383a7 |
|
01-May-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/icp: Add Wa_14010685332 We need to toggle a SDE chicken bit on and then off as the final step when disabling interrupts in preparation for runtime suspend. Bspec: 33450 Bspec: 8402 Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200501213701.371443-1-matthew.d.roper@intel.com Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
|
#
054318c7 |
|
04-May-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/tgl+: Fix interrupt handling for DP AUX transactions Unmask/enable AUX interrupts on all ports on TGL+. So far the interrupts worked only on port A, which meant each transaction on other ports took 10ms. Cc: <stable@vger.kernel.org> # v5.4+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504075828.20348-1-imre.deak@intel.com
|
#
8598eb78 |
|
24-Apr-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Use proper fault mask in interrupt postinstall too The IRQ postinstall handling had open-coded pipe fault mask selection that never got updated for gen11. Switch it to use gen8_de_pipe_fault_mask() to ensure we don't miss updates for new platforms. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: d506a65d56fd ("drm/i915: Catch GTT fault errors for gen11+ planes") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200424231423.4065231-1-matthew.d.roper@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 869129ee0c624a78c74e50b51635e183196cd2c6) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
869129ee |
|
24-Apr-2020 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Use proper fault mask in interrupt postinstall too The IRQ postinstall handling had open-coded pipe fault mask selection that never got updated for gen11. Switch it to use gen8_de_pipe_fault_mask() to ensure we don't miss updates for new platforms. Cc: José Roberto de Souza <jose.souza@intel.com> Fixes: d506a65d56fd ("drm/i915: Catch GTT fault errors for gen11+ planes") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200424231423.4065231-1-matthew.d.roper@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
73c8bfb7 |
|
25-Mar-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Drop final few uses of drm_i915_private.engine We've migrated all the heavy users over to the intel_gt, and can finally drop the last few users and with that the mirror in dev_priv->engine[]. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200325234803.6175-1-chris@chris-wilson.co.uk
|
#
00535527 |
|
27-Feb-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/crc: move pipe_crc from drm_i915_private to intel_crtc Having an array pipe_crc[I915_MAX_PIPES] in struct drm_i915_private should be an obvious clue this should be located in struct intel_crtc instead. Make it so. As a side-effect, fix some errors in indexing pipe_crc with both pipe and crtc index. And, of course, reduce the size of i915_drv.h. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> 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/20200227161253.15741-1-jani.nikula@intel.com
|
#
83d2bdb6 |
|
25-Feb-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: significantly reduce the use of <drm/i915_drm.h> The #include has been splattered all over the place, but there are precious few places, all .c files, that actually need it. v2: remove leftover double newlines 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/20200225133131.3301-1-jani.nikula@intel.com
|
#
aca9310a |
|
24-Feb-2020 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915: Remove (pipe == crtc->index) assumption we can't have (pipe == crtc->index) assumption in driver in order to support 3 non-contiguous display pipe system. FIXME: Remove the WARN_ON(drm_crtc_index(&crtc->base) != crtc->pipe) when we will fix all such assumption. changes since RFC: - Added again removed (pipe == crtc->index) WARN_ON. - Pass drm_crtc_index instead of intel pipe in order to call drm_handle_vblank(). v2: - Used drm_crtc_handle_vblank()/drm_crtc_wait_one_vblank() instead of drm_handle_vblank/drm_wait_one_vblank(). [Jani] - Introduced intel_handle_vblank() helper to avoid sprinkle of intel_crtc across irq_handlers. [Ville] v3: - Moved intel_handle_vblank() from header to i915_irq.c. [Ville] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-3-anshuman.gupta@intel.com
|
#
b8b65ccd |
|
24-Feb-2020 |
Anshuman Gupta <anshuman.gupta@intel.com> |
drm/i915: Iterate over pipes and skip the disabled one It should not be assumed that a disabled display pipe will be always last the pipe. for_each_pipe() should iterate over I915_MAX_PIPES and check for the disabled pipe and skip that pipe so that it should not initialize the intel crtc for any disabled pipes. Due to changes in for_each_pipe() macro, it requires to handle the below compilation error. "suggest explicit braces to avoid ambiguous ‘else’ [-Werror=dangling-else]" v2: - Cosmetic changes, removed unwanted parentheses. [Ville] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-2-anshuman.gupta@intel.com
|
#
48e678076 |
|
23-Jan-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm: Remove legacy version of get_scanout_position() The legacy version of get_scanout_position() was only useful while drivers still used drm_driver.get_scanout_position(). With no such drivers left, the related typedef and code can be removed Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-23-tzimmermann@suse.de
|
#
4bbffbf3 |
|
23-Jan-2020 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Convert to CRTC VBLANK callbacks VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert i915 over. The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). i915 doesn't use CRTC helpers. Instead pass i915's implementation of get_scanout_position() to DRM core's drm_crtc_vblank_helper_get_vblank_timestamp_internal(). v3: * rename dcrtc to _crtc * use intel_ prefix for i915_crtc_get_vblank_timestamp() * update for drm_crtc_vblank_helper_get_vblank_timestamp_internal() v2: * use DRM's implementation of get_vblank_timestamp() * simplify function names Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-8-tzimmermann@suse.de
|
#
7203d49c |
|
21-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Sprinkle missing commas Add the missing comma after the last initialized element of the hpd[] arrays. Best not give people bad ideas. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200121171100.4370-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
00376ccf |
|
30-Jan-2020 |
Wambui Karuga <wambui.karugax@gmail.com> |
drm/i915: conversion to drm_device logging macros when drm_i915_private is present. Converts various instances of the printk drm logging macros to the struct drm_device based logging macros in the drm/i915 folder using the following coccinelle script that transforms based on the existence of the struct drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were fixed manually. Instances of the DRM_DEBUG macro were not converted due to lack of a consensus of an analogous struct drm_device based macro. References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200131093416.28431-2-wambui.karugax@gmail.com
|
#
6cc32f15 |
|
27-Jan-2020 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Reorganise gen8+ interrupt handler We always use a deferred bottom-half (either tasklet or irq_work) for processing the response to an interrupt which means we can recombine the GT irq ack+handler into one. This simplicity is important in later patches as we will need to handle and then ack multiple interrupt levels before acking the GT and master interrupts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200127231540.3302516-2-chris@chris-wilson.co.uk
|
#
8cbda6b2 |
|
23-Jan-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: use intel de functions for forcewake register access Move away from I915_READ_FW() and I915_WRITE_FW() in display code, and switch to using intel_de_read_fw() and intel_de_write_fw(), respectively. No functional changes. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> 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/20200123140004.14136-3-jani.nikula@intel.com
|
#
a9f236d1 |
|
14-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915: Make WARN* drm specific where uncore or stream ptr is available drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where intel_uncore/i915_perf_stream struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @@ identifier func, T; @@ func(...) { ... struct intel_uncore *T = ...; <... ( -WARN( +drm_WARN(&T->i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->i915->drm, ...) ) ...> } @@ identifier func, T; @@ func(struct intel_uncore *T,...) { <... ( -WARN( +drm_WARN(&T->i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->i915->drm, ...) ) ...> } @@ identifier func, T; @@ func(struct i915_perf_stream *T,...) { +struct drm_i915_private *i915 = T->perf->i915; <+... ( -WARN( +drm_WARN(&i915->drm, ...) | -WARN_ON( +drm_WARN_ON(&i915->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&i915->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&i915->drm, ...) ) ...+> } command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file <script> \ --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-11-pankaj.laxminarayan.bharadiya@intel.com
|
#
48a1b8d4 |
|
14-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915: Make WARN* drm specific where drm_priv ptr is available drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } command: ls drivers/gpu/drm/i915/*.c | xargs spatch --sp-file \ <script> --linux-spacing --in-place Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-10-pankaj.laxminarayan.bharadiya@intel.com
|
#
74bb98ba |
|
24-Dec-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: prefer 3-letter acronym for ivybridge We are currently using a mix of platform name and acronym to name the functions. Let's prefer the acronym as it should be clear what platform it's about and it's shorter, so it doesn't go over 80 columns in a few cases. This converts ivybridge to ivb where appropriate. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191224084012.24241-9-lucas.demarchi@intel.com
|
#
9eae5e27 |
|
24-Dec-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: prefer 3-letter acronym for ironlake We are currently using a mix of platform name and acronym to name the functions. Let's prefer the acronym as it should be clear what platform it's about and it's shorter, so it doesn't go over 80 columns in a few cases. This converts ironlake to ilk where appropriate. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191224084012.24241-7-lucas.demarchi@intel.com
|
#
54400257 |
|
17-Dec-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Remove direct invocation of breadcrumb signaling 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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191217095642.3124521-7-chris@chris-wilson.co.uk
|
#
a3265d85 |
|
02-Dec-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/irq: Refactor gen11 display interrupt handling Let's move handling and reset for gen11 display IRQs to their own functions, similar to how we deal with GT interrupts. This will make the top-level functions a bit easier to read and potentially make things easier to deal with in the future if new platforms wind up needing different display handling logic. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191202171608.3361125-1-matthew.d.roper@intel.com Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
|
#
f49108d0 |
|
27-Nov-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Program SHPD_FILTER_CNT on CNP+ The bspec tells us 'Program SHPD_FILTER_CNT with the "500 microseconds adjusted" value before enabling hotplug detection' on CNP+. We haven't been touching this register at all thus far, but we should probably follow the bspec's guidance. The register also exists on LPT and SPT, but there isn't any specific guidance I can find on how we should be programming it there so let's leave it be for now. Bspec: 4342 Bspec: 31297 Bspec: 8407 Bspec: 49305 Bspec: 50473 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191127221314.575575-3-matthew.d.roper@intel.com
|
#
7e7129dc |
|
21-Nov-2019 |
Clint Taylor <clinton.a.taylor@intel.com> |
drm/i915: Disable display interrupts during display IRQ handler During the Display Interrupt Service routine the Display Interrupt Enable bit must be disabled, The interrupts handled, then the Display Interrupt Enable bit must be set to prevent possible missed interrupts. Bspec: 49212 V2: Change Title to remove SDE reference. V3: Fix TAB spacing. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Aditya Swarup <aditya.swarup@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191121201455.2558-1-clinton.a.taylor@intel.com
|
#
e5df52dc |
|
24-Oct-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/tgl: Handle AUX interrupts for TC ports We're currently only processing AUX interrupts on the combo ports; make sure we handle the TC ports as well. v2: Drop stale comment Fixes: f663769a5eef ("drm/i915/tgl: initialize TC and TBT ports") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191024173023.22113-1-matthew.d.roper@intel.com
|
#
9fb94522 |
|
24-Oct-2019 |
Andi Shyti <andi.shyti@intel.com> |
drm/i915: Extract the GuC interrupt handlers Pull the GuC interrupt handlers out of i915_irq.c. They now use the GT interrupt facilities rather than the central dispatch. Based on a patch by Chris Wilson. Signed-off-by: Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191024211642.7688-2-chris@chris-wilson.co.uk
|
#
3e7abf81 |
|
24-Oct-2019 |
Andi Shyti <andi@etezian.org> |
drm/i915: Extract GT render power state management i915_irq.c is large. One reason for this is that has a large chunk of the GT render power management stashed away in it. Extract that logic out of i915_irq.c and intel_pm.c and put it under one roof. Based on a patch by Chris Wilson. Signed-off-by: Andi Shyti <andi.shyti@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191024211642.7688-1-chris@chris-wilson.co.uk
|
#
7be8782a |
|
24-Oct-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: split gen11_irq_handler to make it shareable Split gen11_irq_handler() to receive as parameter the function pointers. This allows to share the interrupt handler even if the enable/disable functions are different. Make sure it's always inlined to avoid the extra indirect call on the hot path. Checking with gcc 9 this produce the exact same code as of now: $ size drivers/gpu/drm/i915/i915_irq*.o text data bss dec hex filename 47511 560 0 48071 bbc7 drivers/gpu/drm/i915/i915_irq.o 47511 560 0 48071 bbc7 drivers/gpu/drm/i915/i915_irq_new.o $ gdb -batch -ex 'file drivers/gpu/drm/i915/i915_irq.o' -ex 'disassemble gen11_irq_handler' > /tmp/old.s $ gdb -batch -ex 'file drivers/gpu/drm/i915/i915_irq_new.o' -ex 'disassemble gen11_irq_handler' > /tmp/new.s $ git diff --no-index /tmp/{old,new}.s $ So, no change in behavior, just a simple refactor. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191024195122.22877-4-lucas.demarchi@intel.com
|
#
d506a65d |
|
08-Oct-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Catch GTT fault errors for gen11+ planes Gen11+ has more hardware planes than gen9 so we need to test additional pipe interrupt register bits to recognize any GTT faults that happen on these extra planes. Bspec: 50335 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008211716.8391-1-matthew.d.roper@intel.com
|
#
789fa874 |
|
17-Oct-2019 |
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> |
drm/i915: Restore full symmetry in i915_driver_modeset_probe/remove Commit 2d6f6f359fd8 ("drm/i915: add i915_driver_modeset_remove()") claimed removal of asymmetry in probe() and remove() calls, however, it didn't take care of calling intel_irq_uninstall() on driver remove. That doesn't hurt as long as we still call it from intel_modeset_driver_remove() but in order to have full symmetry we should call it again from i915_driver_modeset_remove(). Note that it's safe to call intel_irq_uninstall() twice thanks to commit b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs"). We may only want to mention the case we are adding in a related FIXME comment provided by that commit. While being at it, update the name of function mentioned as calling it out of sequence as that name has been changed meanwhile by commit 78dae1ac35dd ("drm/i915: Propagate "_remove" function name suffix down"). Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/6250061.7lZMOAyebC@jkrzyszt-desk.ger.corp.intel.com
|
#
e83c4673 |
|
16-Oct-2019 |
Vivek Kasireddy <vivek.kasireddy@intel.com> |
drm/i915: Correct the PCH type in irq postinstall JasperLake PCH (JSP) has DDI HPD pin mappings similar to TGP and not MCC. Also add the correct HPD pin mappings for the MCC PCH. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016183514.11128-1-vivek.kasireddy@intel.com
|
#
943682e3 |
|
15-Oct-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Introduce Jasper Lake PCH The Jasper Lake PCH follows ICP/TGP's south display behavior and is identical to MCC graphics-wise except that it does not use the unusual (port C -> TC1) pin mapping that MCC does. Also, it turns out the extra PCH ID that we had previously thought was a form of MCC is actually a second ID for JSP (i.e., port C uses the port C pins instead of the TC1 pins). v2: - Also update the port masks (not just the pin table) in mcc_hpd_irq_setup. (Vivek) v3: - Break jsp_hpd_irq_setup out into its own function for clarity. (Vivek) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015162854.30546-1-matthew.d.roper@intel.com
|
#
fcb9bba4 |
|
15-Oct-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/ehl: Don't forget to set TC long detect function Since EHL's MCC PCH reuses one of the TC pins we need to supply a TC long detect function when handling the interrupts. Fixes: 53448aed7b80 ("drm/i915/ehl: Port C's hotplug interrupt is associated with TC1 bits") Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191015161131.21239-1-matthew.d.roper@intel.com Reviewed-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
|
#
53448aed |
|
10-Oct-2019 |
Vivek Kasireddy <vivek.kasireddy@intel.com> |
drm/i915/ehl: Port C's hotplug interrupt is associated with TC1 bits On platforms that have the MCC PCH, Port C's hotplug interrupt bits are mapped to TC1 bits. Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191011002618.3087-1-vivek.kasireddy@intel.com
|
#
cd6a8513 |
|
07-Oct-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Prefer local path to runtime powermanagement Avoid going to the base i915 device when we already have a path from gt to the runtime powermanagement interface. The benefit is that it looks a bit more self-consistent to always be acquiring the gt->uncore->rpm for use with the gt->uncore. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191007154531.1750-1-chris@chris-wilson.co.uk
|
#
7d423af9 |
|
03-Oct-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Implement a better i945gm vblank irq vs. C-states workaround The current "disable C3+" workaround for the delayed vblank irqs on i945gm no longer works. I'm not sure what changed, but now I need to also disable C2. I also got my hands on a i915gm machine that suffers from the same issue. After some furious poking of registers I managed to find a better workaround: The "Do not Turn off Core Render Clock in C states" bit. With that I no longer have to disable any C-states, and as a nice bonus the power cost is only ~1/4 of the "disable C3+" method (which mind you doesn't even work anymore, and so would have an even higher power cost if we made it work by also disabling C2). So let's throw out all the cpuidle/qos crap and just toggle the magic bit as needed. And we extend the workaround to cover i915gm as well. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191003140231.24408-1-ville.syrjala@linux.intel.com Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
d09ad3e7 |
|
18-Sep-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Unify ICP and MCC hotplug pin tables The MCC hpd table is just a subset of the ICP table; we can eliminate it and use the ICP table everywhere. The extra pins in the table won't be a problem for MCC since we still supply an appropriate hotplug trigger mask anywhere the pin table is used. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190918235626.3750-2-matthew.d.roper@intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
8241cfbe |
|
04-Sep-2019 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/tgl: Access the right register when handling PSR interruptions For older gens PSR IIR and IMR have fixed addresses. From TGL onwards those registers moved to each transcoder offset. The bits for the registers are defined without an offset per transcoder as right now we have one register per transcoder. So add a fake "trans_shift" when calculating the bits offsets: it will be 0 for gen12+ and psr.transcoder otherwise. v2 (Lucas): change the implementation to use trans_shift instead of getting each bit value with a different macro Cc: Imre Deak <imre.deak@intel.com> 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> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190904213419.27547-3-jose.souza@intel.com
|
#
40e98130 |
|
29-Aug-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: unify icp, tgp and mcc irq setup Use a single function to setup the SDE irq and make MCC, ICP and TGP use it, just like was done for the irq handler. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-4-jose.souza@intel.com Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
|
#
b32821c0 |
|
29-Aug-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: parameterize SDE hotplug registers Ice Lake, Tiger Lake and Elkhart Lake all have different port configurations and all of them can be parameterized the same way to form the SDE hotplug bitmask. Avoid making them a special case an just use the parameterized macros. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-3-jose.souza@intel.com Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
|
#
58676af6 |
|
29-Aug-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: unify icp, tgp and mcc irq handling The differences are only on the pins, trigger and long_detect function. The MCC handling is already partially merged, so merge TGP as well. Remove the pins argument from icp_irq_handler() so we have all the differences between the 3 set in a common if ladder. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-2-jose.souza@intel.com Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
|
#
ed3126fa |
|
29-Aug-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: parameterize south hpd macros South, follow the north. Instead of defining separate macros for each port, make them take port as parameter as done for TC ports and for north engine. This will allow us to easily extend this as needed. tgp_ddi_port_hotplug_long_detect() is also removed as after the EHL introduction the tgp variant is an exact copy of icp. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829211526.30525-1-jose.souza@intel.com Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
|
#
d048a268 |
|
21-Aug-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use enum pipe consistently Replace all "int pipe"s with "enum pipe pipe"s to make it clear what we're dealing with. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821173033.24123-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
e8edae54 |
|
21-Aug-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Unconfuse pipe vs. crtc->index in i915_get_crtc_scanoutpos() The "pipe" argument passed in by the vblank code is in fact the crtc index. Don't assume that is the same as the pipe. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821173033.24123-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
df7415bf |
|
20-Aug-2019 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915: Do not unmask PSR interruption in IRQ postinstall No need to unmask PSR interrutpion if PSR is not enabled, better move the call to intel_psr_enable_source(). v2: Renamed intel_psr_irq_control() to psr_irq_control() (Lucas) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190820223325.27490-3-jose.souza@intel.com
|
#
46c63d24 |
|
30-Jul-2019 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/bdw+: Move misc display IRQ handling to it own function Just moving it to reduce the tabs and avoid break code lines. No behavior changes intended here. v2: - Reading misc display IRQ outside of gen8_de_misc_irq_handler() as other irq handlers (Dhinakaran) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: 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> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730224753.14907-1-jose.souza@intel.com
|
#
cf1c97dc |
|
11-Aug-2019 |
Andi Shyti <andi.shyti@intel.com> |
drm/i915: Extract general GT interrupt handlers i915_irq.c is large. It serves as the central dispatch and handler for all of our device interrupts. Lets break it up by pulling out the GT interrupt handlers. Based on a patch by Chris Wilson. Signed-off-by: Andi Shyti <andi.shyti@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/20190811210633.18417-1-chris@chris-wilson.co.uk
|
#
d762043f |
|
11-Aug-2019 |
Andi Shyti <andi.shyti@intel.com> |
drm/i915: Extract GT powermanagement interrupt handling i915_irq.c is large. It serves as the central dispatch and handler for all of our device interrupts. Pull out the GT pm interrupt handling (leaving the central dispatch) so that we can encapsulate the logic a little better. Based on a patch by Chris Wilson. Signed-off-by: Andi Shyti <andi.shyti@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/20190811142801.2460-1-chris@chris-wilson.co.uk
|
#
1d455f8d |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: rename intel_drv.h to display/intel_display_types.h Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the include guard name in the renamed file 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/20190806113933.11799-1-jani.nikula@intel.com
|
#
d64575ee |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: un-inline functions to avoid i915_drv.h include Avoid including the i915_drv.h mega header from other header files to make further header cleanup easier. 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/45431103f6cbd4322808907154336fdc176ff20d.1565085691.git.jani.nikula@intel.com
|
#
750e76b4 |
|
06-Aug-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/gt: Move the [class][inst] lookup for engines onto the GT To maintain a fast lookup from a GT centric irq handler, we want the engine lookup tables on the intel_gt. To avoid having multiple copies of the same multi-dimension lookup table, move the generic user engine lookup into an rbtree (for fast and flexible indexing). v2: Split uabi_instance cf uabi_class v3: Set uabi_class/uabi_instance after collating all engines to provide a stable uabi across parallel unordered construction. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20190806124300.24945-2-chris@chris-wilson.co.uk
|
#
8ef7e340 |
|
30-Jul-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/ehl: Don't forget to handle port C's hotplug interrupts We're mostly re-using ICL's interrupt handling on EHL, but we still need to remember to account for the extra combo port that EHL has. Use TGP's mask (which includes combo port C) rather than ICP's mask when appropriate. Let's also skip reading TC-specific registers on this platform since EHL doesn't have any TC ports. v2: Base setup of SHOTPLUG_CTL_TC on whether the tc pin mask is non-zero rather than performing another PCH type check. (Jose) Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Vivek Kasireddy <vivek.kasireddy@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730220553.15300-1-matthew.d.roper@intel.com
|
#
55523360 |
|
25-Jul-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/tgl: handle DP aux interrupts For Tiger Lake the DE Port Interrupt Definition bits changed, so use the new bit definitions. Cc: Jose Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-7-lucas.demarchi@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-4-lucas.demarchi@intel.com
|
#
48ef15d3 |
|
25-Jul-2019 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/tgl: Update north display hotplug detection to TGL connections TGL has 3 combophys and 6 TC/TBT ports, so it has 2 more TC/TBT ports than ICL and the PORT_C on TGL is a combophy. So here adding a new hpd north table and function to detect long pulse for TGL. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190713010940.17711-6-lucas.demarchi@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-3-lucas.demarchi@intel.com
|
#
52dfdba0 |
|
25-Jul-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/tgl: Add hpd interrupt handling Add hotdplug detection for all ports on TGP. icp_hpd_detection_setup() is refactored to be shared with TGP. While we increase the number of pins, add a BUILD_BUG_ON() to avoid going over the number of bits allowed. v2: use BITS_PER_TYPE and correct type for BUILD_BUG_ON() check (requested by Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jose Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190725234813.27179-2-lucas.demarchi@intel.com
|
#
702668e6 |
|
24-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/uc: Unify uC platform check We have several HAS_* checks for GuC and HuC but we mostly use HAS_GUC and HAS_HUC, with only 1 exception. Since our HW always has either both uC or neither of them, just replace all the checks with a unified HAS_UC. v2: use HAS_GT_UC (Michal) v3: fix comment (Michal) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190725001813.4740-2-daniele.ceraolospurio@intel.com
|
#
5270130d |
|
26-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add gen8_de_pipe_fault_mask() Reduce the clutter a bit by introducing gen8_de_pipe_fault_mask(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190626180344.26314-2-ville.syrjala@linux.intel.com
|
#
2239e6df |
|
13-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/guc: prefer intel_gt in guc interrupt functions We can get rid of a few more guc_to_i915 and start compartmentalizing interrupt management a bit more. We should be able to move more code in the future once the gt_pm code is also moved across to gt. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-10-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
8b5689d7 |
|
13-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/uc: move GuC/HuC inside intel_gt under a new intel_uc Being part of the GT HW, it make sense to keep the guc/huc structures inside the GT structure. To help with the encapsulation work done by the following patches, both structures are placed inside a new intel_uc container. Although this results in code with ugly nested dereferences (i915->gt.uc.guc...), it saves us the extra work required in moving the structures twice (i915 -> gt -> uc). The following patches will reduce the number of places where we try to access the guc/huc structures directly from i915 and reduce the ugliness. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-7-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
633023a4 |
|
13-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/guc: unify guc irq handling The 16-bit guc irq vector is unchanged across gens, the only thing that moved is its position (from the upper 16 bits of the PM regs to its own register). Instead of duplicating all defines and functions to handle the 2 different positions, we can work on the vector and shift it as appropriate. While at it, update the handler to work on intel_guc. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-5-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
9cbd51c2 |
|
13-Jul-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/guc: move guc irq functions to intel_guc parameter No functional change, just moving the guc_to_i915 from the caller into the irq function. This will help with the upcoming move of guc under intel_gt. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190713100016.8026-4-chris@chris-wilson.co.uk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
58820574 |
|
04-Jul-2019 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Move dev_priv->pm_i{m, e}r into intel_gt PM interrupts belong to the GT so move the variables to be inside struct intel_gt. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-3-tvrtko.ursulin@linux.intel.com
|
#
f0818984 |
|
04-Jul-2019 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove some legacy mmio accessors from interrupt handling Mostly in gen11 interrupt handling and a couple neighbouring functions which were easy since uncore local was already available. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-2-tvrtko.ursulin@linux.intel.com
|
#
9b77011e |
|
04-Jul-2019 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Rework some interrupt handling functions to take intel_gt Some interrupt handling functions already have gt in their names suggesting them as obvious candidates to make them take struct intel_gt instead of i915. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Co-developed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190704121756.27824-1-tvrtko.ursulin@linux.intel.com
|
#
315ca4c4 |
|
02-Jul-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: synchronize_irq() against the actual irq When eliminating our use of drm_irq_install() I failed to convert all our synchronize_irq() calls to consult pdev->irq instead of dev_priv->drm.irq. As we no longer populate dev_priv->drm.irq we're no longer synchronizing against anything. v2: Add intel_syncrhonize_irq() (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Imre Deak <imre.deak@intel.com> Fixes: b318b82455bd ("drm/i915: Nuke drm_driver irq vfuncs") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111012 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190702151723.29739-1-ville.syrjala@linux.intel.com
|
#
7218524d |
|
26-Jun-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Make i945gm_vblank_work_func static drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol 'i945gm_vblank_work_func' was not declared. Should it be static? CC [M] drivers/gpu/drm/i915/i915_irq.o drivers/gpu/drm/i915/i915_irq.c:3382:6: error: no previous prototype for ‘i945gm_vblank_work_func’ [-Werror=missing-prototypes] void i945gm_vblank_work_func(struct work_struct *work) Jani wrote the idential patch, so for posterity: The static keyword was apparently accidentally removed in commit 08fa8fd0faa5 ("drm/i915: Switch to per-crtc vblank vfuncs"), leading to sparse warning: drivers/gpu/drm/i915/i915_irq.c:3382:6: warning: symbol 'i945gm_vblank_work_func' was not declared. Should it be static? Make the function static again. Meanwhile, the 0-day kbuilder also spotted the mistake. Fixes: 08fa8fd0faa5 ("drm/i915: Switch to per-crtc vblank vfuncs") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626224212.10141-1-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/20190627091914.30795-1-jani.nikula@intel.com
|
#
7d23e593 |
|
19-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Initialize drm_driver vblank funcs at compile time Move the .get_vblank_timestamp() and .get_scanout_position() initialization to happen at compile time. No point in delaying it since we always assign the same functions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-5-ville.syrjala@linux.intel.com
|
#
b318b824 |
|
20-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Nuke drm_driver irq vfuncs Stop using the irq vfuncs under drm_driver. That's not going to fly in a mixed gen environment since the structure is shared between all the devices. v2: Allow intel_irq_uninstall() to be called twice due to intel_modeset_cleanup() calling it as well. Toss in a FIXME to remind us that this is not great. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620103334.15651-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
08fa8fd0 |
|
19-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Switch to per-crtc vblank vfuncs Switch from the driver-wide vblank vfuncs to the per-crtc ones so that we don't have so many platform specific vfuncs in the driver struct. We still need to do something about the rest fo the irq vfuncs... v2: s/INTEL_GEN>=3/IS_GEN3/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619170842.20579-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c6f7acb8 |
|
14-Jun-2019 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/ehl: Introduce Mule Creek Canyon PCH Although EHL introduces a new PCH, the South Display part of the PCH that we care about is nearly identical to ICP, just with some pins remapped. Most notably, Port C is mapped to the pins that ICP uses for TC Port 1. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190615004210.16656-1-matthew.d.roper@intel.com
|
#
df0566a6 |
|
13-Jun-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move modesetting core code under display/ Now that we have a new subdirectory for display code, continue by moving modesetting core code. display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this is, again, a surprisingly clean operation. v2: - don't move intel_sideband.[ch] (Ville) - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-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/20190613084416.6794-3-jani.nikula@intel.com
|
#
9102650f |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: make enable/disable rpm assert function use the rpm structure With this all the rpm assert-related functions consistently work on the i915_runtime_pm structure Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-4-daniele.ceraolospurio@intel.com
|
#
87b391b9 |
|
13-Jun-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: Remove rpm asserts that use i915 Quite a few of the call points have already switched to the version working directly on the runtime_pm structure, so let's switch over the rest and kill the i915-based asserts. v2: rebase Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190613232156.34940-3-daniele.ceraolospurio@intel.com
|
#
4f5fd91f |
|
11-Jun-2019 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove I915_READ16 and I915_WRITE16 Remove call sites in favour of uncore mmio accessors and remove the old macros. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190611104548.30545-6-tvrtko.ursulin@linux.intel.com
|
#
e33a4be8 |
|
11-Jun-2019 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove I915_POSTING_READ_FW Only a few call sites remain which have been converted to uncore mmio accessors and so the macro can be removed. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190611104548.30545-2-tvrtko.ursulin@linux.intel.com
|
#
d13616db |
|
06-Jun-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move pm related declarations to intel_pm.h Move more missed declarations from i915_drv.h to intel_pm.h. 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/20190606122203.13416-1-jani.nikula@intel.com
|
#
54c52a84 |
|
27-May-2019 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/guc: Correctly handle GuC interrupts on Gen11 Starting Gen11 GuC shares interrupt registers with SG unit instead of PM. But for now we don't care about SG interrupts. v2: (Chris) v3: rebased (Michal) v4: more bspec pages, use macros, update commit msg (Michal Wi) Bspec: 19820, 19840, 19841, 20176 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190527183613.17076-13-michal.wajdeczko@intel.com
|
#
1e83e7a6 |
|
27-May-2019 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/guc: Create vfuncs for the GuC interrupts control functions Controlling and handling of the GuC interrupts is Gen specific. Create virtual functions to avoid redundant runtime Gen checks. Gen-specific versions of these functions will follow. v2: move vfuncs to struct guc (Daniele) v3: rebased Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190527183613.17076-12-michal.wajdeczko@intel.com
|
#
a2649b34 |
|
02-May-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_lpe_audio.h from i915_drv.h It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. 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/9101a58b9f10bcf11332175e17b6e6e45f4ebd17.1556809195.git.jani.nikula@intel.com
|
#
dbeb38d9 |
|
29-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_hotplug.h from intel_drv.h and i915_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: fix sparse warnings on undeclared global functions 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/20190429125011.10876-1-jani.nikula@intel.com
|
#
440e2b3d |
|
29-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract i915_irq.h from intel_drv.h and i915_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. 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/64e46278dc8dccc9c548ef453cb2ceece5367bb2.1556540890.git.jani.nikula@intel.com
|
#
8834e365 |
|
29-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_fifo_underrun.h from intel_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. 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/0507c5523d1f07a48e6679a04db75246ce8ba766.1556540889.git.jani.nikula@intel.com
|
#
ebb5eb7d |
|
26-Apr-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace pcu_lock with sb_lock We now have two locks for sideband access. The general one covering sideband access across all generation, sb_lock, and a specific one covering sideband access via the punit on vlv/chv. After lifting the sb_lock around the punit into the callers, the pcu_lock is now redudant and can be separated from its other use to regulate RPS (essentially giving RPS a lock all of its own). v2: Extract a couple of minor bug fixes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-4-chris@chris-wilson.co.uk
|
#
b16b2a2f |
|
10-Apr-2019 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fully convert the IRQ initialization macros to intel_uncore Make them take the uncore argument from the caller instead of passing the implicit &dev_priv->uncore directly. This will allow us to finally pass something that's not dev_priv->uncore in the future, and gets rid of the implicit variables in register macros. v2: Rebase on top of the newer patches. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-6-paulo.r.zanoni@intel.com
|
#
65f42cdc |
|
10-Apr-2019 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: convert the IRQ initialization functions to intel_uncore The IRQ initialization helpers are simple and self-contained. Continue the transition started in the recent uncore rework to get us rid of I915_READ/WRITE and the implicit dev_priv variables. While the implicit dev_priv is removed from the IRQ initialization helpers, we didn't get rid of them in the macro callers. Doing that should be very simple now. v2: Rebase on top of the new patches. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-5-paulo.r.zanoni@intel.com
|
#
9d9523d8 |
|
10-Apr-2019 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers This discussion started because we use token pasting in the GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an empty argument to those macros, making the code a little weird. The original proposal was to just add a comment as the empty argument, but Ville suggested we just add a prefix to the registers, and that indeed sounds like a more elegant solution. Now doing this is kinda against our rules for register naming since we only add gens or platform names as register prefixes when the given gen/platform changes a register that already existed before. On the other hand, we have so many instances of IIR/IMR in comments that adding a prefix would make the users of these register more easily findable, in addition to make our token pasting macros actually readable. So IMHO opening an exception here is worth it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-4-paulo.r.zanoni@intel.com
|
#
2918c3ca |
|
10-Apr-2019 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't specify the IRQ register in the gen2 macros Like the gen3+ macros, the gen2 versions of the IRQ initialization macros take the register name in the 'type' argument. But gen2 only has one set of registers, so there's really no need to specify the type. This commit removes the type argument and uses the registers directly instead of passing them through variables. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-3-paulo.r.zanoni@intel.com
|
#
68eb49b1 |
|
10-Apr-2019 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: refactor the IRQ init/reset macros The whole point of having macros here is for the token pasting necessary to automatically have IMR, IIR and IER selected. We don't really need or want all the inlining that happens as a consequence. The good thing about the current code is that it works regardless of the relative offsets between these registers (they change after gen4, with the usual VLV/CHV exceptions). One thing which we can do is to split the logic of what we do with imr/ier/iir to functions separate from the macros that pick them. That's what we do in this commit. This allows us to get rid of the gen8 duplicates and also all the inlining: add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565) Function old new delta gen3_irq_reset - 233 +233 gen3_irq_init - 151 +151 i8xx_irq_postinstall 459 442 -17 gen11_irq_postinstall 804 744 -60 ironlake_irq_postinstall 450 353 -97 vlv_display_irq_postinstall 348 245 -103 i965_irq_postinstall 378 272 -106 i915_irq_postinstall 333 227 -106 gen8_irq_power_well_post_enable 374 240 -134 ironlake_irq_reset 397 218 -179 vlv_display_irq_reset 616 433 -183 i965_irq_reset 374 180 -194 cherryview_irq_reset 379 185 -194 i915_irq_reset 407 209 -198 ibx_irq_reset 332 133 -199 gen5_gt_irq_postinstall 533 332 -201 gen8_irq_power_well_pre_disable 434 204 -230 gen8_gt_irq_postinstall 469 196 -273 gen8_de_irq_postinstall 1200 836 -364 gen5_gt_irq_reset 471 76 -395 gen8_gt_irq_reset 775 99 -676 gen8_irq_reset 1100 333 -767 gen11_irq_reset 1959 686 -1273 Total: Before=2259222, After=2253657, chg -0.25% v2: - Make checkpatch happy with a temporary which_ (Checkpatch). - Reorder the arguments for the INIT macros (Ville). - Correctly explain when the register offsets change in the commit message (Ville). - Use more line breaks in the macro calls to make the arguments look a little more organized/readable. - Update the bloat-o-meter output (minor change only). Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-2-paulo.r.zanoni@intel.com
|
#
917dc6b5 |
|
10-Apr-2019 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Use Engine1 instance for gen11 pm interrupts With gen11 the interrupt registers are shared between 2 engines, with Engine1 instance being upper word and Engine0 instance being lower. Annoyingly gen11 selected the pm interrupts to be in the Engine1 instance. Rectify the situation by shifting the access accordingly, based on gen. v2: comments, warn on overzealous rps_events Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=108059 Testcase: igt/i915_pm_rps@min-max-config-loaded Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-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/20190410105923.18546-6-mika.kuoppala@linux.intel.com
|
#
8455dad7 |
|
10-Apr-2019 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: Don't warn on spurious interrupts There is a chance we can see spurious interrupts in live now. We have more engines enabled and that with more elaborate access patterns with pm and display, increases the chances hardware just makes a social call, without anything to work on. Remove the error as we have tests to actually probe if we really miss interrupt, instead of getting spurious ones. Note that now we do write to intr_dw even with a zero value. This is considered advantegous as the write is an ack that sw is done. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190410132124.21795-2-mika.kuoppala@linux.intel.com
|
#
a087bafe |
|
10-Apr-2019 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: Handle rps interrupts without irq lock Unlike previous gens, we already hold the irq_lock on entering the rps handler so we can't use it as it is. Make a gen11 specific rps interrupt handler without locking. v2: return early (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.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/20190410132124.21795-1-mika.kuoppala@linux.intel.com
|
#
55367a27 |
|
05-Apr-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: extract intel_psr.h from intel_drv.h It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: Fix checkpatch whitespace complaint Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7e776690bf139ccdd0306b30df08dc68e74603de.1554461791.git.jani.nikula@intel.com
|
#
4c6ce5c9 |
|
29-Mar-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move the decision to use the breadcrumb tasklet to the backend Use the engine->flags to store whether we want to kick the submission tasklet on receipt of a breadcrumb interrupt, so that this decision can be made by the submission backend and not dependent on a limited feature test within the interrupt handler. This should make it easier to adapt to different submission backends. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Xiaolin Zhang <xiaolin.zhang@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190329154912.13781-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
0df3f09d |
|
22-Mar-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use vblank_disable_immediate on gen2 The vblank timestamp->counter guesstimator seems to be working sufficiently well, so there's no reason not to disable vblank interrupts ASAP even on gen2. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322180804.3300-2-ville.syrjala@linux.intel.com Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
d938da6b |
|
22-Mar-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Disable C3 when enabling vblank interrupts on i945gm The AGPBUSY thing doesn't work on i945gm anymore. This means the gmch is incapable of waking the CPU from C3 when an interrupt is generated. The interrupts just get postponed indefinitely until something wakes up the CPU. This is rather annoying for vblank interrupts as we are unable to maintain a steady framerate unless the machine is sufficiently loaded to stay out of C3. To combat this let's use pm_qos to prevent C3 whenever vblank interrupts are enabled. To maintain reasonable amount of powersaving we will attempt to limit this to C3 only while leaving C1 and C2 enabled. v2: Use READ_ONCE() (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30364 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322180804.3300-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
25286aac |
|
19-Mar-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: move regs pointer inside the uncore structure This will allow futher simplifications in the uncore handling. v2: move register access setup under uncore (Chris) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190319183543.13679-8-daniele.ceraolospurio@intel.com
|
#
f3e30485 |
|
18-Mar-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce i915_has_asle() We want to allow the desktop PNV to not have .is_mobile set. To that end let's add a small helper to determine if the platform has the ASLE interrupt (or equivalent). Supposdely both PNV variants have it. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190318165633.28924-4-ville.syrjala@linux.intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
29b43ae2 |
|
13-Mar-2019 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Also use new comparative stuff for more ICP+ stuff I just noticed that initial PCH comparative patch left some >= PCH_ICP cases behind. Let's also cover these cases and leave only the pin map behind now. No functional change. Hence no fixes tag. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190313214307.26573-1-rodrigo.vivi@intel.com
|
#
c6c30b91 |
|
08-Mar-2019 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Start using comparative INTEL_PCH_TYPE In order to make it easier to bring up new platforms without having to take care about all corner cases that was previously taken care for previous platforms we already use comparative INTEL_GEN statements. Let's start doing the same with PCH. The only caveats are: - less-than comparisons need to be avoided or done with attention and check > PCH_NONE as well. - It is not necessarily a chronological order, but a matter of south display compatibility/inheritance. v2: Rebased on top of Jani's clean-up which removed the need for less-than comparison Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190308214300.25057-3-rodrigo.vivi@intel.com
|
#
8a68d464 |
|
05-Mar-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Store the BIT(engine->id) as the engine's mask In the next patch, we are introducing a broad virtual engine to encompass multiple physical engines, losing the 1:1 nature of BIT(engine->id). To reflect the broader set of engines implied by the virtual instance, lets store the full bitmask. v2: Use intel_engine_mask_t (s/ring_mask/engine_mask/) v3: Tvrtko voted for moah churn so teach everyone to not mention ring and use $class$instance throughout. v4: Comment upon the disparity in bspec for using VCS1,VCS2 in gen8 and VCS[0-4] in later gen. We opt to keep the code consistent and use 0-index naming throughout. Signed-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/20190305180332.30900-1-chris@chris-wilson.co.uk
|
#
f14c0d9f |
|
05-Mar-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Just check the vebox IIR regardless As we don't unmask and enable the vebox interrupts if the engine is not being used, we will never generate the vebox interrupts as part of the IIR and so can unconditionally check IIR without fear of chasing into the vebox. Signed-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/20190305150914.11340-1-chris@chris-wilson.co.uk
|
#
9d17210f |
|
25-Feb-2019 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: extract AUX mask assignment to separate function No change in behavior, this only allows to more easily follow the flow of gen8_de_irq_handler without the mask assignments for each platform. This also re-organizes the branches a little bit, so the one-off case for CNL_WITH_PORT_F is separate from the generic gen >= 11. v2: rename de_port_iir_aux_mask -> gen8_de_port_aux_mask (Ville) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jose Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190226004900.26047-1-lucas.demarchi@intel.com
|
#
2a8862d2 |
|
18-Feb-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reduce the RPS shock Limit deboosting and boosting to keep ourselves at the extremes when in the respective power modes (i.e. slowly decrease frequencies while in the HIGH_POWER zone and slowly increase frequencies while in the LOW_POWER zone). On idle, we will hit the timeout and drop to the next level quickly, and conversely if busy we expect to hit a waitboost and rapidly switch into max power. This should improve the UX experience by keeping the GPU clocks higher than they ostensibly should be (based on simple busyness) by switching into the INTERACTIVE mode (due to waiting for pageflips) and increasing clocks via waitboosting. This will incur some additional power, our saving grace should be rc6 and powergating to keep the extra current draw in check. Food for future thought would be deadline scheduling? If we know certain contexts (high priority compositors) absolutely must hit the next vblank then we can raise the frequencies ahead of time. Part of this is covered by per-context frequencies, where userspace is given control over the frequency range they want the GPU to execute at (for largely the same problem as this, where the workload is very latency sensitive but at the EI level appears mostly idle). Indeed, the per-context series does extend the modeset boosting to include a frequency range tweak which seems applicable to solving this jittery UX behaviour. Reported-by: Lyude Paul <lyude@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109408 References: 0d55babc8392 ("drm/i915: Drop stray clearing of rps->last_adj") References: 60548c554be2 ("drm/i915: Interactive RPS mode") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lyude Paul <lyude@redhat.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Quoting Lyude Paul: > Before reverting 0d55babc8392754352f1058866dd4182ae587d11: [4.20] > > 35 measurements [of gnome-shell animations] > Average: 33.65657142857143 FPS > FPS observed: 20.8 - 46.87 FPS > Percentage under 60 FPS: 100.0% > Percentage under 55 FPS: 100.0% > Percentage under 50 FPS: 100.0% > Percentage under 45 FPS: 97.14285714285714% > Percentage under 40 FPS: 97.14285714285714% > Percentage under 35 FPS: 45.714285714285715% > Percentage under 30 FPS: 11.428571428571429% > Percentage under 25 FPS: 2.857142857142857% > > After reverting: [4.19 behaviour] > > 30 measurements > Average: 49.833666666666666 FPS > FPS observed: 33.85 - 60.0 FPS > Percentage under 60 FPS: 86.66666666666667% > Percentage under 55 FPS: 70.0% > Percentage under 50 FPS: 53.333333333333336% > Percentage under 45 FPS: 20.0% > Percentage under 40 FPS: 6.666666666666667% > Percentage under 35 FPS: 6.666666666666667% > Percentage under 30 FPS: 0% > Percentage under 25 FPS: 0% > > Patched: > 42 measurements > Average: 46.05428571428571 FPS > FPS observed: 1.82 - 59.98 FPS > Percentage under 60 FPS: 88.09523809523809% > Percentage under 55 FPS: 61.904761904761905% > Percentage under 50 FPS: 45.23809523809524% > Percentage under 45 FPS: 35.714285714285715% > Percentage under 40 FPS: 33.33333333333333% > Percentage under 35 FPS: 19.047619047619047% > Percentage under 30 FPS: 7.142857142857142% > Percentage under 25 FPS: 4.761904761904762% Tested-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-13-chris@chris-wilson.co.uk
|
#
5cee6c45 |
|
06-Feb-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add pipe crc tracepoint Add a tracepoint for pipe crc. Makes life much simpler when staring at traces when hunting for fifo underruns and other issues which cause corrupted frames. We'll add the tracepoint before filtering out any potentially bogus crcs during modeset (should actually verify if that filtering is even correct anymore...) v2: s/crcs[5]/*crcs/ in the function argument because something in the macros wants to do sizeof(crcs) and gcc likes to warn us it's not an actual array so the size may not be as expected. The silly bugger even does that for 'crcs[]' causing us to lose any helpful syntactic hint that we are in fact dealing with an array (kbuild test robot) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190206204910.13965-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
52c0fdb2 |
|
29-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace global breadcrumbs with per-context interrupt tracking A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request herd"), the issue of handling multiple clients waiting in parallel was brought to our attention. The requirement was that every client should be woken immediately upon its request being signaled, without incurring any cpu overhead. To handle certain fragility of our hw meant that we could not do a simple check inside the irq handler (some generations required almost unbounded delays before we could be sure of seqno coherency) and so request completion checking required delegation. Before commit 688e6c725816, the solution was simple. Every client waiting on a request would be woken on every interrupt and each would do a heavyweight check to see if their request was complete. Commit 688e6c725816 introduced an rbtree so that only the earliest waiter on the global timeline would woken, and would wake the next and so on. (Along with various complications to handle requests being reordered along the global timeline, and also a requirement for kthread to provide a delegate for fence signaling that had no process context.) The global rbtree depends on knowing the execution timeline (and global seqno). Without knowing that order, we must instead check all contexts queued to the HW to see which may have advanced. We trim that list by only checking queued contexts that are being waited on, but still we keep a list of all active contexts and their active signalers that we inspect from inside the irq handler. By moving the waiters onto the fence signal list, we can combine the client wakeup with the dma_fence signaling (a dramatic reduction in complexity, but does require the HW being coherent, the seqno must be visible from the cpu before the interrupt is raised - we keep a timer backup just in case). Having previously fixed all the issues with irq-seqno serialisation (by inserting delays onto the GPU after each request instead of random delays on the CPU after each interrupt), we can rely on the seqno state to perfom direct wakeups from the interrupt handler. This allows us to preserve our single context switch behaviour of the current routine, with the only downside that we lose the RT priority sorting of wakeups. In general, direct wakeup latency of multiple clients is about the same (about 10% better in most cases) with a reduction in total CPU time spent in the waiter (about 20-50% depending on gen). Average herd behaviour is improved, but at the cost of not delegating wakeups on task_prio. v2: Capture fence signaling state for error state and add comments to warm even the most cold of hearts. v3: Check if the request is still active before busywaiting v4: Reduce the amount of pointer misdirection with list_for_each_safe and using a local i915_request variable inside the loops v5: Add a missing pluralisation to a purely informative selftest message. References: 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request herd") Signed-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/20190129205230.19056-2-chris@chris-wilson.co.uk
|
#
3df0bd19 |
|
29-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove the intel_engine_notify tracepoint The global seqno is defunct and so we have no meaningful indicator of forward progress for an engine. You need to listen to the request signaling tracepoints instead. 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/20190129205230.19056-1-chris@chris-wilson.co.uk
|
#
8a920e24 |
|
25-Jan-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/tv: Use the scanline counter for timestamps on i965gm TV output Just like the frame counter, the pixel counter also reads zero all the time when the TV encoder is used. Fortunately the scanline counter still works sufficiently well so let's use that to correct the vblank timestamps. Otherwise the timestamps may en up out of whack, and since we use them to guesstimate the vblank counter value that may end up incorrect as well. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190125181931.19482-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
32db0b65 |
|
27-Nov-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't try to use the hardware frame counter with i965gm TV output On i965gm the hardware frame counter does not work when the TV encoder is active. So let's not try to consult the hardware frame counter in that case. Instead we'll fall back to the timestamp based guesstimation method used on gen2. Note that the pipe timings generated by the TV encoder are also rather peculiar. Apparently the pipe wants to run at a much higher speed (related to the oversample clock somehow it seems) but during the vertical active period the TV encoder stalls the pipe every few lines to keep its speed in check. But once the vertical blanking period is reached the pipe gets to run at full speed. This means our vblank timestamp estimates are suspect. Fixing all that would require quite a bit more work. This simple fix at least avoids the nasty vblank timeouts that are happening currently. Curiously the frame counter works just fine on i945gm and gm45. I don't really understand what kind of mishap occurred with the hardware design on i965gm. Sadly I wasn't able to find any chicken bits etc. that would fix the frame counter :( v2: Move the zero vs. non-zero hw counter value handling into i915_get_vblank_counter() (Daniel) Use the per-crtc maximum exclusively, leaving the per-device maximum at zero v3: max_vblank_count not populated yet in intel_enable_pipe() use intel_crtc_max_vblank_count() instead Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel@ffwll.ch> Fixes: 51e31d49c890 ("drm/i915: Use generic vblank wait") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190122125149.GE5527@ideak-desk.fi.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
fcd70cd3 |
|
17-Jan-2019 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Split out drm_probe_helper.h Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically v5: Actually try to sort them, and while at it, sort all the ones I touch. v6: Rebase onto i915 changes. v7: Rebase once more. Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: CK Hu <ck.hu@mediatek.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etnaviv@lists.freedesktop.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-tegra@vger.kernel.org Cc: xen-devel@lists.xen.org Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
|
#
c25f0c6a |
|
22-Jan-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/icl: do a posting read after irq install When reading GEN11_GT_INTR_DWx closely after enabling the interrupts in gen11_irq_postinstall, the returned value is garbage. This can cause other parts of the setup code (e.g. gen11_reset_one_iir) to think that there are interrupts to be cleared when there are none. The garbage value is only seen on the first read done after the enable, so this looks like a posting issue. Adding a posting read after enabling the interrupts does indeed fix the problem. Note that the posting read has been purposely added outside of gen11_master_intr_enable since the issue has only been observed when the full interrupt setup is performed. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190123023227.8117-1-daniele.ceraolospurio@intel.com
|
#
0e21834e |
|
21-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Tidy common test_bit probing of i915_request->fence.flags A repeated pattern is to test the signaled bit of our request->fence.flags. Make this an inline to shorten a few lines and remove unnecessary line continuations. 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/20190121222117.23305-20-chris@chris-wilson.co.uk
|
#
a9c287c9 |
|
16-Jan-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: switch to kernel types Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/841f4eac1c52f4ed3efe2ac9e343d6640c03b774.1547629303.git.jani.nikula@intel.com
|
#
9f58892e |
|
16-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Pull all the reset functionality together into i915_reset.c Currently the code to reset the GPU and our state is spread widely across a few files. Pull the logic together into a common file. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190116153304.787-1-chris@chris-wilson.co.uk
|
#
183e260b |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Track the rpm wakerefs for error handling Keep hold of the local wakeref used in error handling, to cancel the tracking upon release so that leaks can be identified. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-4-chris@chris-wilson.co.uk
|
#
16e4dd03 |
|
14-Jan-2019 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Markup paired operations on wakerefs The majority of runtime-pm operations are bounded and scoped within a function; these are easy to verify that the wakeref are handled correctly. We can employ the compiler to help us, and reduce the number of wakerefs tracked when debugging, by passing around cookies provided by the various rpm_get functions to their rpm_put counterpart. This makes the pairing explicit, and given the required wakeref cookie the compiler can verify that we pass an initialised value to the rpm_put (quite handy for double checking error paths). For regular builds, the compiler should be able to eliminate the unused local variables and the program growth should be minimal. Fwiw, it came out as a net improvement as gcc was able to refactor rpm_get and rpm_get_if_in_use together, v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual mark up for smaller more targeted patches. v3: Mention the cookie in Returns Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@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/20190114142129.24398-2-chris@chris-wilson.co.uk
|
#
d78a600f |
|
09-Jan-2019 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915: drop DPF code for gen8+ The only gen8+ platform that has the feature is BDW, but we don't define the feature flag on any BDW platform and we only have partial support in the gen8 path (irq enabling code, but no handler). The only thing we could do in the irq handler is report the error to userspace, but no one asked/cared about that since BDW was released so it is relatively safe to assume that even if we added the message no one would look at it. Just drop the dead code from the driver instead. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20190109213147.16851-1-daniele.ceraolospurio@intel.com
|
#
2f80d7bd |
|
08-Jan-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: drop all drmP.h includes Needs just a few additional includes here and there. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com
|
#
1216e3c3 |
|
28-Dec-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Drop unused engine->irq_seqno_barrier w/a Now that we have eliminated the CPU-side irq_seqno_barrier by moving the delays on the GPU before emitting the MI_USER_INTERRUPT, we can remove the engine->irq_seqno_barrier infrastructure. Though intentionally slowing down the GPU is nasty, so is the code we can now remove! 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/20181228171641.16531-6-chris@chris-wilson.co.uk
|
#
060f2322 |
|
18-Dec-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Apply missed interrupt after reset w/a to all ringbuffer gen Having completed a test run of gem_eio across all machines in CI we also observe the phenomenon (of lost interrupts after resetting the GPU) on gen3 machines as well as the previously sighted gen6/gen7. Let's apply the same HWSTAM workaround that was effective for gen6+ for all, as although we haven't seen the same failure on gen4/5 it seems prudent to keep the code the same. As a consequence we can remove the extra setting of HWSTAM and apply the register from a single site. v2: Delazy and move the HWSTAM into its own function v3: Mask off all HWSP writes on driver unload and engine cleanup. v4: And what about the physical hwsp? v5: No, engine->init_hw() is not called from driver_init_hw(), don't be daft. Really scrub HWSTAM as early as we can in driver_init_mmio() v6: Rename set_hwsp as it was setting the mask not the hwsp register. v7: Ville pointed out that although vcs(bsd) was introduced for g4x/ilk, per-engine HWSTAM was not introduced until gen6! References: https://bugs.freedesktop.org/show_bug.cgi?id=108735 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181218102712.11058-1-chris@chris-wilson.co.uk
|
#
cf819eff |
|
12-Dec-2018 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: replace IS_GEN<N> with IS_GEN(..., N) Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
|
#
62819dfd |
|
06-Nov-2018 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/icl: Reset PSR interruptions All other interruptions gen11 interruptions are reset in gen11_irq_reset() also it is done for other gens that supports PSR. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181106190843.18009-3-jose.souza@intel.com
|
#
9a64c650 |
|
06-Nov-2018 |
Lyude Paul <lyude@redhat.com> |
drm/i915: Add short HPD IRQ storm detection for non-MST systems 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
|
#
81067b71 |
|
15-Oct-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: Disable master intr before reading Disable master interrupt before reading level indications. This will close a race where we get a level indication between reading and disabling, generating an extra interrupt where we could have avoided one. Further, as the reading acts also as a post, replace the write/post on the irq reset with the helper. On enabling side, posting doesn't serve any purpose so it can also be replaced with helper. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181015141440.21845-3-mika.kuoppala@linux.intel.com
|
#
95b0e7c1 |
|
15-Oct-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: No need to ack intr through master control All other master control register bits, except the enable, are read only and they are level indications of the second level interrupt status. Only touch enable bit and rectify the comment. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181015141440.21845-2-mika.kuoppala@linux.intel.com
|
#
4376b9c9 |
|
15-Oct-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/gen8: Disable master intr before reading Disable master interrupt before reading level indications. This will close a race where we get a level indication between reading and disabling, generating an extra interrupt where we could have avoided one. Further, as the reading acts also as a post, replace the write/post on the irq reset with the helper. On enabling side, posting doesn't serve any purpose so it can also be replaced with helper. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181015141440.21845-1-mika.kuoppala@linux.intel.com
|
#
4ca8ca9f |
|
26-Sep-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid compiler warning for maybe unused gu_misc_iir /kisskb/src/drivers/gpu/drm/i915/i915_irq.c: warning: 'gu_misc_iir' may be used uninitialized in this function [-Wuninitialized]: => 3120:10 Silence the compiler warning by ensuring that the local variable is initialised and removing the guard that is confusing the older gcc. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: df0d28c185ad ("drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926104718.17462-1-chris@chris-wilson.co.uk (cherry picked from commit 7a90938332d80faf973fbcffdf6e674e7b8f0914) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
7a909383 |
|
26-Sep-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid compiler warning for maybe unused gu_misc_iir /kisskb/src/drivers/gpu/drm/i915/i915_irq.c: warning: 'gu_misc_iir' may be used uninitialized in this function [-Wuninitialized]: => 3120:10 Silence the compiler warning by ensuring that the local variable is initialised and removing the guard that is confusing the older gcc. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: df0d28c185ad ("drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926104718.17462-1-chris@chris-wilson.co.uk
|
#
2bfbf6fe |
|
03-Sep-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Do a full device reset after being wedged We only call unset_wedged on the global reset path (since it's a global operation), so if we are terminally wedged and wish to reset, take the full device reset path rather than the quicker individual engine resets. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-1-chris@chris-wilson.co.uk
|
#
09605548 |
|
30-Aug-2018 |
Lionel Landwerlin <lionel.g.landwerlin@intel.com> |
drm/i915: clear error registers after error capture We need to clear the register in order to get correct value after the next potential hang. v2: Centralize error register clearing in i915_irq.c (Chris) v3: Don't read gen8 register on < gen6 (Chris) v4: Don't swap gen8+ & gen6+ code... (Chris) Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180830132424.21940-1-lionel.g.landwerlin@intel.com
|
#
1aeb1b5f |
|
21-Aug-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/psr: Mask PSR irq bits when re-enabling interrupts. 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 c44301fce614 ("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: c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180821221156.2442-3-dhinakaran.pandiyan@intel.com
|
#
c44301fc |
|
09-Aug-2018 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Allow control of PSR at runtime through debugfs, v6 Currently tests modify i915.enable_psr and then do a modeset cycle to change PSR. We can write a value to i915_edp_psr_debug to force a certain PSR mode without a modeset. To retain compatibility with older userspace, we also still allow the override through the module parameter, and add some tracking to check whether a debugfs mode is specified. Changes since v1: - Rename dev_priv->psr.enabled to .dp, and .hw_configured to .enabled. - Fix i915_psr_debugfs_mode to match the writes to debugfs. - Rename __i915_edp_psr_write to intel_psr_set_debugfs_mode, simplify it and move it to intel_psr.c. This keeps all internals in intel_psr.c - Perform an interruptible wait for hw completion outside of the psr lock, instead of being forced to trywait and return -EBUSY. Changes since v2: - Rebase on top of intel_psr changes. Changes since v3: - Assign psr.dp during init. (dhnkrn) - Add prepared bool, which should be used instead of relying on psr.dp. (dhnkrn) - Fix -EDEADLK handling in debugfs. (dhnkrn) - Clean up waiting for idle in intel_psr_set_debugfs_mode. - Print PSR mode when trying to enable PSR. (dhnkrn) - Move changing psr debug setting to i915_edp_psr_debug_set. (dhnkrn) Changes since v4: - Return error in _set() function. - Change flag values to make them easier to remember. (dhnkrn) - Only assign psr.dp once. (dhnkrn) - Only set crtc_state->has_psr on the crtc with psr.dp. - Fix typo. (dhnkrn) Changes since v5: - Only wait for PSR idle on the PSR connector correctly. (dhnkrn) - Reinstate WARN_ON(drrs.dp) in intel_psr_enable. (dhnkrn) - Remove stray comment. (dhnkrn) - Be silent in intel_psr_compute_config on wrong connector. (dhnkrn) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180809142101.26155-1-maarten.lankhorst@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
|
#
027063b1 |
|
31-Jul-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Interactive RPS mode 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>
|
#
4668f695 |
|
02-Aug-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Clear all residual RPS events on disabling interrupts Make sure that the RPS IIR is completely clear on disabling so we should not get any more interrupts after idling. Since the IIR is shared with the guc, we have to be careful to only clobber RPS events. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-3-chris@chris-wilson.co.uk
|
#
f4de7794 |
|
02-Aug-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Unconditionally clear the pm/guc GT IIR upon acking Having stored the IIR for action, we should always clear it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180802100631.31305-2-chris@chris-wilson.co.uk
|
#
60548c55 |
|
31-Jul-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Interactive RPS mode 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
|
#
60a94324 |
|
13-Jul-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/execlists: Drop clear_gtiir() on GPU reset With the new CSB processing code, we are not vulnerable to delayed delivery of a pre-reset interrupt as we use the CSB status pointers in the HWSP to decide if we need to parse any CSB events and no longer need to wait for the first post-reset interrupt to be assured that the CSB mmio registers are valid. The new icl code to clear registers has a nasty lock inversion: [ 57.409776] ====================================================== [ 57.409779] WARNING: possible circular locking dependency detected [ 57.409783] 4.18.0-rc4-CI-CI_DII_1137+ #1 Tainted: G U W [ 57.409785] ------------------------------------------------------ [ 57.409788] swapper/6/0 is trying to acquire lock: [ 57.409790] 000000004f304ee5 (&engine->timeline.lock/1){-.-.}, at: execlists_submit_request+0x2b/0x1a0 [i915] [ 57.409841] but task is already holding lock: [ 57.409844] 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915] [ 57.409869] which lock already depends on the new lock. [ 57.409872] the existing dependency chain (in reverse order) is: [ 57.409876] -> #2 (&(&rq->lock)->rlock#2){-.-.}: [ 57.409900] notify_ring+0x2b2/0x480 [i915] [ 57.409922] gen8_cs_irq_handler+0x39/0xa0 [i915] [ 57.409943] gen11_irq_handler+0x2f0/0x420 [i915] [ 57.409949] __handle_irq_event_percpu+0x42/0x370 [ 57.409952] handle_irq_event_percpu+0x2b/0x70 [ 57.409956] handle_irq_event+0x2f/0x50 [ 57.409959] handle_edge_irq+0xe7/0x190 [ 57.409964] handle_irq+0x67/0x160 [ 57.409967] do_IRQ+0x5e/0x120 [ 57.409971] ret_from_intr+0x0/0x1d [ 57.409974] _raw_spin_unlock_irqrestore+0x4e/0x60 [ 57.409979] tasklet_action_common.isra.5+0x47/0xb0 [ 57.409982] __do_softirq+0xd9/0x505 [ 57.409985] irq_exit+0xa9/0xc0 [ 57.409988] do_IRQ+0x9a/0x120 [ 57.409991] ret_from_intr+0x0/0x1d [ 57.409995] cpuidle_enter_state+0xac/0x360 [ 57.409999] do_idle+0x1f3/0x250 [ 57.410004] cpu_startup_entry+0x6a/0x70 [ 57.410010] start_secondary+0x19d/0x1f0 [ 57.410015] secondary_startup_64+0xa5/0xb0 [ 57.410018] -> #1 (&(&dev_priv->irq_lock)->rlock){-.-.}: [ 57.410081] clear_gtiir+0x30/0x200 [i915] [ 57.410116] execlists_reset+0x6e/0x2b0 [i915] [ 57.410140] i915_reset_engine+0x111/0x190 [i915] [ 57.410165] i915_handle_error+0x11a/0x4a0 [i915] [ 57.410198] i915_hangcheck_elapsed+0x378/0x530 [i915] [ 57.410204] process_one_work+0x248/0x6c0 [ 57.410207] worker_thread+0x37/0x380 [ 57.410211] kthread+0x119/0x130 [ 57.410215] ret_from_fork+0x3a/0x50 [ 57.410217] -> #0 (&engine->timeline.lock/1){-.-.}: [ 57.410224] _raw_spin_lock_irqsave+0x33/0x50 [ 57.410256] execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410289] submit_notify+0x8d/0x124 [i915] [ 57.410314] __i915_sw_fence_complete+0x81/0x250 [i915] [ 57.410339] dma_i915_sw_fence_wake+0xd/0x20 [i915] [ 57.410344] dma_fence_signal_locked+0x79/0x200 [ 57.410368] notify_ring+0x2ba/0x480 [i915] [ 57.410392] gen8_cs_irq_handler+0x39/0xa0 [i915] [ 57.410416] gen11_irq_handler+0x2f0/0x420 [i915] [ 57.410421] __handle_irq_event_percpu+0x42/0x370 [ 57.410425] handle_irq_event_percpu+0x2b/0x70 [ 57.410428] handle_irq_event+0x2f/0x50 [ 57.410432] handle_edge_irq+0xe7/0x190 [ 57.410436] handle_irq+0x67/0x160 [ 57.410439] do_IRQ+0x5e/0x120 [ 57.410445] ret_from_intr+0x0/0x1d [ 57.410449] cpuidle_enter_state+0xac/0x360 [ 57.410453] do_idle+0x1f3/0x250 [ 57.410456] cpu_startup_entry+0x6a/0x70 [ 57.410460] start_secondary+0x19d/0x1f0 [ 57.410464] secondary_startup_64+0xa5/0xb0 [ 57.410466] other info that might help us debug this: [ 57.410471] Chain exists of: &engine->timeline.lock/1 --> &(&dev_priv->irq_lock)->rlock --> &(&rq->lock)->rlock#2 [ 57.410481] Possible unsafe locking scenario: [ 57.410485] CPU0 CPU1 [ 57.410487] ---- ---- [ 57.410490] lock(&(&rq->lock)->rlock#2); [ 57.410494] lock(&(&dev_priv->irq_lock)->rlock); [ 57.410498] lock(&(&rq->lock)->rlock#2); [ 57.410503] lock(&engine->timeline.lock/1); [ 57.410506] *** DEADLOCK *** [ 57.410511] 4 locks held by swapper/6/0: [ 57.410514] #0: 0000000074575789 (&(&dev_priv->irq_lock)->rlock){-.-.}, at: gen11_irq_handler+0x8a/0x420 [i915] [ 57.410542] #1: 000000009b29b30e (rcu_read_lock){....}, at: notify_ring+0x1a/0x480 [i915] [ 57.410573] #2: 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915] [ 57.410601] #3: 000000009b29b30e (rcu_read_lock){....}, at: submit_notify+0x35/0x124 [i915] [ 57.410635] stack backtrace: [ 57.410640] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G U W 4.18.0-rc4-CI-CI_DII_1137+ #1 [ 57.410644] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.2222.A01.1805300339 05/30/2018 [ 57.410650] Call Trace: [ 57.410652] <IRQ> [ 57.410657] dump_stack+0x67/0x9b [ 57.410662] print_circular_bug.isra.16+0x1c8/0x2b0 [ 57.410666] __lock_acquire+0x1897/0x1b50 [ 57.410671] ? lock_acquire+0xa6/0x210 [ 57.410674] lock_acquire+0xa6/0x210 [ 57.410706] ? execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410711] _raw_spin_lock_irqsave+0x33/0x50 [ 57.410741] ? execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410769] execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410774] ? _raw_spin_unlock_irqrestore+0x39/0x60 [ 57.410804] submit_notify+0x8d/0x124 [i915] [ 57.410828] __i915_sw_fence_complete+0x81/0x250 [i915] [ 57.410854] dma_i915_sw_fence_wake+0xd/0x20 [i915] [ 57.410858] dma_fence_signal_locked+0x79/0x200 [ 57.410882] notify_ring+0x2ba/0x480 [i915] [ 57.410907] gen8_cs_irq_handler+0x39/0xa0 [i915] [ 57.410933] gen11_irq_handler+0x2f0/0x420 [i915] [ 57.410938] __handle_irq_event_percpu+0x42/0x370 [ 57.410943] handle_irq_event_percpu+0x2b/0x70 [ 57.410947] handle_irq_event+0x2f/0x50 [ 57.410951] handle_edge_irq+0xe7/0x190 [ 57.410955] handle_irq+0x67/0x160 [ 57.410958] do_IRQ+0x5e/0x120 [ 57.410962] common_interrupt+0xf/0xf [ 57.410965] </IRQ> [ 57.410969] RIP: 0010:cpuidle_enter_state+0xac/0x360 [ 57.410972] Code: 44 00 00 31 ff e8 84 93 91 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 85 31 02 00 00 31 ff e8 7d 30 98 ff e8 e8 0e 94 ff fb 4c 29 fb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff [ 57.411015] RSP: 0018:ffffc90000133e90 EFLAGS: 00000216 ORIG_RAX: ffffffffffffffdd [ 57.411023] RAX: ffff8804ae748040 RBX: 000000000002a97d RCX: 0000000000000000 [ 57.411029] RDX: 0000000000000046 RSI: ffffffff82141263 RDI: ffffffff820f05a7 [ 57.411035] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 57.411041] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8229f078 [ 57.411045] R13: ffff8804ab2adfa8 R14: 0000000000000000 R15: 0000000d5de092e3 [ 57.411052] do_idle+0x1f3/0x250 [ 57.411055] cpu_startup_entry+0x6a/0x70 [ 57.411059] start_secondary+0x19d/0x1f0 [ 57.411064] secondary_startup_64+0xa5/0xb0 The easiest remedy is to remove the defunct code. Fixes: ff047a87cfac ("drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11") References: fd8526e50902 ("drm/i915/execlists: Trust the CSB") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-3-chris@chris-wilson.co.uk
|
#
f88f0478 |
|
05-Jul-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Print the long_mask alongside the pin_mask We're printing out which pins got a hotplug, so why not also print out which pins detected the long pulse as opposed to a short pulse. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-9-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
af92058f |
|
05-Jul-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass hpd_pin to long_pulse_detect() We're doing a pointless translation from hpd_pin to port simply for passing the thing to long_pulse_detect(). Let's pass the hpd_pin directly instead. This removes the assumption that the hpd_pin and port always match. The only other place where we make that assumption anymore is intel_hpd_pin_default() and that's fine as it's what determines the relationship between the two. If we ever get hardware where the hpd pins are wired in more interesting ways it should be trivial to handle from now on. This should also fix the IS_CNL_WITH_PORT_F() case as that mapped pin E back to port F and passed that to spt_port_hotplug2_long_detect() which would always return false for port F. Now that we pass in pin E directly it'll actually do the right thing. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: cf53902f48c3 ("drm/i915/cnl: Add HPD support for Port F.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-7-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
e9be2850 |
|
05-Jul-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/int i/enum hpd_pin pin/ Use the enum hpd_pin type when talking about HPD pins, and rename the variable from a very nondescript 'i' to 'pin', a name we already use in other parts of the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-6-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
96a85cc5 |
|
14-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix hotplug irq ack on i965/g4x Just like with PIPESTAT, the edge triggered IIR on i965/g4x also causes problems for hotplug interrupts. To make sure we don't get the IIR port interrupt bit stuck low with the ISR bit high we must force an edge in ISR. Unfortunately we can't borrow the PIPESTAT trick and toggle the enable bits in PORT_HOTPLUG_EN as that act itself generates hotplug interrupts. Instead we just have to loop until we've cleared PORT_HOTPLUG_STAT, or we just give up and WARN. v2: Don't frob with PORT_HOTPLUG_EN Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614175625.1615-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 0ba7c51a6fd80a89236f6ceb52e63f8a7f62bfd3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
6cc42152 |
|
28-Jun-2018 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Remove support for legacy debugfs crc interface This interface is deprecated, and has been replaced by the upstream drm crc interface. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628072303.14175-1-maarten.lankhorst@linux.intel.com
|
#
16659bc5 |
|
11-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Unmask and enable master error interrupt on gen2/3 For whatever reason we only unmask and enable the master error interrut on gen4. With the EIR handling fixed let's do that on gen2/3 as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
78c357dd |
|
11-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix pre-ILK error interrupt ack Adjust the EIR clearing to cope with the edge triggered IIR on i965/g4x. To guarantee an edge in the ISR master error bit we temporarily mask everything in EMR. As some of the EIR bits can't even be directly cleared we also borrow a trick from i915_clear_error_registers() and permanently mask any bit that remains high. No real thought given to how we might unmask them again once the cause for the error has been clered. I suppose on pre-g4x GPU reset will reinitialize EMR from scratch. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
0ba7c51a |
|
14-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix hotplug irq ack on i965/g4x Just like with PIPESTAT, the edge triggered IIR on i965/g4x also causes problems for hotplug interrupts. To make sure we don't get the IIR port interrupt bit stuck low with the ISR bit high we must force an edge in ISR. Unfortunately we can't borrow the PIPESTAT trick and toggle the enable bits in PORT_HOTPLUG_EN as that act itself generates hotplug interrupts. Instead we just have to loop until we've cleared PORT_HOTPLUG_STAT, or we just give up and WARN. v2: Don't frob with PORT_HOTPLUG_EN Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614175625.1615-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
fd8526e5 |
|
28-Jun-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/execlists: Trust the CSB Now that we use the CSB stored in the CPU friendly HWSP, we do not need to track interrupts for when the mmio CSB registers are valid and can just check where we read up to last from the cached HWSP. This means we can forgo the atomic bit tracking from interrupt, and in the next patch it means we can check the CSB at any time. v2: Change the splitting inside reset_prepare, we only want to lose testing the interrupt in this patch, the next patch requires the change in locking Signed-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/20180628201211.13837-8-chris@chris-wilson.co.uk
|
#
8ea397fa |
|
28-Jun-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/execlists: Process one CSB update at a time In the next patch, we will process the CSB events directly from the submission path, rather than only after a CS interrupt. Hence, we will no longer have the need for a loop until the has-interrupt bit is clear, and in the meantime can remove that small optimisation. v2: Tvrtko pointed out it was safer to unconditionally kick the tasklet after each irq, when assuming that the tasklet is called for each irq. Signed-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/20180628201211.13837-4-chris@chris-wilson.co.uk
|
#
74093f3e |
|
28-Jun-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Drop posting reads to flush master interrupts We do not need to do a posting read of our uncached mmio write to re-enable the master interrupt lines after handling an interrupt, so don't. This saves us a slow UC read before we can process the interrupt, most noticeable in execlists where any stalls imposes extra latency on GPU command execution. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-1-chris@chris-wilson.co.uk
|
#
e3be4079 |
|
27-Jun-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only signal from interrupt when requested Avoid calling dma_fence_signal() from inside the interrupt if we haven't enabled signaling on the request. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180627201304.15817-4-chris@chris-wilson.co.uk
|
#
78796877 |
|
27-Jun-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move the irq_counter inside the spinlock Rather than have multiple locked instructions inside the notify_ring() irq handler, move them inside the spinlock and reduce their intrinsic locking. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180627201304.15817-3-chris@chris-wilson.co.uk
|
#
69dc4d00 |
|
27-Jun-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only trigger missed-seqno checking next to boundary If we have more interrupts pending (because we know there are more breadcrumb signals before the completion), then we do not need to trigger an irq_seqno_barrier or even wakeup the task on this interrupt as there will be another. To allow some margin of error (we are trying to work around incoherent seqno after all), we wakeup the breadcrumb before the target as well as on the target. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180627201304.15817-2-chris@chris-wilson.co.uk
|
#
3f88325c |
|
27-Jun-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reduce spinlock hold time during notify_ring() interrupt By taking advantage of the RCU protection of the task struct, we can find the appropriate signaler under the spinlock and then release the spinlock before waking the task and signaling the fence. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180627201304.15817-1-chris@chris-wilson.co.uk
|
#
31604222 |
|
26-Jun-2018 |
Anusha Srivatsa <anusha.srivatsa@intel.com> |
drm/i915/icp: Add Interrupt Support This patch addresses Interrupts from south display engine (SDE). ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC. Introduce these registers and their intended values. Introduce icp_irq_handler(). The icp_irq_postinstall() takes care of enabling all PCH interrupt sources, to unmask them as needed with SDEIMR, as is done done by ibx_irq_pre_postinstall() for earlier platforms. We do not need to explicitly call the ibx_irq_pre_postinstall(). Also, while changing these, s/CPT/PPT/CPT-CNP comment. v2: - remove redundant register defines.(Lucas) - Change register names to be more consistent with previous platforms (Lucas) v3: -Reorder bit defines to a more appropriate location. Change the comments. Confirm in the commit message that icp_irq_postinstall() need not go to ibx_irq_pre_postinstall() and ibx_irq_postinstall() as in earlier platforms. (Paulo) Cc: Lucas De Marchi <lucas.de.marchi@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> [Paulo: coding style bikesheds and rebases]. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530046343-30649-1-git-send-email-anusha.srivatsa@intel.com
|
#
4dc055c9 |
|
11-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix PIPESTAT irq ack on i965/g4x On i965/g4x IIR is edge triggered. So in order for IIR to notice that there is still a pending interrupt we have to force and edge in ISR. For the ISR/IIR pipe event bits we can do that by temporarily clearing all the PIPESTAT enable bits when we ack the status bits. This will force the ISR pipe event bit low, and it can then go back high when we restore the PIPESTAT enable bits. This avoids the following race: 1. stat = read(PIPESTAT) 2. an enabled PIPESTAT status bit goes high 3. write(PIPESTAT, enable|stat); 4. write(IIR, PIPE_EVENT) The end result is IIR==0 and ISR!=0. This can lead to nasty vblank wait/flip_done timeouts if another interrupt source doesn't trick us into looking at the PIPESTAT status bits despite the IIR PIPE_EVENT bit being low. Before i965 IIR was level triggered so this problem can't actually happen there. And curiously VLV/CHV went back to the level triggered scheme as well. But for simplicity we'll use the same i965/g4x compatible code for all platforms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 132c27c97cb958f637dc05adc35a61b47779bcd8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
b796b971 |
|
15-Jun-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/icl: Handle hotplug interrupts for DP over TBT This patch enables hotplug interrupts for DP over TBT output on TC ports. The TBT interrupts are enabled and handled irrespective of the actual output type which could be DP Alternate, DP over TBT, native DP or native HDMI. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-3-paulo.r.zanoni@intel.com
|
#
121e758e |
|
15-Jun-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/icl: Support for TC North Display interrupts The hotplug interrupts for the ports can be routed to either North Display or South Display depending on the output mode. DP Alternate or DP over TBT outputs will have hotplug interrupts routed to the North Display while interrupts for legacy modes will be routed to the South Display in PCH. This patch adds hotplug interrupt handling support for DP Alternate mode. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [Paulo: coding style changes] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-2-paulo.r.zanoni@intel.com
|
#
df0d28c1 |
|
15-Jun-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC The Graphics System Event(GSE) interrupt bit has a new location in the GU_MISC_INTERRUPT_{IIR, ISR, IMR, IER} registers. Since GSE was the only DE_MISC interrupt that was enabled, with this change we don't enable/handle any of DE_MISC interrupts for gen11. Credits to Paulo for pointing out the register change. v2: from DK raw_reg_[read/write], branch prediction hint and drop platform check (Mika) v3: From DK Early re-enable of master interrupt (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [Paulo: bikesheds and rebases] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-1-paulo.r.zanoni@intel.com
|
#
132c27c9 |
|
11-Jun-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix PIPESTAT irq ack on i965/g4x On i965/g4x IIR is edge triggered. So in order for IIR to notice that there is still a pending interrupt we have to force and edge in ISR. For the ISR/IIR pipe event bits we can do that by temporarily clearing all the PIPESTAT enable bits when we ack the status bits. This will force the ISR pipe event bit low, and it can then go back high when we restore the PIPESTAT enable bits. This avoids the following race: 1. stat = read(PIPESTAT) 2. an enabled PIPESTAT status bit goes high 3. write(PIPESTAT, enable|stat); 4. write(IIR, PIPE_EVENT) The end result is IIR==0 and ISR!=0. This can lead to nasty vblank wait/flip_done timeouts if another interrupt source doesn't trick us into looking at the PIPESTAT status bits despite the IIR PIPE_EVENT bit being low. Before i965 IIR was level triggered so this problem can't actually happen there. And curiously VLV/CHV went back to the level triggered scheme as well. But for simplicity we'll use the same i965/g4x compatible code for all platforms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
bb187e93 |
|
11-Jun-2018 |
James Ausmus <james.ausmus@intel.com> |
drm/i915/icl: DP_AUX_E is valid on ICL+ Add support for DP_AUX_E. Here we also introduce the bits for the AUX power well E, however ICL power well support is still not enabled yet, so the power well is not used. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180612002512.29783-2-paulo.r.zanoni@intel.com
|
#
9bb635d9 |
|
21-May-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/icl: Extend AUX F interrupts to ICL ICL has AUX F. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-2-paulo.r.zanoni@intel.com
|
#
ff047a87 |
|
24-Apr-2018 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11 Interrupt handling in Gen11 is quite different from previous platforms. v2: Rebased (Michel) v3: Rebased with wiggle v4: Rebased, remove TODO warning correctly (Daniele) v5: Rebased, made gen11_gtiir const while at it (Michel) v6: Rebased v7: Adapt to the style currently in upstream Suggested-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1524605995-22324-1-git-send-email-oscar.mateo@intel.com
|
#
54fd3149 |
|
04-Apr-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/psr: Control PSR interrupts via debugfs Interrupts other than the one for AUX errors are required only for debug, so unmask them via debugfs when the user requests debug. User can make such a request with echo 1 > <DEBUG_FS>/dri/0/i915_edp_psr_debug There are no locks to serialize PSR debug enabling from irq_postinstall() and debugfs for simplicity. As irq_postinstall() is called only during module initialization/resume and IGT subtests aren't expected to modify PSR debug at those times, we should be safe. v2: Unroll loops (Ville) Avoid resetting error mask bits. v3: Unmask interrupts in postinstall() if debug was still enabled. Avoid RMW (Ville) v4: Avoid extra IMR write introduced in the previous version.(Jose) Style changes, renames (Jose). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405013717.24254-1-dhinakaran.pandiyan@intel.com
|
#
e04f7ece |
|
03-Apr-2018 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable edp psr error interrupts on bdw+ Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on any transcoder in theory, though the we don't currenty enable PSR except on the EDP transcoder. v2: From DK * Rebased on drm-tip v3: Switched author to Ville based on IRC discussion. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-2-dhinakaran.pandiyan@intel.com
|
#
fc340442 |
|
05-Apr-2018 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Enable edp psr error interrupts on hsw The definitions for the error register should be valid on bdw/skl too, but there we haven't even enabled DE_MISC handling yet. Somewhat confusing the the moved register offset on bdw is only for the _CTL/_AUX register, and that _IIR/IMR stayed where they have been on bdw. v2: Fixes from Ville. v3: From DK * Rebased on drm-tip * Removed BDW IIR bit definition, looks like an unintentional change that should be in the following patch. v4: From DK * Don't mask REG_WRITE. References: bspec/11974 [SRD Interrupt Bit Definition DevHSW] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405220023.9449-1-dhinakaran.pandiyan@intel.com
|
#
d0667e9c |
|
06-Apr-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Pass the set of guilty engines to i915_reset() Currently, we rely on inspecting the hangcheck state from within the i915_reset() routines to determine which engines were guilty of the hang. This is problematic for cases where we want to run i915_handle_error() and call i915_reset() independently of hangcheck. Instead of relying on the indirect parameter passing, turn it into an explicit parameter providing the set of stalled engines which then are treated as guilty until proven innocent. While we are removing the implicit stalled parameter, also make the reason into an explicit parameter to i915_reset(). We still need a back-channel for i915_handle_error() to hand over the task to the locked waiter, but let's keep that its own channel rather than incriminate another. This leaves stalled/seqno as being private to hangcheck, with no more nefarious snooping by reset, be it whole-device or per-engine. \o/ The only real issue now is that this makes it crystal clear that we don't actually do any testing of hangcheck per se in drv_selftest/live_hangcheck, merely of resets! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-2-chris@chris-wilson.co.uk
|
#
96606f3b |
|
05-Apr-2018 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/icl: Deal with GT INT DW correctly BSpec says: "Second level interrupt events are stored in the GT INT DW. GT INT DW is a double buffered structure. A snapshot of events is taken when SW reads GT INT DW. From the time of read to the time of SW completely clearing GT INT DW (to indicate end of service), all incoming interrupts are logged in a secondary storage structure. this guarantees that the record of interrupts SW is servicing will not change while under service". We read GT INT DW in several places now: - The IRQ handler (banks 0 and 1) where, hopefully, it is completely cleared (operation now covered with the irq lock). - The 'reset' interrupts functions for RPS and GuC logs, where we clear the bit we are interested in and leave the others for the normal interrupt handler. - The 'enable' interrupts functions for RPS and GuC logs, as a measure of precaution. Here we could relax a bit and don't check GT INT DW at all or, if we do, at least we should clear the offending bit (which is what this patch does). Note that, if every bit is cleared on reading GT INT DW, the register won't be locked. Also note that, according to the BSpec, GT INT DW cannot be cleared without first servicing the Selector & Shared IIR registers. v2: - Remove some code duplication (Tvrtko) - Make sure GT_INTR_DW are protected by the irq spinlock, since it's a global resource (Tvrtko) v3: Optimize the spinlock (Tvrtko) v4: Rebase. v5: - take spinlock on outer scope to please sparse (Mika) - use raw_reg accessors (Mika) v6: omit the continue in looping banks (Michel) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v4) Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406093237.14548-1-mika.kuoppala@linux.intel.com
|
#
d02b98b8 |
|
05-Apr-2018 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/icl: Handle RPS interrupts correctly for Gen11 Using the new hierarchical interrupt infrastructure. v2: Rebase v3: Rebase v4: use class/instance handler (Mika) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-3-mika.kuoppala@linux.intel.com
|
#
f744dbc2 |
|
05-Apr-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: Use hw engine class, instance to find irq handler Interrupt identity register we already read from hardware contains engine class and instance fields. Leverage these fields to find correct engine to handle the interrupt. v3: rebase on top of rps intr use correct class / instance limits (Michel) v4: split engine/other handling v5: empty iir is not err (Daniele, Michel) Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406093145.14389-1-mika.kuoppala@linux.intel.com
|
#
1c645bf4 |
|
22-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use full serialisation around engine->irq_posted Using engine->irq_posted for execlists, we are not always serialised by the tasklet as we supposed. On the reset paths, the tasklet is disabled and ignored. Instead, we manipulate the engine->irq_posted directly to account for the reset, but if an interrupt fired before the reset and so wrote to engine->irq_posted, that write may not be flushed from the local CPU's cacheline until much later as the tasklet is already active and so does not generate a mb(). To correctly serialise the interrupt with reset, we need serialisation on the set_bit() itself. And at last Mika can be happy. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322073533.5313-3-chris@chris-wilson.co.uk
|
#
ce800754 |
|
20-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Add control flags to i915_handle_error() Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to i915_reset/i915_reset_engine so that we include the reason for the reset in the dev_notice(), superseding the earlier option to not print that notice. v3: Stash the reason inside the i915->gpu_error to handover to the direct reset from the blocking waiter. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-2-chris@chris-wilson.co.uk
|
#
873d66fb |
|
16-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Trim error mask to known engines For the convenience of userspace passing in an arbitrary reset mask, remove unknown engines from the set of engines that are to be reset. This means that we always follow a per-engine reset with a full-device reset when userspace writes -1 into debugfs/i915_wedged. Reported-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316215001.12391-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com>
|
#
93bf8096 |
|
08-Mar-2018 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915/guc: Move GuC notification handling to separate function To allow future code reuse. While here, fix comment style. v2: Notifications are a separate thing - rename the handler (Sagar) Suggested-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180308154707.21716-3-michal.winiarski@intel.com
|
#
51f6b0f9 |
|
08-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Push irq_shift from gen8_cs_irq_handler() to caller Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into the caller, we can shrink the code still further: add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34) Function old new delta gen8_cs_irq_handler 123 118 -5 gen8_gt_irq_handler 261 248 -13 gen11_irq_handler 722 706 -16 v2: Drop gen11_cs_irq_handler now that it is a simple stub around gen8_cs_irq_handler (Daniele) References: 5d3d69d5c119 ("drm/i915: Stop inlining the execlists IRQ handler") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180309010808.11921-1-chris@chris-wilson.co.uk
|
#
033b7a23 |
|
08-Mar-2018 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Handle pipe CRC around enabling/disabling pipe. This will get rid of the following error: [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei prime_numbers [ 74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 4.16.0-rc2-CI-CI_DRM_3822+ #1 [ 74.730355] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011 [ 74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730361] RSP: 0018:ffff88022fb03d10 EFLAGS: 00010086 [ 74.730365] RAX: ffffffffa0291d20 RBX: ffff88021a180000 RCX: 0000000000000001 [ 74.730367] RDX: ffffffff820e7db8 RSI: 0000000000000001 RDI: ffffffff82068cea [ 74.730369] RBP: ffff88022fb03d70 R08: 0000000000000000 R09: ffffffff815d26d0 [ 74.730371] R10: 0000000000000000 R11: ffffffffa0161ca0 R12: 0000000000000001 [ 74.730373] R13: ffff880212448008 R14: ffff880212448330 R15: 0000000000000000 [ 74.730376] FS: 0000000000000000(0000) GS:ffff88022fb00000(0000) knlGS:0000000000000000 [ 74.730378] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 74.730380] CR2: 000055edcbec9000 CR3: 0000000002210001 CR4: 00000000000606e0 [ 74.730382] Call Trace: [ 74.730385] <IRQ> [ 74.730397] drm_get_last_vbltimestamp+0x36/0x50 [ 74.730401] drm_update_vblank_count+0x64/0x240 [ 74.730409] drm_crtc_accurate_vblank_count+0x41/0x90 [ 74.730453] display_pipe_crc_irq_handler+0x176/0x220 [i915] [ 74.730497] i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915] [ 74.730537] ironlake_irq_handler+0x618/0xa30 [i915] [ 74.730548] __handle_irq_event_percpu+0x3c/0x340 [ 74.730556] handle_irq_event_percpu+0x1b/0x50 [ 74.730561] handle_irq_event+0x2f/0x50 [ 74.730566] handle_edge_irq+0xe4/0x1b0 [ 74.730572] handle_irq+0x11/0x20 [ 74.730576] do_IRQ+0x5e/0x120 [ 74.730584] common_interrupt+0x84/0x84 [ 74.730586] </IRQ> [ 74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350 [ 74.730593] RSP: 0018:ffffc9000008beb8 EFLAGS: 00000212 ORIG_RAX: ffffffffffffffde [ 74.730597] RAX: ffff880226b80040 RBX: 000000000031fc3e RCX: 0000000000000001 [ 74.730599] RDX: 0000000000000000 RSI: ffffffff8210fb59 RDI: ffffffff820c02e7 [ 74.730601] RBP: 0000000000000004 R08: 00000000000040af R09: 0000000000000018 [ 74.730603] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004 [ 74.730606] R13: ffffe8ffffd00430 R14: 0000001166120bf4 R15: ffffffff82294460 [ 74.730621] ? cpuidle_enter_state+0xa6/0x350 [ 74.730629] do_idle+0x188/0x1d0 [ 74.730636] cpu_startup_entry+0x14/0x20 [ 74.730641] start_secondary+0x129/0x160 [ 74.730646] secondary_startup_64+0xa5/0xb0 [ 74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41 [ 74.730754] ---[ end trace 14b1345705b68565 ]--- Changes since v1: - Don't try to apply CRC workaround when enabling pipe, it should already be enabled. Changes since v2: - Make crc functions for !DEBUGFS case inline. - Pass intel_crtc to crc functions. - Add comments to callsites. Changes since v3: - Cache selected source to pipe_crc->source. - Set pipe_crc->skipped to MIN_INT during disable to close a race condition. Changes since v4: - Handle fallout from setting pipe_crc->source in irq handler. Cc: Marta Löfstedt <marta.lofstedt@intel.com> Reported-by: Marta Löfstedt <marta.lofstedt@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180308120202.52446-1-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
4e9a8bef |
|
05-Mar-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Assert that the request is indeed complete when signaled from irq After we call dma_fence_signal(), confirm that the request was indeed complete. Signed-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/20180305104105.8296-1-chris@chris-wilson.co.uk
|
#
51951ae7 |
|
27-Feb-2018 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/icl: Interrupt handling v2: Rebase. v3: * Remove DPF, it has been removed from SKL+. * Fix -internal rebase wrt. execlists interrupt handling. v4: Rebase. v5: * Updated for POR changes. (Daniele Ceraolo Spurio) * Merged with irq handling fixes by Daniele Ceraolo Spurio: * Simplify the code by using gen8_cs_irq_handler. * Fix interrupt handling for the upstream kernel. v6: * Remove early bringup debug messages (Tvrtko) * Add NB about arbitrary spin wait timeout (Tvrtko) v7 (from Paulo): * Don't try to write RO bits to registers. * Don't check for PCH types that don't exist. PCH interrupts are not here yet. v9: * squashed in selector and shared register handling (Daniele) * skip writing of irq if data is not valid (Daniele) * use time_after32 (Chris) * use I915_MAX_VCS and I915_MAX_VECS (Daniele) * remove fake pm interrupt handling for later patch (Mika) v10: * Direct processing of banks. clear banks early (Chris) * remove poll on valid bit, only clear valid bit (Mika) * use raw accessors, better naming (Chris) v11: * adapt to raw_reg_[read|write] * bring back polling the valid bit (Daniele) v12: * continue if unset intr_dw (Daniele) * comment the usage of gen8_de_irq_handler bits (Daniele) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180228101153.7224-2-mika.kuoppala@linux.intel.com
|
#
e61e0f51 |
|
21-Feb-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename drm_i915_gem_request to i915_request We want to de-emphasize the link between the request (dependency, execution and fence tracking) from GEM and so rename the struct from drm_i915_gem_request to i915_request. That is we may implement the GEM user interface on top of requests, but they are an abstraction for tracking execution rather than an implementation detail of GEM. (Since they are not tied to HW, we keep the i915 prefix as opposed to intel.) In short, the spatch: @@ @@ - struct drm_i915_gem_request + struct i915_request A corollary to contracting the type name, we also harmonise on using 'rq' shorthand for local variables where space if of the essence and repetition makes 'request' unwieldy. For globals and struct members, 'request' is still much preferred for its clarity. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221095636.6649-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
2e4a5b25 |
|
19-Feb-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Prune gen8_gt_irq_handler The compiler is not automatically caching the i915->regs address inside a register and emitting a load for every mmio access. For simple functions like gen8_gt_irq_handler that are already using the raw accessors, we can open-code them for substantial savings: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-83 (-83) Function old new delta gen8_gt_irq_handler 290 266 -24 gen8_gt_irq_ack 181 122 -59 Total: Before=954637, After=954554, chg -0.01% v2: Add raw_reg_read/raw_reg_write. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219100926.16554-1-chris@chris-wilson.co.uk
|
#
f0fd96f5 |
|
15-Feb-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Track GT interrupt handling using the master iir Keep the master iir and use it to reduce the number of reads and writes to the GT iir array, i.e. only the bits marked as set by the master iir are valid inside GT iir array and will be handled during the interrupt. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjala <ville.syrjala@linux.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/20180215073713.26985-1-chris@chris-wilson.co.uk
|
#
2e8bf223 |
|
02-Feb-2018 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915: Estimate and update missed vblanks. The frame counter may have got reset between disabling and enabling vblank interrupts due to DMC putting the hardware to DC5/6 states if PSR was active. The frame counter could also have stalled if PSR was active in case there was no DMC. The frame counter resetting has a user visible impact of screen freezes. Make use of drm_vblank_restore() to compute missed vblanks for the duration in which vblank interrupts were disabled and update the vblank counter with this value as diff. There's no need to check if PSR was actually active in the interrupt disabled duration, so simplify the check to a feature check. Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it from going back again as long as the there are pending interrupts. So, we don't have to explicity disallow DC5/6 after enabling vblank interrupts to keep the counter running. This change is not applicable to CHV, as enabling interrupts does not prevent the hardware from activating PSR. v2: Added comments(Rodrigo) and rewrote commit message. 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: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-10-dhinakaran.pandiyan@intel.com
|
#
55ef72f2 |
|
02-Feb-2018 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove spurious DRM_ERROR for cancelled interrupts As we ourselves cancel interrupts during reset by clearing the GTIIR, it is possible for the master IIR to indicate a pending IRQ for which we have already cleared from the GTIIR. In this case, the DRM_ERROR are intended and should not be flagged as an error. 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180202153448.23908-1-chris@chris-wilson.co.uk
|
#
cf53902f |
|
29-Jan-2018 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Add HPD support for Port F. On CNP boards that are using DDI F, bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing the Digital Port F hotplug line when the Digital Port F hotplug detect input is enabled. v2: Reuse all existent structure instead of adding a new HPD_PORT_F pointing to pin of port E. v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming this right now. If that SKU ever get a proper name we come back and update it. v4: Rebase on top of digital connected port using encoder instead of port. v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-8-rodrigo.vivi@intel.com
|
#
a324fcac |
|
29-Jan-2018 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnl: Add AUX-F support On some Cannonlake SKUs we have a dedicated Aux for port F, that is only the full split between port A and port E. There is still no Aux E for Port E, as in previous platforms, because port_E still means shared lanes with port A. v2: Rebase. v3: Add couple missed PORT_F cases on intel_dp. v4: Rebase and fix commit message. v5: Squash Imre's "drm/i915: Add missing AUX_F power well string" v6: Rebase on top of display headers rework. v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK) v8: Fix Aux bits for Port F (DK) v9: Fix VBT definition of Port F (DK). v10: Squash power well addition to this patch to avoid warns as pointed by DK. v11: Clean up squashed commit message. (David) v12: Remove unnecessary handling for older platforms (DK) Adding AUX_F to PG2 following other existent ones. (DK) Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-2-rodrigo.vivi@intel.com
|
#
1be333d3 |
|
24-Jan-2018 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915/guc: Grab RPM wakelock while disabling GuC interrupts Disabling GuC interrupts involves access to GuC IRQ control registers hence ensure device is RPM awake. v1-v2: old changelog 1: Add comment about need to synchronize flush work and log runtime destroy 2: Moved patch earlier in the series and removed comment about future work. (Tvrtko) v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris) Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: 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> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1516808821-3638-1-git-send-email-sagar.a.kamble@intel.com
|
#
93ffbe8e |
|
06-Dec-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915/guc: Introduce USES_GUC_xxx helper macros In the upcoming patch we will change the way how to recognize when GuC is in use. Using helper macros will minimize scope of that changes. While here, update dev_info message. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@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/20171206135316.32556-3-michal.wajdeczko@intel.com
|
#
8bd099a7 |
|
29-Nov-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Tidy up signed/unsigned comparison drivers/gpu/drm/i915/i915_irq.c|3096 col 29| error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171130125253.21405-1-chris@chris-wilson.co.uk Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
|
#
c6dce8f1 |
|
16-Nov-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Update execlists tasklet naming intel_lrc_irq_handler and i915_guc_irq_handler are HW submission related tasklet functions. Name them with "submission_tasklet" suffix and remove intel/i915 prefix as they are static. Also rename irq_tasklet as just tasklet for clarity. v2: s/_bh/_tasklet (Chris) Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1510839162-25197-2-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
5d266692 |
|
23-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Filter out spurious execlists context-switch interrupts Back in commit a4b2b01523a8 ("drm/i915: Don't mark an execlists context-switch when idle") we noticed the presence of late context-switch interrupts. We were able to filter those out by looking at whether the ELSP remained active, but in commit beecec901790 ("drm/i915/execlists: Preemption!") that became problematic as we now anticipate receiving a context-switch event for preemption while ELSP may be empty. To restore the spurious interrupt suppression, add a counter for the expected number of pending context-switches and skip if we do not need to handle this interrupt to make forward progress. v2: Don't forget to switch on for preempt. v3: Reduce the counter to a on/off boolean tracker. Declare the HW as active when we first submit, and idle after the final completion event (with which we confirm the HW says it is idle), and track each source of activity separately. With a finite number of sources, it should aide us in debugging which gets stuck. Fixes: beecec901790 ("drm/i915/execlists: Preemption!") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171023213237.26536-3-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> (cherry picked from commit 4a118ecbe99c93cf9f9582e83a88d03f18d6cb84) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
bcbd5c33 |
|
25-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/guc: Always enable the breadcrumbs irq The execlists emulation on top of the GuC (used for scheduling and preemption) depends on the MI_USER_INTERRUPT for its notifications and tasklet action. As we always employ the irq, there is no advantage in ever disabling it while we are using the GuC, so allow us to arm the breadcrumb irq when enabling GuC submission and disarm upon disabling. The impact should be lessened by the delayed irq disabling we do (we only disable after receiving an interrupt for which no one was wanting), but allowing guc to explicitly manage the irq in relation to itself is simpler and prevents an issue with losing an interrupt for preemption as it is not coupled to an active request. Internally, we add a reference counter (breadcrumbs.irq_enabled) as a simple mechanism to allow GuC to keep the breadcrumb irq enabled. To improve upon always enabling the irq while guc is selected, we need to hook into the parking facility of intel_engines so that we only enable the breadcrumbs while the GT is active (one step better would be to individually park/unpark each engine). In effect, this means that we keep the breadcrumb irq always enabled for the entire duration the guc is busy, whereas before we would try to switch it off whenever we idled for more than interrupt with no associated waiters. The difference *should* be negligible in practice! v2: Stop abusing fence signaling (and its auxiliary data structures) to enable the breadcrumbs irqs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com>, Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>, Link: https://patchwork.freedesktop.org/patch/msgid/20171025143943.7661-3-chris@chris-wilson.co.uk
|
#
4a118ecb |
|
23-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Filter out spurious execlists context-switch interrupts Back in commit a4b2b01523a8 ("drm/i915: Don't mark an execlists context-switch when idle") we noticed the presence of late context-switch interrupts. We were able to filter those out by looking at whether the ELSP remained active, but in commit beecec901790 ("drm/i915/execlists: Preemption!") that became problematic as we now anticipate receiving a context-switch event for preemption while ELSP may be empty. To restore the spurious interrupt suppression, add a counter for the expected number of pending context-switches and skip if we do not need to handle this interrupt to make forward progress. v2: Don't forget to switch on for preempt. v3: Reduce the counter to a on/off boolean tracker. Declare the HW as active when we first submit, and idle after the final completion event (with which we confirm the HW says it is idle), and track each source of activity separately. With a finite number of sources, it should aide us in debugging which gets stuck. Fixes: beecec901790 ("drm/i915/execlists: Preemption!") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171023213237.26536-3-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
562d9bae |
|
10-Oct-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Name structure in dev_priv that contains RPS/RC6 state as "gt_pm" Prepared substructure rps for RPS related state. autoenable_work is used for RC6 too hence it is defined outside rps structure. As we do this lot many functions are refactored to use intel_rps *rps to access rps related members. Hence renamed intel_rps_client pointer variables to rps_client in various functions. v2: Rebase. v3: s/pm/gt_pm (Chris) Refactored access to rps structure by declaring struct intel_rps * in many functions. Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> #1 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-9-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-8-chris@chris-wilson.co.uk
|
#
9f817501 |
|
10-Oct-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Move rps.hw_lock to dev_priv and s/hw_lock/pcu_lock In order to separate GT PM related functionality into new structure we are updating rps structure. hw_lock in it is used for display related PCU communication too hence move it to dev_priv. Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-8-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-7-chris@chris-wilson.co.uk
|
#
ad1443f0 |
|
10-Oct-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Name i915_runtime_pm structure in dev_priv as "runtime_pm" We were using dev_priv->pm for runtime power management related state. This patch renames it to "runtime_pm" which looks more apt. v2: s/rpm/runtime_pm (Chris) Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> #1 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-7-git-send-email-sagar.a.kamble@intel.com Acked-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-6-chris@chris-wilson.co.uk
|
#
45c1cd87 |
|
10-Oct-2017 |
Mika Kahola <mika.kahola@intel.com> |
drm/i915: Cleanup South Error Interrupts Cleanup and parametrize the handling of South Error Interrupts (SERR_INT). Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1507630626-23806-6-git-send-email-mika.kahola@intel.com
|
#
0a195c02 |
|
10-Oct-2017 |
Mika Kahola <mika.kahola@intel.com> |
drm/i915: Fold IRQ pipe masks Fold IRQ pipe masks into one loop instead of hardcoding per pipe. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1507630626-23806-4-git-send-email-mika.kahola@intel.com
|
#
beecec90 |
|
03-Oct-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/execlists: Preemption! When we write to ELSP, it triggers a context preemption at the earliest arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other operations and the explicit MI_ARB_CHECK). If this is to the same context, it triggers a LITE_RESTORE where the RING_TAIL is merely updated (used currently to chain requests from the same context together, avoiding bubbles). However, if it is to a different context, a full context-switch is performed and it will start to execute the new context saving the image of the old for later execution. Previously we avoided preemption by only submitting a new context when the old was idle. But now we wish embrace it, and if the new request has a higher priority than the currently executing request, we write to the ELSP regardless, thus triggering preemption, but we tell the GPU to switch to our special preemption context (not the target). In the context-switch interrupt handler, we know that the previous contexts have finished execution and so can unwind all the incomplete requests and compute the new highest priority request to execute. It would be feasible to avoid the switch-to-idle intermediate by programming the ELSP with the target context. The difficulty is in tracking which request that should be whilst maintaining the dependency change, the error comes in with coalesced requests. As we only track the most recent request and its priority, we may run into the issue of being tricked in preempting a high priority request that was followed by a low priority request from the same context (e.g. for PI); worse still that earlier request may be our own dependency and the order then broken by preemption. By injecting the switch-to-idle and then recomputing the priority queue, we avoid the issue with tracking in-flight coalesced requests. Having tried the preempt-to-busy approach, and failed to find a way around the coalesced priority issue, Michal's original proposal to inject an idle context (based on handling GuC preemption) succeeds. The current heuristic for deciding when to preempt are only if the new request is of higher priority, and has the privileged priority of greater than 0. Note that the scheduler remains unfair! v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU. Since, the feature is now conditional and not always available when we have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a capability mask). v3: Stylistic tweaks. v4: Appease Joonas with a snippet of kerneldoc, only to fuel to fire of the preempt vs preempting debate. Suggested-by: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-8-chris@chris-wilson.co.uk
|
#
9dfe2e3a |
|
28-Sep-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen8+: Init/reset display interrupts only if i915 IRQs are enabled Only init / reset the display interrupts during power well enabling / disabling if the i915 interrupts are enabled. So far we did the init / reset during driver loading / resuming too, where initialization / enabling of the i915 interrupts happens only at a later point. This didn't cause a problem due to GEN8_MASTER_IRQ_CONTROL being cleared, but triggered gen3_assert_iir_is_zero() in GEN8_IRQ_INIT_NDX(). References: https://bugs.freedesktop.org/show_bug.cgi?id=102988 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170928100624.15533-1-imre.deak@intel.com
|
#
163e8aec |
|
27-Sep-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Also discard second CRC on gen8+ platforms. One of the differences I spotted for GEN8+ platforms when compared to older platforms is that spec for BDW+ includes this sentence: "The first CRC done indication after CRC is first enabled is from only a partial frame, so it will not have the expected CRC result." This is an indication that on BDW+ platforms, by the time we receive the interrupt the CRC is not accurate yet for the full frame. That would be ok, because we are already skipping the first CRC for all platforms. However the comment on the code state that it is for some unknown reason. Also, on CHV (gen8 lp) we were already discarding the second CRC as well to make sure we have a reliable CRC on hand. So based on all ou tests and bugs it seems that it is not on CHV that needs to discard 2 first CRCs, but all BDW+ platforms. Starting on SKL we have this CRC done bit (24), but the experiments around the use of this bit wasn't that stable as just discarding the second CRC. So, let's for now just move with CHV solution for all gen8+ platforms and make our CI a bit more stable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102374 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101309 Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170928002040.7917-1-rodrigo.vivi@intel.com
|
#
aec0246f |
|
25-Sep-2017 |
Uma Shankar <uma.shankar@intel.com> |
drm/i915: Enable scanline read based on frame timestamps For certain platforms on certain encoders, timings are driven from port instead of pipe. Thus, we can't rely on pipe scanline registers to get the timing information. Some cases scanline register read will not be functional. This is causing vblank evasion logic to fail since it relies on scanline, causing atomic update failure warnings. This patch uses pipe framestamp and current timestamp registers to calculate scanline. This is an indirect way to get the scanline. It helps resolve atomic update failure for gen9 dsi platforms. v2: Addressed Ville and Daniel's review comments. Updated the register MACROs, handled race condition for register reads, extracted timings from the hwmode. Removed the dependency on crtc->config to get the encoder type. v3: Made get scanline function generic v4: Addressed Ville's review comments. Added a flag to decide timestamp based scanline reporting. Changed 64bit variables to u32 v5: Adressed Ville's review comments. Put the scanline compute function at the place of caller. Removed hwmode flags from uapi and used a local i915 data structure instead. v6: Used vblank hwmode to get the timings. v7: Fixed sparse warnings, indentation and minor review comments. v8: Limited this only for Gen9 DSI. Credits-to: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com> 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/1506347761-4201-1-git-send-email-vidya.srinivas@intel.com
|
#
6b12ca56 |
|
14-Sep-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't rmw PIPESTAT enable bits i830 seems to occasionally forget the PIPESTAT enable bits when we read the register. These aren't the only registers on i830 that have problems with RMW, as reading the double buffered plane registers returns the latched value rather than the last written value. So something similar is perhaps going on with PIPESTAT. This corruption results on vblank interrupts occasionally turning off on their own, which leads to vblank timeouts and generally a stuck display subsystem. So let's not RMW the pipestat enable bits, and instead use the cached copy we have around. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170914151731.5034-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
b620e870 |
|
22-Sep-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Make own struct for execlist items Engine's execlist related items have been increasing to a point where a separate struct is warranted. Carve execlist specific items to a dedicated struct to add clarity. v2: add kerneldoc and fix whitespace (Joonas, Chris) v3: csb_mmio changes, rebase v4: s/\b(el|execlist)\b/execlists/ (Joonas) Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> (v3) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170922124307.10914-1-mika.kuoppala@intel.com
|
#
4f044a88 |
|
19-Sep-2017 |
Michal Wajdeczko <michal.wajdeczko@intel.com> |
drm/i915: Rename global i915 to i915_modparams Our global struct with params is named exactly the same way as new preferred name for the drm_i915_private function parameter. To avoid such name reuse lets use different name for the global. v5: pure rename v6: fix Credits-to: Coccinelle @@ identifier n; @@ ( - i915.n + i915_modparams.n ) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjala <ville.syrjala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919193846.38060-1-michal.wajdeczko@intel.com
|
#
de4d2106 |
|
18-Sep-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Check waiter->seqno carefully in case of preemption If preemption occurs at precisely the right moment, we may decide that the wait is complete even though the wait's request is no longer executing (having been preempted). We handle this situation by double checking that request following deciding whether the wait is complete. Reported-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170918162734.21294-2-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
|
#
17b51ad8 |
|
18-Sep-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only wake the waiter from the interrupt if passed As we now check if the seqno is complete in order to signal the fence, we can also decide not to wake up the first_waiter until it is ready (since it is waiting on the same seqno). The only caveat is that if we need the engine->irq_seqno_barrier to enforce some coherency between an interrupt and the seqno read, we have to always wake the waiter in order to perform that heavyweight barrier. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170918162734.21294-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
3b92e263 |
|
19-Sep-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnp: Display Wa #1179: WaHardHangonHotPlug "CNL PCH chance of hang when software accesses south display registers after hotplug is enabled. Workaround: Program 0xC2000 bits 11:8 = 0xF before enabling south display hotplug detection." "Workaround only needs to be applied to pre-production steppings used in graphics capable SKUs, but it is easier to apply to everything, and does not hurt." v2: Moving from clock gating to right before enabling SHOTPLUG_CTL as it should be. v3: Align with SOUTH_CHICKEN1 (DK) and consequently use proper spaces on bits definition since other bits around already use new style. And now that checkpatch is not noise anymore I also fixed the reg read mask to avoid going over 80 chars. Suggested-by: Ben Widawsky <ben@bwidawsk.net> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170919215703.25947-1-rodrigo.vivi@intel.com
|
#
99df13b6 |
|
14-Sep-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove unused 'in_vbl' from i915_get_crtc_scanoutpos() Commit 1bf6ad622b9b ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos") removed the use of in_vbl, but did not remove the local variable. Do so now. Fixes: 1bf6ad622b9b ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170914164213.18461-1-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit e01e71fc49d4c95090a04f898a3fe788c652a04b) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
6bcdb1c8 |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove duplicated irq_preinstall/uninstall hooks All the irq_preinstall and irq_uninstall hooks are now identical. Let's just rename them all the irq_reset and remove the pointless duplicates. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-16-ville.syrjala@linux.intel.com
|
#
d420a50c |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up the HWSTAM mess Currently we're unmasking some random looking bits in HWSTAM on gen3/4/5. The two bits we apparently unmask are 0 and 12, and also bits 16-31 on gen4/5. What those bits do depends on the gen as follows: bit 0: Breakpoint (gen2), ASLE (gen3), reserved (gen4), render user interrupt (gen5) bit 12: Sync flush statusa (gen2-4), reserved (gen5) bit 16-31: The ones that can unmasked seem to be mostly some display stuff on gen4. Bit 18 is the PIPE_CONTROL notify, which might be the only intresting one. On gen5 all the bits are reserved. So I don't know whether we actually depend on that status page write somehow. Extra seqno coherency by accident perhaps? Except we don't even unmask the user interrupt bit in HWSTAM except on gen5, and sync flush isn't something we use normally, so seems unlikely. So let's just assume we don't need any of this and mask everything in HWSTAM. From gen6 onwards there's a separate HWSTAM for each engine, and so we deal with them during the engine setup. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-15-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e01e71fc |
|
14-Sep-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove unused 'in_vbl' from i915_get_crtc_scanoutpos() Commit 1bf6ad622b9b ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos") removed the use of in_vbl, but did not remove the local variable. Do so now. Fixes: 1bf6ad622b9b ("drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170914164213.18461-1-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
5190707e |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Gen3 HWSTAM is actually 32 bits Bspec claims that HWSTAM is only 16 bits on gen3, but the other interrupts registers are 32 bits and there are 18 valid interrupt bits. Hence a 16 bit HWSTAM wouldn't be able to contain all the bits, so it seems the spec is incorrect about the size of the register. And indeed I can clear bits 16 and 17 just fine with a 32 bit write. So let's adjust the code to treat the register as 32 bits. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-14-ville.syrjala@linux.intel.com
|
#
af722d28 |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rewrite GMCH irq handlers to avoid loops Eliminate the loops from the gen2-3 irq handlers. Since we don't use MSI anymore on these platforms, and thus the CPU interrupt will be level triggered, we shouldn't need to play any tricks with IER to induce edges from IIR. IIR itself still detects only edges from PIPESTAT & co. on gen4 but since IIR is double buffered and we only clear one bit per irq handler invocation we can use the normal "clear PIPESTAT & co. -> clear IIR" approach to ack the interrupts. On gen2 everything is level triggered, and gen3 presumably follows either the gen2 or gen4 approach since nothing else would really make sense. v2: Drop the IER tricks since we no longer use MSI Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-12-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
eb64343c |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract PIPESTAT irq handling into separate functions Extract the gen2-4 PIPESTAT irq handling into separate functions just like we already do on VLV/CHV. We can share valleyview_pipestat_irq_ack() on all gmch platforms to actually read and clear the PIPESTAT status bits, so let's rename it to i9xx_pipestat_irq_ack(). Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-11-ville.syrjala@linux.intel.com
|
#
9515d7b8 |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove NULL dev_priv checks from irq_uninstall There should be no way to land in irq_uninstall without a valid dev_priv. Let's kill off the remaining checks, which are probably some kind of UMS leftovers. Not all the irq_uninstall hooks even had them anymore. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-10-ville.syrjala@linux.intel.com
|
#
c30bb1fd |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Unify the appearance of gen3/4 irq_postistall hooks Do the irq_mask/enable_mask setup in the same way on gen3/4, and also reorder the steps to make the code more uniform. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-9-ville.syrjala@linux.intel.com
|
#
e13924a8 |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Eliminate PORT_HOTPLUG_EN setup from gen3/4 irq_postinstall We've already cleared PORT_HOTPLUG_EN in the .irq_preinstall hook so doing it again in the .irq_postinstall is pointless. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-8-ville.syrjala@linux.intel.com
|
#
045cebd2 |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Setup EMR first on all gen2-4 Unify the appaerance of the gen2-4 irq postinstall hooks a little bit by doing the EMR setup first on all the platforms. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-7-ville.syrjala@linux.intel.com
|
#
e9e9848a |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce GEN2_IRQ_RESET/INIT Unify the appearance of the gen2 irq code with the gen3+ code by introducing the GEN2_IRQ_RESET/INIT macros. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-6-ville.syrjala@linux.intel.com
|
#
ba7eb789 |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use GEN3_IRQ_RESET/INIT on gen3/4 Replace the manual IMR+IER+IIR write sequences with the appropriate GEN3_IRQ_RESET/INIT macro invocations in gen3/4. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-5-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3488d4eb |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/GEN5/GEN3/ The GEN5_IRQ_RESET/INIT macros are perfectly suitable even for gen3/4 hardware as those have 32 bit interrupt registers. Let's rename the macros to reflect that fact. Gen2 on the other hand has 16 bit interrupt registers so these macros aren't really appropriate there. v2: Fix patch subject (Maarten) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-4-ville.syrjala@linux.intel.com
|
#
44d9241e |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clear pipestat consistently We have a lot of different ways of clearing the PIPESTAT registers. Let's unify it all into one function. There's no magic in PIPESTAT that would require any of the double clearing and whatnot that some of the code tries to do. All we can really do is clear the status bits and disable the enable bits. There is no way to mask anything so as soon as another event happens the status bit will become set again, and trying to clear them twice or something can't protect against that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
842ebf7a |
|
18-Aug-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't enable/unmask flip interrupts commit fd3a40242e87 ("drm/i915: Rip out legacy page_flip completion/irq handling") removed the code to hande the flip done/pending interrupts, but it failed to actually disable/mask those interrupts. Let's do that now. Also remove a stale comment that was left behind. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170818183705.27850-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
4ebc6509 |
|
08-Sep-2017 |
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> |
drm/i915/spt+: Don't reset invalid AUX channel interrupt bits in SDEIMR The SDE interrupt bits 25, 26 and 27 are either reserved or meant for DDI E hotplug in SPT+. These bits are meant for AUX channels only in LPT and CPT, so add the appropriate checks. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170909004255.14827-1-dhinakaran.pandiyan@intel.com
|
#
3814fd77 |
|
23-Aug-2017 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915: Make some RPS functions static They are not used anywhere else. Also, fix a small typo in a comment. No functional changes. Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1503532705-3692-1-git-send-email-oscar.mateo@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/1503532705-3692-1-git-send-email-oscar.mateo@intel.com
|
#
9db529aa |
|
08-Aug-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: More surgically unbreak the modeset vs reset deadlock There's no reason to entirely wedge the gpu, for the minimal deadlock bugfix we only need to unbreak/decouple the atomic commit from the gpu reset. The simplest way to fix that is by replacing the unconditional fence wait a the top of commit_tail by a wait which completes either when the fences are done (normal case, or when a reset doesn't need to touch the display state). Or when the gpu reset needs to force-unblock all pending modeset states. The lesser source of deadlocks is when we try to pin a new framebuffer and run into a stall. There's a bunch of places this can happen, like eviction, changing the caching mode, acquiring a fence on older platforms. And we can't just break the depency loop and keep going, the only way would be to break out and restart. But the problem with that approach is that we must stall for the reset to complete before we grab any locks, and with the atomic infrastructure that's a bit tricky. The only place is the ioctl code, and we don't want to insert code into e.g. the BUSY ioctl. Hence for that problem just create a critical section, and if any code is in there, wedge the GPU. For the steady-state this should never be a problem. Note that in both cases TDR itself keeps working, so from a userspace pov this trickery isn't observable. Users themselvs might spot a short glitch while the rendering is catching up again, but that's still better than pre-TDR where we've thrown away all the rendering, including innocent batches. Also, this fixes the regression TDR introduced of making gpu resets deadlock-prone when we do need to touch the display. One thing I noticed is that gpu_error.flags seems to use both our own wait-queue in gpu_error.wait_queue, and the generic wait_on_bit facilities. Not entirely sure why this inconsistency exists, I just picked one style. A possible future avenue could be to insert the gpu reset in-between ongoing modeset changes, which would avoid the momentary glitch. But that's a lot more work to implement in the atomic commit machinery, and given that we only need this for pre-g4x hw, of questionable utility just for the sake of polishing gpu reset even more on those old boxes. It might be useful for other features though. v2: Rebase onto 4.13 with a s/wait_queue_t/struct wait_queue_entry/. v3: Really emabarrassing fixup, I checked the wrong bit and broke the unbreak/wakeup logic. v4: Also handle deadlocks in pin_to_display. v5: Review from Michel: - Fixup the BUILD_BUG_ON - Don't forget about the overlay Cc: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2) Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808080828.23650-3-daniel.vetter@ffwll.ch Reviewed-by: Michel Thierry <michel.thierry@intel.com>
|
#
256cfdde |
|
11-Aug-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Simplify hpd pin to port We will soon need to make that pin port association per platform, so let's try to simplify it beforehand. Also we are moving the backwards port to pin here as well so let's use a standardized way. One extra possibility here would be to add a MISSING_CASE along with PORT_NONE, but I don't want to change this behaviour for now. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170811182650.14327-1-rodrigo.vivi@intel.com
|
#
03e0c832 |
|
26-Jul-2017 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Remove unused i915_err_print_instdone Just a simple code cleanup, below commit forgot to remove a function which it made unused: commit eaa14c24864ecfc60fb591f3b20747af7c67d446 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Oct 19 13:52:03 2016 +0100 drm/i915: Stop reporting error details in dmesg as well as the error-state As we already capture all the information from the registers into the error-state, also dumping that to dmesg just generates noise that upsets CI and users alike (and doesn't provide us with any more information). v2: Chris Wilson dag out the relevant commit. Commit msg updated. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170727110113.16942-1-tvrtko.ursulin@linux.intel.com
|
#
535275d3 |
|
21-Jul-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Squelch reset messages during selftests During our selftests, we try reseting the GPU tens of thousands of times, flooding the dmesg with our reset spam drowning out any potential warnings. Add an option to i915_reset()/i915_reset_engine() to specify a quiet reset for selftesting. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-19-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
001bd2cb |
|
12-Jul-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/hsw, bdw: Add irq_pipe_mask, has_vga power well attributes The pattern of a power well backing a set of pipe IRQ or VGA functionality applies to all HSW+ platforms. Using power well attributes instead of platform checks to decide whether to init/reset pipe IRQs and VGA correspondingly is cleaner and it allows us to unify the HSW/BDW and GEN9+ power well code in follow-up patches. Also use u8 for pipe_mask in related helpers to match the type in the power well struct. v2: - Use u8 instead of u32 for irq_pipe_mask. (Ville) v3: - Use u8 for pipe_mask in related helpers too for clarity. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170712155413.29839-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fd3a4024 |
|
20-Jul-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Rip out legacy page_flip completion/irq handling All these races and things are now solved through the vblank evasion trick, plus event handling is done using normal vblank even processing and drm_crtc_arm_vblank_event. We can get rid of all this complexity. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720175754.30751-5-daniel.vetter@ffwll.ch
|
#
bca2bf2a |
|
18-Jul-2017 |
Pandiyan, Dhinakaran <dhinakaran.pandiyan@intel.com> |
drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq INTEL_GEN() appears to be the new way of doing these platform checks, so convert this i915_irq.c too. Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1500402480-30741-1-git-send-email-dhinakaran.pandiyan@intel.com
|
#
a2196033 |
|
17-Jul-2017 |
Matthias Kaehlcke <mka@chromium.org> |
drm/i915: Consistently use enum pipe for PCH transcoders The current code uses in some instances enum transcoder for PCH transcoders and enum pipe in others. This is error prone and clang raises warnings like this: drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion from enumeration type 'enum pipe' to different enumeration type 'enum transcoder' [-Wenum-conversion] intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false); Consistently use the type enum pipe for PCH transcoders. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170717181403.57324-1-mka@chromium.org
|
#
7b92c1bd |
|
28-Jun-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid keeping waitboost active for signaling threads Once a client has requested a waitboost, we keep that waitboost active until all clients are no longer waiting. This is because we don't distinguish which waiter deserves the boost. However, with the advent of fence signaling, the signaler threads appear as waiters to the RPS interrupt handler. So instead of using a single boolean to track when to keep the waitboost active, use a counter of all outstanding waitboosted requests. At this point, I have removed all vestiges of the rate limiting on clients. Whilst this means that compositors should remain more fluid, it also means that boosts are more prevalent. See commit b29c19b64528 ("drm/i915: Boost RPS frequency for CPU stalls") for a longer discussion on the pros and cons of both approaches. A drawback of this implementation is that it requires constant request submission to keep the waitboost trimmed (as it is now cancelled when the request is completed). This will be fine for a busy system, but near idle the boosts may be kept for longer than desired (effectively tens of vblanks worstcase) and there is a reliance on rc6 instead. v2: Remove defunct rps.client_lock Reported-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170628123548.9236-1-chris@chris-wilson.co.uk
|
#
36703e79 |
|
22-Jun-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Break modeset deadlocks on reset Trying to do a modeset from within a reset is fraught with danger. We can fall into a cyclic deadlock where the modeset is waiting on a previous modeset that is waiting on a request, and since the GPU hung that request completion is waiting on the reset. As modesetting doesn't allow its locks to be broken and restarted, or for its *own* reset mechanism to take over the display, we have to do something very evil instead. If we detect that we are stuck waiting to prepare the display reset (by using a very simple timeout), resort to cancelling all in-flight requests and throwing the user data into /dev/null, which is marginally better than the driver locking up and keeping that data to itself. This is not a fix; this is just a workaround that unbreaks machines until we can resolve the deadlock in a way that doesn't lose data! v2: Move the retirement from set-wegded to the i915_reset() error path, after which we no longer any delayed worker cleanup for i915_handle_error() v3: C abuse for syntactic sugar v4: Cover all waits with the timeout to catch more driver breakage References: https://bugs.freedesktop.org/show_bug.cgi?id=99093 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170622105625.16952-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
142bc7d9 |
|
20-Jun-2017 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915: Modify error handler for per engine hang recovery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails at this point because core implementation is lacking) and continue recovery using legacy full gpu reset. A helper function is also added to query the availability of engine reset. A subsequent patch will add the capability to query which type of reset is present (engine -> full -> no-reset) via the get-param ioctl. It has been decided that the error events that are used to notify user of reset will only be sent in case if full chip reset. In case of just single (or multiple) engine resets, userspace won't be notified by these events. Note that this implementation of engine reset is for i915 directly submitting to the ELSP, where the driver manages the hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and firmware; i915 will still responsible for detecting a hang, and when it does it will have to request GuC to reset that Engine and remind the firmware about the outstanding submissions. This will be added in different patch. v2: rebase, advertise engine reset availability in platform definition, add note about GuC submission. v3: s/*engine_reset*/*reset_engine*/. (Chris) Handle reset as 2 level resets, by first going to engine only and fall backing to full/chip reset as needed, i.e. reset_engine will need the struct_mutex. v4: Pass the engine mask to i915_reset. (Chris) v5: Rebase, update selftests. v6: Rebase, prepare for mutex-less reset engine. v7: Pass reset_engine mask as a function parameter, and iterate over the engine mask for reset_engine. (Chris) v8: Use i915.reset >=2 in has_reset_engine; remove redundant reset logging; add a reset-engine-in-progress flag to prevent concurrent resets, and avoid dual purposing of reset-backoff. (Chris) v9: Support reset of different engines in parallel (Chris) v10: Handle reset-engine flag locking better (Chris) v11: Squash in reporting of per-engine-reset availability. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Ian Lister <ian.lister@intel.com> Signed-off-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-4-michel.thierry@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-5-chris@chris-wilson.co.uk
|
#
d5367307 |
|
20-Jun-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Wait for concurrent global resets to complete If we enter i915_handle_error() a second time and a global reset is already in progress, we can simply wait for completion of the first reset. Currently we exit early prior to the actual reset being performed -- the worst of both worlds! v2: Plug into the existing reset_queue, and remember that kselftests is playing games with I915_RESET_BACKOFF to prevent hangcheck from screwing up. v3: Rename to i915_reset_device to fit in better with i915_reset_engine Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-2-chris@chris-wilson.co.uk
|
#
ca814b25 |
|
24-May-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/vblank: Consistent drm_crtc_ prefix We use drm_crtc_ for all the new-style vblank functions which directly take a struct drm_crtc *. drm_accurate_vblank_count was the odd one out, correct this to appease my OCD. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170524145212.27837-13-daniel.vetter@ffwll.ch
|
#
7b22b8c4 |
|
02-Jun-2017 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915/cnp: Introduce Cannonpoint PCH. Most of south engine display that is in PCH is still the same as SPT and KBP, except for this key differences: - Backlight: Backlight programming changed in CNP PCH. - Panel Power: Sligh programming changed in CNP PCH. - GMBUS and GPIO: The pin mapping has changed in CNP PCH. All of these changes follow more the BXT style. v2: Update definition to use dev_priv isntead of dev (Tvrtko). Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1496434004-29812-1-git-send-email-rodrigo.vivi@intel.com
|
#
9bd95909 |
|
27-Apr-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stop pretending to mask/unmask LPE audio interrupts vlv_display_irq_postinstall() enables the LPE audio interrupts regardless of whether the LPE audio irq chip has masked/unmasked them. Also the irqchip masking/unmasking doesn't consider the state of the display power well or the device, and hence just leads to dmesg spew when it tries to access the hardware while it's powered down. If the current way works, then we don't need to do anything in the mask/unmask hooks. If it doesn't work, well, then we'd need to properly track whether the irqchip has masked/unmasked the interrupts when we enable display interrupts. And the mask/unmask hooks would need to check whether display interrupts are even enabled before frobbing with he registers. So let's just assume the current way works and neuter the mask/unmask hooks. Also clean up vlv_display_irq_postinstall() a bit and stop it from trying to unmask/enable the LPE C interrupt on VLV since it doesn't exist. Cc: Takashi Iwai <tiwai@suse.de> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-4-ville.syrjala@linux.intel.com Reviewed-by: Takashi Iwai <tiwai@suse.de> (cherry picked from commit ebf5f921478b9b55ed4e634b994571dd23a8fca3) Reference: http://mid.mail-archive.com/874cf6d3-4e45-d4cf-e662-eb972490d2ce@redhat.com Tested-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
955a4b89 |
|
17-May-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Don't force serialisation on marking up execlists irq posted Since we coordinate with the execlists tasklet using a locked schedule operation that ensures that after we set the engine->irq_posted we always have an invocation of the tasklet, we do not need to use a locked operation to set the engine->irq_posted itself. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170517121007.27224-12-chris@chris-wilson.co.uk
|
#
5d3d69d5 |
|
17-May-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Stop inlining the execlists IRQ handler As the handler is now quite complex, involving a few atomics, the cost of the function preamble is negligible in comparison and so we should leave the function out-of-line for better I$. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170517121007.27224-11-chris@chris-wilson.co.uk
|
#
a4b2b015 |
|
17-May-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Don't mark an execlists context-switch when idle If we *know* that the engine is idle, i.e. we have not more contexts in flight, we can skip any spurious CSB idle interrupts. These spurious interrupts seem to arrive long after we assert that the engines are completely idle, triggering later assertions: [ 178.896646] intel_engine_is_idle(bcs): interrupt not handled, irq_posted=2 [ 178.896655] ------------[ cut here ]------------ [ 178.896658] kernel BUG at drivers/gpu/drm/i915/intel_engine_cs.c:226! [ 178.896661] invalid opcode: 0000 [#1] SMP [ 178.896663] Modules linked in: i915(E) x86_pkg_temp_thermal(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) ghash_clmulni_intel(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) intel_gtt(E) i2c_algo_bit(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) aesni_intel(E) prime_numbers(E) evdev(E) aes_x86_64(E) drm(E) crypto_simd(E) cryptd(E) glue_helper(E) mei_me(E) mei(E) lpc_ich(E) efivars(E) mfd_core(E) battery(E) video(E) acpi_pad(E) button(E) tpm_tis(E) tpm_tis_core(E) tpm(E) autofs4(E) i2c_i801(E) fan(E) thermal(E) i2c_designware_platform(E) i2c_designware_core(E) [ 178.896694] CPU: 1 PID: 522 Comm: gem_exec_whispe Tainted: G E 4.11.0-rc5+ #14 [ 178.896702] task: ffff88040aba8d40 task.stack: ffffc900003f0000 [ 178.896722] RIP: 0010:intel_engine_init_global_seqno+0x1db/0x1f0 [i915] [ 178.896725] RSP: 0018:ffffc900003f3ab0 EFLAGS: 00010246 [ 178.896728] RAX: 0000000000000000 RBX: ffff88040af54000 RCX: 0000000000000000 [ 178.896731] RDX: ffff88041ec933e0 RSI: ffff88041ec8cc48 RDI: ffff88041ec8cc48 [ 178.896734] RBP: ffffc900003f3ac8 R08: 0000000000000000 R09: 000000000000047d [ 178.896736] R10: 0000000000000040 R11: ffff88040b344f80 R12: 0000000000000000 [ 178.896739] R13: ffff88040bce0000 R14: ffff88040bce52d8 R15: ffff88040bce0000 [ 178.896742] FS: 00007f2cccc2d8c0(0000) GS:ffff88041ec80000(0000) knlGS:0000000000000000 [ 178.896746] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 178.896749] CR2: 00007f41ddd8f000 CR3: 000000040bb03000 CR4: 00000000001406e0 [ 178.896752] Call Trace: [ 178.896768] reset_all_global_seqno.part.33+0x4e/0xd0 [i915] [ 178.896782] i915_gem_request_alloc+0x304/0x330 [i915] [ 178.896795] i915_gem_do_execbuffer+0x8a1/0x17d0 [i915] [ 178.896799] ? remove_wait_queue+0x48/0x50 [ 178.896812] ? i915_wait_request+0x300/0x590 [i915] [ 178.896816] ? wake_up_q+0x70/0x70 [ 178.896819] ? refcount_dec_and_test+0x11/0x20 [ 178.896823] ? reservation_object_add_excl_fence+0xa5/0x100 [ 178.896835] i915_gem_execbuffer2+0xab/0x1f0 [i915] [ 178.896844] drm_ioctl+0x1e6/0x460 [drm] [ 178.896858] ? i915_gem_execbuffer+0x260/0x260 [i915] [ 178.896862] ? dput+0xcf/0x250 [ 178.896866] ? full_proxy_release+0x66/0x80 [ 178.896869] ? mntput+0x1f/0x30 [ 178.896872] do_vfs_ioctl+0x8f/0x5b0 [ 178.896875] ? ____fput+0x9/0x10 [ 178.896878] ? task_work_run+0x80/0xa0 [ 178.896881] SyS_ioctl+0x3c/0x70 [ 178.896885] entry_SYSCALL_64_fastpath+0x17/0x98 [ 178.896888] RIP: 0033:0x7f2ccb455ca7 [ 178.896890] RSP: 002b:00007ffcabec72d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 178.896894] RAX: ffffffffffffffda RBX: 000055f897a44b90 RCX: 00007f2ccb455ca7 [ 178.896897] RDX: 00007ffcabec74a0 RSI: 0000000040406469 RDI: 0000000000000003 [ 178.896900] RBP: 00007f2ccb70a440 R08: 00007f2ccb70d0a4 R09: 0000000000000000 [ 178.896903] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 178.896905] R13: 000055f89782d71a R14: 00007ffcabecf838 R15: 0000000000000003 [ 178.896908] Code: 00 31 d2 4c 89 ef 8d 70 48 41 ff 95 f8 06 00 00 e9 68 fe ff ff be 0f 00 00 00 48 c7 c7 48 dc 37 a0 e8 fa 33 d6 e0 e9 0b ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 On the other hand, by ignoring the interrupt do we risk running out of space in CSB ring? Testing for a few hours suggests not, i.e. that we only seem to get the odd delayed CSB idle notification. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170517121007.27224-6-chris@chris-wilson.co.uk
|
#
5caa0fea |
|
09-May-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/vblank: Lock down vblank->hwmode more In the previous patch we've implemented hwmode tracking a la i915 for the vblank timestamp calculations. But that was just the basic semantics, i915 has some nice sanity checks to make sure we keep getting this right. Move them over too. v2: - WARN_ON_ONCE to avoid excessive spam (Ville) - Really only WARN on atomic drivers. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-5-daniel.vetter@ffwll.ch
|
#
1bf6ad62 |
|
09-May-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence the final timestamps might be a bit off. But since this is an existing bug I'm not going to change it, but just try to be bug-for-bug compatible with the current code. This only applies to radeon&amdgpu. - i915 tries to get it perfect by updating crtc->hwmode when the pipe is off (i.e. vblank->enabled = false). - All other atomic drivers look at crtc->state->adjusted_mode. Those that look at state->requested_mode simply don't adjust their mode, so it's the same. That has two problems: Accessing crtc->state from interrupt handling code is unsafe, and it's updated before we shut down the pipe. For nonblocking modesets it's even worse. For atomic drivers try to implement what i915 does. To do that we add a new hwmode field to the vblank structure, and update it from drm_calc_timestamping_constants(). For atomic drivers that's called from the right spot by the helper library already, so all fine. But for safety let's enforce that. For legacy driver this function is only called at the end (oh the fun), which is broken, so again let's not bother and just stay bug-for-bug compatible. The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos directly to implement ->get_vblank_timestamp in every driver, deleting a lot of code. v2: Completely new approach, trying to mimick the i915 solution. v3: Fixup kerneldoc. v4: Drop the WARN_ON to check that the vblank is off, atomic helpers currently unconditionally call this. Recomputing the same stuff should be harmless. v5: Fix typos and move misplaced hunks to the right patches (Neil). v6: Undo hunk movement (kbuild). Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
|
#
3fcdcb27 |
|
09-May-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3: kbuild says v1 was better ... Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch
|
#
d673c02c |
|
09-May-2017 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything else). Again, we DRM_ERROR. - EINVAL is checked at higher levels already, and if we'd use struct drm_crtc * instead of (dev, pipe) it would be real obvious that those are again core bugs. The only valid failure mode is crap hardware that couldn't sample a useful timestamp, to ask the core to just grab a not-so-accurate timestamp. Bool is perfectly fine for that. v2: Also fix up the one caller, I lost that in the shuffling (Jani). v3: Fixup commit message (Neil). Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch
|
#
ebf5f921 |
|
27-Apr-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stop pretending to mask/unmask LPE audio interrupts vlv_display_irq_postinstall() enables the LPE audio interrupts regardless of whether the LPE audio irq chip has masked/unmasked them. Also the irqchip masking/unmasking doesn't consider the state of the display power well or the device, and hence just leads to dmesg spew when it tries to access the hardware while it's powered down. If the current way works, then we don't need to do anything in the mask/unmask hooks. If it doesn't work, well, then we'd need to properly track whether the irqchip has masked/unmasked the interrupts when we enable display interrupts. And the mask/unmask hooks would need to check whether display interrupts are even enabled before frobbing with he registers. So let's just assume the current way works and neuter the mask/unmask hooks. Also clean up vlv_display_irq_postinstall() a bit and stop it from trying to unmask/enable the LPE C interrupt on VLV since it doesn't exist. Cc: Takashi Iwai <tiwai@suse.de> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170427160231.13337-4-ville.syrjala@linux.intel.com Reviewed-by: Takashi Iwai <tiwai@suse.de>
|
#
cefcff8f |
|
28-Apr-2017 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm/i915: Do not leak dev_priv->l3_parity.remap_info[] Add intel_irq_fini() for placing the deinitialization code, starting with freeing dev_priv->l3_parity.remap_info[]. Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1493366319-18515-1-git-send-email-joonas.lahtinen@linux.intel.com
|
#
acf2dc22 |
|
13-Apr-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Fix system hang with EI UP masked on Haswell Previously with commit a9c1f90c8e17 ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain, seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed to be unmasked for IVB and SNB in order to prevent system hang with chained batchbuffers. Our CI was seeing incomplete results with tests that used chained batches and it was found out that HSW needs to have this same bit unmasked to reliably survive chained batches. Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to prevent system hang with batch chaining. Testcase: igt/gem_exec_fence/nb-await-default Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 3396a273851c14634b98bb27be37508b06df94f4) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
3396a273 |
|
13-Apr-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Fix system hang with EI UP masked on Haswell Previously with commit a9c1f90c8e17 ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain, seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed to be unmasked for IVB and SNB in order to prevent system hang with chained batchbuffers. Our CI was seeing incomplete results with tests that used chained batches and it was found out that HSW needs to have this same bit unmasked to reliably survive chained batches. Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to prevent system hang with batch chaining. Testcase: igt/gem_exec_fence/nb-await-default Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
|
#
e7465473 |
|
22-Mar-2017 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/guc: Break out the GuC log extras into their own "runtime" struct When initializing the GuC log struct, there is an object we need to allocate always, since the GuC needs its address at fw load time. The rest is only needed during runtime, in the sense that we only create if we actually enable GuC logging. Make that distinction explicit by subdividing further the intel_guc_log struct. v2: Call the new struct "runtime", instead of "extras" (Joonas) v3: Check indent (Joonas) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
8c185eca |
|
16-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Split I915_RESET_IN_PROGRESS into two flags I915_RESET_IN_PROGRESS is being used for both signaling the requirement to i915_mutex_lock_interruptible() to avoid taking the struct_mutex and to instruct a waiter (already holding the struct_mutex) to perform the reset. To allow for a little more coordination, split these two meaning into a couple of distinct flags. I915_RESET_BACKOFF tells i915_mutex_lock_interruptible() not to acquire the mutex and I915_RESET_HANDOFF tells the waiter to call i915_reset(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170316171305.12972-1-chris@chris-wilson.co.uk
|
#
31de7350 |
|
15-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/scheduler: emulate a scheduler for guc This emulates execlists on top of the GuC in order to defer submission of requests to the hardware. This deferral allows time for high priority requests to gazump their way to the head of the queue, however it nerfs the GuC by converting it back into a simple execlist (where the CPU has to wake up after every request to feed new commands into the GuC). v2: Drop hack status - though iirc there is still a lockdep inversion between fence and engine->timeline->lock (which is impossible as the nesting only occurs on different fences - hopefully just requires some judicious lockdep annotation) v3: Apply lockdep nesting to enabling signaling on the request, using the pattern we already have in __i915_gem_request_submit(); v4: Replaying requests after a hang also now needs the timeline spinlock, to disable the interrupts at least v5: Hold wq lock for completeness, and emit a tracepoint for enabling signal v6: Reorder interrupt checking for a happier gcc. v7: Only signal the tasklet after a user-interrupt if using guc scheduling v8: Restore lost update of rq through the i915_guc_irq_handler (Tvrtko) v9: Avoid re-initialising the engine->irq_tasklet from inside a reset v10: Hook up the execlists-style tracepoints v11: Clear the execlists irq_posted bit after taking over the interrupt/tasklet Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170316125619.6856-1-chris@chris-wilson.co.uk Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
|
#
6b7f6aa7 |
|
15-Mar-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Use coarse grained residency counter with byt Set byt rc residency counters high level as chv does by default. We lose some accuracy on byt but we can do the calculation without extra hw read on both platforms, as now they behave identically in this respect. v2: use ktime v3: keep comparison u32 (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1489592584-10422-1-git-send-email-mika.kuoppala@intel.com
|
#
679cb6c1 |
|
15-Mar-2017 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Use ktime to calculate rc0 residency We have used cz timestamp register to gain a reference time wrt to residency calculations. The residency counts are in cz clk ticks (333Mhz clock) but for some reason the cz timestamp register gives 100us units. Perhaps for some other usage, the base-ten based values are easier, but in residency calculations raw units would have been the easiest. As there is not much advantage of using base-ten clock through a more costly punit access, take our reference times directly from kernel clock. v2: use ktime (Chris, Ville) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
db93991b |
|
15-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only attempt to signal the request once from the interrupt handler Check that request has not been signaled before acquiring a reference to the request for signaling later in the interrupt handler. The loading of the cacheline (for request->fence.flags) should be "free" when followed by the locked increment of the request->fence.refcount (which then sets the cacheline to exclusive mode), i.e. the cost of test_bit prior to an atomic_inc should be negligible. This should benefit us when we have a pile of bare breadcrumbs (interrupted execbuf) where we may get interrupts faster than we can get rid of the intel_wait, or if the device is too slow to run the bottom-half between interrupts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170315210726.12095-5-chris@chris-wilson.co.uk
|
#
1604a86d |
|
14-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Extend rpm wakelock during i915_handle_error() We take the runtime pm wakelock during i915_handle_error() to ensure that all paths that reach the error handler keep the device awake during the hw reads. However, we need to extend that from the reset handler to include the earlier capture routines. Reported-by: Antonio Argenziano <antonio.argenziano@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170314171840.25706-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com>
|
#
8f68d591 |
|
13-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Stop using RP_DOWN_EI on Baytrail On Baytrail, we manually calculate busyness over the evaluation interval to avoid issues with miscaluations with RC6 enabled. However, it turns out that the DOWN_EI interrupt generator is completely bust - it operates in two modes, continuous or never. Neither of which are conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just compute everything from the UP_EI which does seem to correspond to the desired interval. v2: Fixup gen6_rps_pm_mask() as well v3: Inline vlv_c0_above() to combine the now identical elapsed calculation for up/down and simplify the threshold testing Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.1+ Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170313170617.31564-1-chris@chris-wilson.co.uk (cherry picked from commit e0e8c7cb6eb68e9256de2d8cbeb481d3701c05ac) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
35a3abfd |
|
13-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only enable hotplug interrupts if the display interrupts are enabled In order to prevent accessing the hpd registers outside of the display power wells, we should refrain from writing to the registers before the display interrupts are enabled. [ 4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915] [ 4.740155] Unclaimed read from register 0x1e1110 [ 4.740168] Modules linked in: i915(+) intel_gtt drm_kms_helper prime_numbers [ 4.740190] CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 4.10.0-rc6+ #384 [ 4.740203] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 4.740220] Call Trace: [ 4.740236] dump_stack+0x4d/0x6f [ 4.740251] __warn+0xc1/0xe0 [ 4.740265] warn_slowpath_fmt+0x4a/0x50 [ 4.740281] ? insert_work+0x77/0xc0 [ 4.740355] ? fwtable_write32+0x90/0x130 [i915] [ 4.740431] __unclaimed_reg_debug+0x44/0x50 [i915] [ 4.740507] fwtable_read32+0xd8/0x130 [i915] [ 4.740575] i915_hpd_irq_setup+0xa5/0x100 [i915] [ 4.740649] intel_hpd_init+0x68/0x80 [i915] [ 4.740716] i915_driver_load+0xe19/0x1380 [i915] [ 4.740784] i915_pci_probe+0x32/0x90 [i915] [ 4.740799] pci_device_probe+0x8b/0xf0 [ 4.740815] driver_probe_device+0x2b6/0x450 [ 4.740828] __driver_attach+0xda/0xe0 [ 4.740841] ? driver_probe_device+0x450/0x450 [ 4.740853] bus_for_each_dev+0x5b/0x90 [ 4.740865] driver_attach+0x19/0x20 [ 4.740878] bus_add_driver+0x166/0x260 [ 4.740892] driver_register+0x5b/0xd0 [ 4.740906] ? 0xffffffffa0166000 [ 4.740920] __pci_register_driver+0x47/0x50 [ 4.740985] i915_init+0x5c/0x5e [i915] [ 4.740999] do_one_initcall+0x3e/0x160 [ 4.741015] ? __vunmap+0x7c/0xc0 [ 4.741029] ? kmem_cache_alloc+0xcf/0x120 [ 4.741045] do_init_module+0x55/0x1c4 [ 4.741060] load_module+0x1f3f/0x25b0 [ 4.741073] ? __symbol_put+0x40/0x40 [ 4.741086] ? kernel_read_file+0x100/0x190 [ 4.741100] SYSC_finit_module+0xbc/0xf0 [ 4.741112] SyS_finit_module+0x9/0x10 [ 4.741125] entry_SYSCALL_64_fastpath+0x17/0x98 [ 4.741135] RIP: 0033:0x7f8559a140f9 [ 4.741145] RSP: 002b:00007fff7509a3e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 4.741161] RAX: ffffffffffffffda RBX: 00007f855aba02d1 RCX: 00007f8559a140f9 [ 4.741172] RDX: 0000000000000000 RSI: 000055b6db0914f0 RDI: 0000000000000011 [ 4.741183] RBP: 0000000000020000 R08: 0000000000000000 R09: 000000000000000e [ 4.741193] R10: 0000000000000011 R11: 0000000000000246 R12: 000055b6db0854d0 [ 4.741204] R13: 000055b6db091150 R14: 0000000000000000 R15: 000055b6db035924 v2: Set dev_priv->display_irqs_enabled to true for all platforms other than vlv/chv that manually control the display power domain. Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97798 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lyude <cpaul@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Hans de Goede <jwrdegoede@fedoraproject.org> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170215131547.5064-1-chris@chris-wilson.co.uk Link: http://patchwork.freedesktop.org/patch/msgid/20170313170231.18633-1-chris@chris-wilson.co.uk (cherry picked from commit 262fd485ac6b476479f41f00bb104f6a1766ae66) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
707bdd3f |
|
09-Mar-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/__raw_i915_read32/I915_READ_FW/ in the SKL+ scanline read w/a Replace __raw_i915_read32() with I915_READ_FW() in the workaround for the SKL+ scanline counter hardware fail. The two are the same thing but everyone else uses I915_READ_FW() so let's follow suit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170309154434.29303-3-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
694e409d |
|
09-Mar-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use I915_READ_FW in i915_get_vblank_counter() Optimize the multi-register read in i915_get_vblank_counter() a little bit by grabbing the uncore lock manually and using I915_READ_FW(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170309154434.29303-2-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
1300b4f8 |
|
12-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Inline gen6_sanitize_rps_pm_mask() gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the object code. v2: Use const markup Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170312135426.2216-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
655d49ef |
|
12-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename REDIRECT_TO_GUC bit The REDIRECT_TO_GUC bit is a strange beast as it is a disable bit - setting the bit in the pm interrupt generation stops the interrupt going to the guc (not sending it to the guc as the name implies). To help the reader rename it to DISABLE_REDIRECT_TO_GUC so that we keep the bspec greppable name without it being as confusing! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170312132745.9618-1-chris@chris-wilson.co.uk Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
|
#
1f3b1fd3 |
|
10-Mar-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915/guc: Update rps.pm_intrmsk_mbz in guc_interrupts_capture/release Different state is to be maintained for rps.pm_intrmsk_mbz for GuC and Execlists. Updating it inside guc_interrupts_* routines as in those routines GuC load/submission params are sanitized and it should not be set based on HAS_GUC_SCHED during intel_irq_init. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489199821-6707-3-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
5dd04556 |
|
10-Mar-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: s/pm_intr_keep/pm_intrmsk_mbz "pm_intr_keep" is not conveying the intent that it is bitmask of interrupts that must be zero(mbz) in GEN6_PMINTRMSK. Name it "pm_intrmsk_mbz". Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1489199821-6707-2-git-send-email-sagar.a.kamble@intel.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
7c0a16ad |
|
09-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Defer unmasking RPS interrupts until after making adjustments To make our adjustments to RPS requires taking a mutex and potentially sleeping for an unknown duration - until we have completed our adjustments further RPS interrupts are immaterial (they are based on stale thresholds) and we can safely ignore them. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-3-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
569884e3 |
|
09-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use max(render, media) for Baytrail busyness calculation Currently, we sum the render and media cycles (on different engines) to compute a percentage - but we fail to factor in the duplication into the threshold calculations. This makes us very eager to upclock! If we just consider the maximum busy cycles of either counter, we should have an accurate reflection on whether there are cycles to spare to handle the workload at this frequency. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-2-chris@chris-wilson.co.uk
|
#
e0e8c7cb |
|
09-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Stop using RP_DOWN_EI on Baytrail On Baytrail, we manually calculate busyness over the evaluation interval to avoid issues with miscaluations with RC6 enabled. However, it turns out that the DOWN_EI interrupt generator is completely bust - it operates in two modes, continuous or never. Neither of which are conducive to good behaviour. Stop unmask the DOWN_EI interrupt and just compute everything from the UP_EI which does seem to correspond to the desired interval. v2: Fixup gen6_rps_pm_mask() as well v3: Inline vlv_c0_above() to combine the now identical elapsed calculation for up/down and simplify the threshold testing Fixes: 43cf3bf084ba ("drm/i915: Improved w/a for rps on Baytrail") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.1+ Link: http://patchwork.freedesktop.org/patch/msgid/20170309211232.28878-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
9735b04d |
|
06-Mar-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Initialize pm_intr_keep during intel_irq_init for GuC Driver needs to ensure that it doesn't mask the PM interrupts, which are unmasked/needed by GuC firmware. For that, Driver maintains a bitmask of interrupts to be kept unmasked, pm_intr_keep. pm_intr_keep was determined across GuC load. GuC gets loaded in different scenarios and it is not going to change the pm_intr_keep so this patch moves its setup to intel_irq_init. This patch fixes incorrect RPS masking leading to UP interrupts triggered even when at cur_freq=max and inversly for Down interrupts. Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1488862355-9768-1-git-send-email-sagar.a.kamble@intel.com
|
#
61d3dc70 |
|
03-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Split breadcrumbs spinlock into two As we now take the breadcrumbs spinlock within the interrupt handler, we wish to minimise its hold time. During the interrupt we do not care about the state of the full rbtree, only that of the first element, so we can guard that with a separate lock. v2: Rename first_wait to irq_wait to make it clearer that it is guarded by irq_lock. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170303190824.1330-1-chris@chris-wilson.co.uk
|
#
24754d75 |
|
03-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Take reference for signaling the request from hardirq Being inside a spinlock signaling that the hardware just completed a request doesn't prevent a second thread already spotting that the request is complete, freeing it and reallocating it! The code currently tries to prevent this using RCU -- but that only prevents the request from being freed, it doesn't prevent us from reallocating it - that requires us to take a reference. [ 206.922985] BUG: spinlock already unlocked on CPU#4, gem_exec_parall/7796 [ 206.922994] lock: 0xffff8801c6047120, .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1 [ 206.923000] CPU: 4 PID: 7796 Comm: gem_exec_parall Not tainted 4.10.0-CI-Patchwork_4008+ #1 [ 206.923006] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 1805 06/20/2016 [ 206.923012] Call Trace: [ 206.923014] <IRQ> [ 206.923019] dump_stack+0x67/0x92 [ 206.923023] spin_dump+0x73/0xc0 [ 206.923027] do_raw_spin_unlock+0x79/0xb0 [ 206.923031] _raw_spin_unlock_irqrestore+0x27/0x60 [ 206.923042] dma_fence_signal+0x160/0x230 [ 206.923060] notify_ring+0xae/0x2e0 [i915] [ 206.923073] ? ibx_hpd_irq_handler+0xc0/0xc0 [i915] [ 206.923086] gen8_gt_irq_handler+0x219/0x290 [i915] [ 206.923100] gen8_irq_handler+0x8e/0x6b0 [i915] [ 206.923105] __handle_irq_event_percpu+0x58/0x370 [ 206.923109] handle_irq_event_percpu+0x1e/0x50 [ 206.923113] handle_irq_event+0x34/0x60 [ 206.923117] handle_edge_irq+0xbe/0x150 [ 206.923122] handle_irq+0x15/0x20 [ 206.923126] do_IRQ+0x63/0x130 [ 206.923142] ? i915_mutex_lock_interruptible+0x39/0x140 [i915] [ 206.923148] common_interrupt+0x90/0x90 [ 206.923153] RIP: 0010:osq_lock+0x77/0x110 [ 206.923157] RSP: 0018:ffffc90001cabaa0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff6e [ 206.923164] RAX: 0000000000000000 RBX: ffff880236d1abc0 RCX: ffff8801ef642fc0 [ 206.923169] RDX: ffff8801ef6427c0 RSI: ffffffff81c6e7fd RDI: ffffffff81c7c848 [ 206.923175] RBP: ffffc90001cabab8 R08: 00000000692bb19b R09: 08c1493200000000 [ 206.923180] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880236cdabc0 [ 206.923185] R13: ffff8802207f00b0 R14: ffffffffa00b7cd9 R15: ffff8802207f0070 [ 206.923191] </IRQ> [ 206.923206] ? i915_mutex_lock_interruptible+0x39/0x140 [i915] [ 206.923213] __mutex_lock+0x649/0x990 [ 206.923217] ? __mutex_lock+0xb0/0x990 [ 206.923221] ? _raw_spin_unlock+0x2c/0x50 [ 206.923226] ? __pm_runtime_resume+0x56/0x80 [ 206.923242] ? i915_mutex_lock_interruptible+0x39/0x140 [i915] [ 206.923249] mutex_lock_interruptible_nested+0x16/0x20 [ 206.923264] i915_mutex_lock_interruptible+0x39/0x140 [i915] [ 206.923270] ? __pm_runtime_resume+0x56/0x80 [ 206.923285] i915_gem_do_execbuffer.isra.15+0x442/0x1d10 [i915] [ 206.923291] ? __lock_acquire+0x449/0x1b50 [ 206.923296] ? __might_fault+0x3e/0x90 [ 206.923301] ? __might_fault+0x87/0x90 [ 206.923305] ? __might_fault+0x3e/0x90 [ 206.923320] i915_gem_execbuffer2+0xb5/0x220 [i915] [ 206.923327] drm_ioctl+0x200/0x450 [ 206.923341] ? i915_gem_execbuffer+0x330/0x330 [i915] [ 206.923348] do_vfs_ioctl+0x90/0x6e0 [ 206.923352] ? __fget+0x108/0x200 [ 206.923356] ? expand_files+0x2b0/0x2b0 [ 206.923361] SyS_ioctl+0x3c/0x70 [ 206.923365] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 206.923369] RIP: 0033:0x7fdd75fc6357 [ 206.923373] RSP: 002b:00007fdd20e59bf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 206.923380] RAX: ffffffffffffffda RBX: ffffffff81481ff3 RCX: 00007fdd75fc6357 [ 206.923385] RDX: 00007fdd20e59c70 RSI: 0000000040406469 RDI: 0000000000000003 [ 206.923390] RBP: ffffc90001cabf88 R08: 0000000000000040 R09: 00000000000003f7 [ 206.923396] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 206.923401] R13: 0000000000000003 R14: 0000000040406469 R15: 0000000001cf9cb0 [ 206.923408] ? __this_cpu_preempt_check+0x13/0x20 Fixes: 56299fb7d904 ("drm/i915: Signal first fence from irq handler if complete") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100051 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> Link: http://patchwork.freedesktop.org/patch/msgid/20170303144557.4815-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
72259536 |
|
02-Mar-2017 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add plane update/disable tracepoints Add tracepoints for plane programming. The tracepoints will dump the frame and scanline counters, so this can be used to verify eg. that the plane gets reprogrammed at the right time with respect to watermark programming (if we have appropriate tracepoints for that as well). v2: Rebase due to legacy cursor changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170302171508.1666-16-ville.syrjala@linux.intel.com
|
#
67520415 |
|
02-Mar-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: s/assert_spin_locked/lockdep_assert_held/ assert_spin_locked() becomes an unconditionally compiled BUG_ON(), adding debug code right into the heart of critical routines like interrupt handlers. text data bss dec hex 1296480 19944 2272 1318696 141f28 before (lockdep disabled) 1295984 19944 2272 1318200 141d38 after 1336261 21139 3208 1360608 14c2e0 before (lockdep enabled) 1339920 21139 3208 1364267 14d12b after Small saving for release; hopefully more instructive in debug. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170302132801.599-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
67b807a8 |
|
27-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Delay disabling the user interrupt for breadcrumbs A significant cost in setting up a wait is the overhead of enabling the interrupt. As we disable the interrupt whenever the queue of waiters is empty, if we are frequently waiting on alternating batches, we end up re-enabling the interrupt on a frequent basis. We do want to disable the interrupt during normal operations as under high load it may add several thousand interrupts/s - we have been known in the past to occupy whole cores with our interrupt handler after accidentally leaving user interrupts enabled. As a compromise, leave the interrupt enabled until the next IRQ, or the system is idle. This gives a small window for a waiter to keep the interrupt active and not be delayed by having to re-enable the interrupt. v2: Restore hangcheck/missed-irq detection for continuations v3: Be more careful restoring the hangcheck timer after reset v4: Be more careful restoring the fake irq after reset (if required!) v5: Redo changes to intel_engine_wakeup() v6: Factor out __intel_engine_wakeup() v7: Improve commentary for declaring a missed wakeup 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: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-4-chris@chris-wilson.co.uk
|
#
56299fb7 |
|
27-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Signal first fence from irq handler if complete As execlists and other non-semaphore multi-engine devices coordinate between engines using interrupts, we can shave off a few 10s of microsecond of scheduling latency by doing the fence signaling from the interrupt as opposed to a RT kthread. (Realistically the delay adds about 1% to an individual cross-engine workload.) We only signal the first fence in order to limit the amount of work we move into the interrupt handler. We also have to remember that our breadcrumbs may be unordered with respect to the interrupt and so we still require the waiter process to perform some heavyweight coherency fixups, as well as traversing the tree of waiters. v2: No need for early exit in irq handler - it breaks the flow between patches and prevents the tracepoint v3: Restore rcu hold across irq signaling of request 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: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-2-chris@chris-wilson.co.uk
|
#
dffabc8f |
|
21-Feb-2017 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915/tracepoints: Rename i915_gem_request_notify i915_gem_ring_notify is more appropriate since we do not have the request information at this point, but it is simply a signal from the engine that some request has been completed. v2: * Always trace and log if there were any waiters. * Rename to intel_engine_notify. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
2246bea6 |
|
17-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Postpone fake breadcrumb interrupt until real interrupts cease When the timer expires for checking on interrupt processing, check to see if any interrupts arrived within the last time period. If real interrupts are still being delivered, we can be reassured that we haven't missed the final interrupt as the waiter will still be woken. Only once all activity ceases, do we have to worry about the waiter never being woken and so need to install a timer to kick the waiter for a slow arrival of a seqno. Signed-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: http://patchwork.freedesktop.org/patch/msgid/20170217151304.16665-2-chris@chris-wilson.co.uk
|
#
2a57d9cc |
|
27-Jan-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9+: Enable hotplug detection early For LSPCON resume time initialization we need to sample the corresponding pin's HPD level, but this is only available when HPD detection is enabled. Currently we enable detection only when enabling HPD interrupts which is too late, so bring the enabling of detection earlier. This is needed by the next patch. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-2-git-send-email-imre.deak@intel.com (cherry picked from commit 7fff8126d9cc902b2636d05d5d34894a75174993) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
262fd485 |
|
15-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only enable hotplug interrupts if the display interrupts are enabled In order to prevent accessing the hpd registers outside of the display power wells, we should refrain from writing to the registers before the display interrupts are enabled. [ 4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915] [ 4.740155] Unclaimed read from register 0x1e1110 [ 4.740168] Modules linked in: i915(+) intel_gtt drm_kms_helper prime_numbers [ 4.740190] CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 4.10.0-rc6+ #384 [ 4.740203] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 4.740220] Call Trace: [ 4.740236] dump_stack+0x4d/0x6f [ 4.740251] __warn+0xc1/0xe0 [ 4.740265] warn_slowpath_fmt+0x4a/0x50 [ 4.740281] ? insert_work+0x77/0xc0 [ 4.740355] ? fwtable_write32+0x90/0x130 [i915] [ 4.740431] __unclaimed_reg_debug+0x44/0x50 [i915] [ 4.740507] fwtable_read32+0xd8/0x130 [i915] [ 4.740575] i915_hpd_irq_setup+0xa5/0x100 [i915] [ 4.740649] intel_hpd_init+0x68/0x80 [i915] [ 4.740716] i915_driver_load+0xe19/0x1380 [i915] [ 4.740784] i915_pci_probe+0x32/0x90 [i915] [ 4.740799] pci_device_probe+0x8b/0xf0 [ 4.740815] driver_probe_device+0x2b6/0x450 [ 4.740828] __driver_attach+0xda/0xe0 [ 4.740841] ? driver_probe_device+0x450/0x450 [ 4.740853] bus_for_each_dev+0x5b/0x90 [ 4.740865] driver_attach+0x19/0x20 [ 4.740878] bus_add_driver+0x166/0x260 [ 4.740892] driver_register+0x5b/0xd0 [ 4.740906] ? 0xffffffffa0166000 [ 4.740920] __pci_register_driver+0x47/0x50 [ 4.740985] i915_init+0x5c/0x5e [i915] [ 4.740999] do_one_initcall+0x3e/0x160 [ 4.741015] ? __vunmap+0x7c/0xc0 [ 4.741029] ? kmem_cache_alloc+0xcf/0x120 [ 4.741045] do_init_module+0x55/0x1c4 [ 4.741060] load_module+0x1f3f/0x25b0 [ 4.741073] ? __symbol_put+0x40/0x40 [ 4.741086] ? kernel_read_file+0x100/0x190 [ 4.741100] SYSC_finit_module+0xbc/0xf0 [ 4.741112] SyS_finit_module+0x9/0x10 [ 4.741125] entry_SYSCALL_64_fastpath+0x17/0x98 [ 4.741135] RIP: 0033:0x7f8559a140f9 [ 4.741145] RSP: 002b:00007fff7509a3e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 4.741161] RAX: ffffffffffffffda RBX: 00007f855aba02d1 RCX: 00007f8559a140f9 [ 4.741172] RDX: 0000000000000000 RSI: 000055b6db0914f0 RDI: 0000000000000011 [ 4.741183] RBP: 0000000000020000 R08: 0000000000000000 R09: 000000000000000e [ 4.741193] R10: 0000000000000011 R11: 0000000000000246 R12: 000055b6db0854d0 [ 4.741204] R13: 000055b6db091150 R14: 0000000000000000 R15: 000055b6db035924 v2: Set dev_priv->display_irqs_enabled to true for all platforms other than vlv/chv that manually control the display power domain. Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97798 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lyude <cpaul@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Hans de Goede <jwrdegoede@fedoraproject.org> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/20170215131547.5064-1-chris@chris-wilson.co.uk Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
bd64818d |
|
10-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only apply the jump to the "efficient RPS" frequency on startup Currently we apply the jump to rpe if we are below it and the GPU needs more power. For some GPUs, the rpe is 75% of the maximum range causing us to dramatically overshoot low power applications *and* unable to reach the low frequency that can most efficiently deliver their workload. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170210150348.22146-3-chris@chris-wilson.co.uk Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
|
#
17136d54 |
|
10-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Don't accidentally increase the frequency in handling DOWN rps If we receive a DOWN_TIMEOUT rps interrupt, we respond by reducing the GPU clocks significantly. Before we do, double check that the frequency we pick is actually a decrease. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170210150348.22146-2-chris@chris-wilson.co.uk Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
|
#
317eaa95 |
|
03-Feb-2017 |
Lyude <lyude@redhat.com> |
drm/i915/debugfs: Add i915_hpd_storm_ctl This adds a file in i915's debugfs directory that allows userspace to manually control HPD storm detection. This is mainly for hotplugging tests, where we might want to test HPD storm functionality or disable storm detection to speed up hotplugging tests without breaking anything. Changes since v1: - Make HPD storm interval configurable - Misc code cleanup Signed-off-by: Lyude <lyude@redhat.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Cc: Tomeu Vizoso <tomeu@tomeuvizoso.net>
|
#
967dd484 |
|
07-Feb-2017 |
Shawn Guo <shawn.guo@linaro.org> |
drm: remove drm_vblank_no_hw_counter assignment from driver code Core code already makes drm_driver.get_vblank_counter hook optional by letting drm_vblank_no_hw_counter be the default implementation for the function hook. So the drm_vblank_no_hw_counter assignment in the driver code becomes redundant and can be removed now. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Inki Dae <inki.dae@samsung.com> Cc: Stefan Agner <stefan@agner.ch> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: CK Hu <ck.hu@mediatek.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Marek Vasut <marex@denx.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Eric Anholt <eric@anholt.net> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1486458995-31018-3-git-send-email-shawnguo@kernel.org
|
#
1a56b1a2 |
|
27-Jan-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen5+, pch: Enable hotplug detection early To be consistent with the recent change to enable hotplug detection early on GEN9 platforms do the same on all non-GMCH platforms starting from GEN5. On GMCH platforms enabling detection without interrupts isn't trivial, since AUX and HPD have a shared interrupt line. It could be done there too by using a SW interrupt mask, but I punt on that for now. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-5-git-send-email-imre.deak@intel.com
|
#
7fff8126 |
|
27-Jan-2017 |
Imre Deak <imre.deak@intel.com> |
drm/i915/gen9+: Enable hotplug detection early For LSPCON resume time initialization we need to sample the corresponding pin's HPD level, but this is only available when HPD detection is enabled. Currently we enable detection only when enabling HPD interrupts which is too late, so bring the enabling of detection earlier. This is needed by the next patch. Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485509961-9010-2-git-send-email-imre.deak@intel.com
|
#
9fcee2f7 |
|
26-Jan-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Report the failure to write to the punit The write to the punit may fail, so propagate the error code back to its callers. Of particular interest are the RPS writes, so add appropriate user error codes and logging. v2: Add DEBUG for failed frequency changes during RPS. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170126101919.13211-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
eef57324 |
|
24-Jan-2017 |
Jerome Anand <jerome.anand@intel.com> |
drm/i915: setup bridge for HDMI LPE audio driver Enable support for HDMI LPE audio mode on Baytrail and Cherrytrail when HDaudio controller is not detected Setup minimum required resources during i915_driver_load: 1. Create a platform device to share MMIO/IRQ resources 2. Make the platform device child of i915 device for runtime PM. 3. Create IRQ chip to forward HDMI LPE audio irqs. HDMI LPE audio driver (a standalone sound driver) probes the LPE audio device and creates a new sound card. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Jerome Anand <jerome.anand@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
#
f747026c |
|
24-Jan-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only run execlist context-switch handler after an interrupt Mark when we run the execlist tasklet following the interrupt, so we don't probe a potentially uninitialised register when submitting the contexts multiple times before the hardware responds. v2: Use a shared engine->irq_posted v3: Always use locked bitops to be sure of atomicity wrt to other bits in the mask. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170124152021.26587-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
538b257d |
|
24-Jan-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move breadcrumbs irq_posted up a level to engine In the next patch, we will use the irq_posted technique for another engine interrupt, rather than use two members for the atomic updates, we can use two bits of one instead. First, we need to update the breadcrumbs to use the new common engine->irq_posted. v2: Use set_bit() rather than __set_bit() to ensure atomicity with respect to other bits in the mask Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170124151805.26146-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
7e79a683 |
|
19-Jan-2017 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Set adjustment to zero on Up/Down interrupts if freq is already max/min When we reach the user's RPS limits, stop requesting an adjustment. Even though we will clamp the requested frequency later, we rely on interrupt masking to disable further adjustments in the same direction. Even though it is unlikely (one scenario is a bug in the driver, another is careful manipulation through the uAPI) if we keep exponentially increasing the adjustment value, it will wrap and cause a negative adjustment. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1484884104-28134-2-git-send-email-sagar.a.kamble@intel.com
|
#
87c390b6 |
|
11-Jan-2017 |
Michel Thierry <michel.thierry@intel.com> |
drm/i915: Keep i915_handle_error kerneldoc parameters together And before the function description. Tidy up from commit 14bb2c11796d70b ("drm/i915: Fix a buch of kerneldoc warnings"), all others kerneldoc blocks look ok. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170112041817.1102-2-michel.thierry@intel.com
|
#
246ee524 |
|
10-Jan-2017 |
Tomeu Vizoso <tomeu.vizoso@collabora.com> |
drm/i915: Put "cooked" vlank counters in frame CRC lines Use drm_accurate_vblank_count so we have the full 32 bit to represent the frame counter and userspace has a simpler way of knowing when the counter wraps around. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Robert Foss <robert.foss@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170110134305.26326-3-tomeu.vizoso@collabora.com
|
#
8c6b709d |
|
10-Jan-2017 |
Tomeu Vizoso <tomeu.vizoso@collabora.com> |
drm/i915: Use new CRC debugfs API The core provides now an ABI to userspace for generation of frame CRCs, so implement the ->set_crc_source() callback and reuse as much code as possible with the previous ABI implementation. When handling the pageflip interrupt, we skip 1 or 2 frames depending on the HW because they contain wrong values. For the legacy ABI for generating frame CRCs, this was done in userspace but now that we have a generic ABI it's better if it's not exposed by the kernel. v2: - Leave the legacy implementation in place as the ABI implementation in the core is incompatible with it. v3: - Use the "cooked" vblank counter so we have a whole 32 bits. - Make sure we don't mess with the state of the legacy CRC capture ABI implementation. v4: - Keep use of get_vblank_counter as in the legacy code, will be changed in a followup commit. v5: - Skip first frame or two as it's known that they contain wrong data. - A few fixes suggested by Emil Velikov. v6: - Rework programming of the HW registers to preserve previous behavior. v7: - Address whitespace issue. - Added a comment on why in the implementation of the new ABI we skip the 1st or 2nd frames. v9: - Add stub for intel_crtc_set_crc_source. v12: - Rebased. - Remove stub for intel_crtc_set_crc_source and instead set the callback to NULL (Jani Nikula). v15: - Rebased. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Robert Foss <robert.foss@collabora.com> irq Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170110134305.26326-2-tomeu.vizoso@collabora.com
|
#
cc3f90f0 |
|
02-Dec-2016 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915/glk: Reuse broxton code for geminilake Geminilake is mostly backwards compatible with broxton, so change most of the IS_BROXTON() checks to IS_GEN9_LP(). Differences between the platforms will be implemented in follow-up patches. v2: Don't reuse broxton's path in intel_update_max_cdclk(). Don't set plane count as in broxton. v3: Rebase v4: Include the check intel_bios_is_port_hpd_inverted(). Commit message. v5: Leave i915_dmc_info() out; glk's csr version != bxt's. (Rodrigo) v6: Rebase. v7: Convert a few mode IS_BROXTON() occurances in pps, ddi, dsi and pll code. (Rodrigo) v8: Squash a couple of DDI patches with more conversions. (Rodrigo) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480667037-11215-2-git-send-email-ander.conselvan.de.oliveira@intel.com
|
#
a80bc45f |
|
25-Nov-2016 |
Arkadiusz Hiler <arkadiusz.hiler@intel.com> |
drm/i915/guc: Drop guc2host/host2guc from names To facilitate code reorganization we are renaming everything that contains guc2host or host2guc. host2guc_action() and host2guc_action_response() become guc_send() and guc_recv() respectively. Other host2guc_*() functions become simply guc_*(). Other entities are renamed basing on context they appear in: - HOST2GUC_ACTIONS_& become INTEL_GUC_ACTION_* - HOST2GUC_{INTERRUPT,TRIGGER} become GUC_SEND_{INTERRUPT,TRIGGER} - GUC2HOST_STATUS_* become INTEL_GUC_STATUS_* - GUC2HOST_MSG_* become INTEL_GUC_RECV_MSG_* - action_lock becomes send_mutex v2: drop unnecessary backslashes and use BIT() instead of '<<' v3: shortened enum names and INTEL_GUC_STATUS_* Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Winiarski <michal.winiarski@intel.com> Signed-off-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-3-git-send-email-arkadiusz.hiler@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b243f530 |
|
16-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: dev_priv cleanup in i915_irq.c And a little bit of function prototype changes. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
4805fe82 |
|
04-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Further assorted dev_priv cleanups A small selection of macros which can only accept dev_priv from now on and a resulting trickle of fixups. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
|
#
56b857a5 |
|
07-Nov-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: More assorted dev_priv cleanups A small selection of macros which can only accept dev_priv from now on and a resulting trickle of fixups. v2: Keep original order. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
|
#
3ac168a7 |
|
01-Nov-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Move hangcheck code out from i915_irq.c Create new file for hangcheck specific code, intel_hangcheck.c, and move all related code in it. v2: s/intel_engine_hangcheck/intel_engine (Chris) No functional changes. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1478018583-5816-1-git-send-email-mika.kuoppala@intel.com
|
#
98187836 |
|
31-Oct-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Always use intel_get_crtc_for_pipe() Replace the open coded dev_priv->pipe_to_crtc_mapping[] usage with intel_get_crtc_for_pipe(). Mostly done with coccinelle, with a few manual tweaks @@ expression E1, E2; @@ ( - E1->pipe_to_crtc_mapping[E2] + intel_get_crtc_for_pipe(E1, E2) | - E1->plane_to_crtc_mapping[E2] + intel_get_crtc_for_plane(E1, E2) ) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b91eb5cc |
|
31-Oct-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass dev_priv to intel_get_crtc_for_pipe() Unify our approach to things by passing around dev_priv instead of dev. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e2af48c6 |
|
31-Oct-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Store struct intel_crtc * in {pipe,plane}_to_crtc_mapping[] A lot of users of the {pipe,plane}_to_crtc_mapping[] will end up casting the result to intel_crtc, so let's just store the intel_crtc pointer in the first place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477946245-14134-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
cb399eab |
|
01-Nov-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid accessing request->timeline outside of its lifetime Whilst waiting on a request, we may do so without holding any locks or any guards beyond a reference to the request. In order to avoid taking locks within request deallocation, we drop references to its timeline (via the context and ppgtt) upon retirement. We should avoid chasing such pointers outside of their control, in particular we inspect the request->timeline to see if we may restore the RPS waitboost for a client. If we instead look at the engine->timeline, we will have similar behaviour on both full-ppgtt and !full-ppgtt systems and reduce the amount of reward we give towards stalling clients (i.e. only if the client stalls and the GPU is uncontended does it reclaim its boost). This restores behaviour back to pre-timelines, whilst fixing: [ 645.078485] BUG: KASAN: use-after-free in i915_gem_object_wait_fence+0x1ee/0x2e0 at addr ffff8802335643a0 [ 645.078577] Read of size 4 by task gem_exec_schedu/28408 [ 645.078638] CPU: 1 PID: 28408 Comm: gem_exec_schedu Not tainted 4.9.0-rc2+ #64 [ 645.078724] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 645.078816] ffff88022daef9a0 ffffffff8143d059 ffff880235402a80 ffff880233564200 [ 645.078998] ffff88022daef9c8 ffffffff81229c5c ffff88022daefa48 ffff880233564200 [ 645.079172] ffff880235402a80 ffff88022daefa38 ffffffff81229ef0 000000008110a796 [ 645.079345] Call Trace: [ 645.079404] [<ffffffff8143d059>] dump_stack+0x68/0x9f [ 645.079467] [<ffffffff81229c5c>] kasan_object_err+0x1c/0x70 [ 645.079534] [<ffffffff81229ef0>] kasan_report_error+0x1f0/0x4b0 [ 645.079601] [<ffffffff8122a244>] kasan_report+0x34/0x40 [ 645.079676] [<ffffffff81634f5e>] ? i915_gem_object_wait_fence+0x1ee/0x2e0 [ 645.079741] [<ffffffff81229951>] __asan_load4+0x61/0x80 [ 645.079807] [<ffffffff81634f5e>] i915_gem_object_wait_fence+0x1ee/0x2e0 [ 645.079876] [<ffffffff816364bf>] i915_gem_object_wait+0x19f/0x590 [ 645.079944] [<ffffffff81636320>] ? i915_gem_object_wait_priority+0x500/0x500 [ 645.080016] [<ffffffff8110fb30>] ? debug_show_all_locks+0x1e0/0x1e0 [ 645.080084] [<ffffffff8110abdc>] ? check_chain_key+0x14c/0x210 [ 645.080157] [<ffffffff8110a796>] ? __lock_is_held+0x46/0xc0 [ 645.080226] [<ffffffff8163bc61>] ? i915_gem_set_domain_ioctl+0x141/0x690 [ 645.080296] [<ffffffff8163bcc2>] i915_gem_set_domain_ioctl+0x1a2/0x690 [ 645.080366] [<ffffffff811f8f85>] ? __might_fault+0x75/0xe0 [ 645.080433] [<ffffffff815a55f7>] drm_ioctl+0x327/0x640 [ 645.080508] [<ffffffff8163bb20>] ? i915_gem_obj_prepare_shmem_write+0x3a0/0x3a0 [ 645.080603] [<ffffffff815a52d0>] ? drm_ioctl_permit+0x120/0x120 [ 645.080670] [<ffffffff8110abdc>] ? check_chain_key+0x14c/0x210 [ 645.080738] [<ffffffff81275717>] do_vfs_ioctl+0x127/0xa20 [ 645.080804] [<ffffffff8120268c>] ? do_mmap+0x47c/0x580 [ 645.080871] [<ffffffff811da567>] ? vm_mmap_pgoff+0x117/0x140 [ 645.080938] [<ffffffff812755f0>] ? ioctl_preallocate+0x150/0x150 [ 645.081011] [<ffffffff81108c53>] ? up_write+0x23/0x50 [ 645.081078] [<ffffffff811da567>] ? vm_mmap_pgoff+0x117/0x140 [ 645.081145] [<ffffffff811da450>] ? vma_is_stack_for_current+0x90/0x90 [ 645.081214] [<ffffffff8110d853>] ? mark_held_locks+0x23/0xc0 [ 645.082030] [<ffffffff81288408>] ? __fget+0x168/0x250 [ 645.082106] [<ffffffff819ad517>] ? entry_SYSCALL_64_fastpath+0x5/0xb1 [ 645.082176] [<ffffffff81288592>] ? __fget_light+0xa2/0xc0 [ 645.082242] [<ffffffff8127604c>] SyS_ioctl+0x3c/0x70 [ 645.082309] [<ffffffff819ad52e>] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 645.082374] Object at ffff880233564200, in cache kmalloc-8192 size: 8192 [ 645.082431] Allocated: [ 645.082480] PID = 28408 [ 645.082535] [ 645.082566] [<ffffffff8103ae66>] save_stack_trace+0x16/0x20 [ 645.082623] [ 645.082656] [<ffffffff81228b06>] save_stack+0x46/0xd0 [ 645.082716] [ 645.082756] [<ffffffff812292fd>] kasan_kmalloc+0xad/0xe0 [ 645.082817] [ 645.082848] [<ffffffff81631752>] i915_ppgtt_create+0x52/0x220 [ 645.082908] [ 645.082941] [<ffffffff8161db96>] i915_gem_create_context+0x396/0x560 [ 645.083027] [ 645.083059] [<ffffffff8161f857>] i915_gem_context_create_ioctl+0x97/0xf0 [ 645.083152] [ 645.083183] [<ffffffff815a55f7>] drm_ioctl+0x327/0x640 [ 645.083243] [ 645.083274] [<ffffffff81275717>] do_vfs_ioctl+0x127/0xa20 [ 645.083334] [ 645.083372] [<ffffffff8127604c>] SyS_ioctl+0x3c/0x70 [ 645.083432] [ 645.083464] [<ffffffff819ad52e>] entry_SYSCALL_64_fastpath+0x1c/0xb1 [ 645.083551] Freed: [ 645.083599] PID = 27629 [ 645.083648] [ 645.083676] [<ffffffff8103ae66>] save_stack_trace+0x16/0x20 [ 645.083738] [ 645.083770] [<ffffffff81228b06>] save_stack+0x46/0xd0 [ 645.083830] [ 645.083862] [<ffffffff81229203>] kasan_slab_free+0x73/0xc0 [ 645.083922] [ 645.083961] [<ffffffff812279c9>] kfree+0xa9/0x170 [ 645.084021] [ 645.084053] [<ffffffff81629f60>] i915_ppgtt_release+0x100/0x180 [ 645.084139] [ 645.084171] [<ffffffff8161d414>] i915_gem_context_free+0x1b4/0x230 [ 645.084257] [ 645.084288] [<ffffffff816537b2>] intel_lr_context_unpin+0x192/0x230 [ 645.084380] [ 645.084413] [<ffffffff81645250>] i915_gem_request_retire+0x620/0x630 [ 645.084500] [ 645.085226] [<ffffffff816473d1>] i915_gem_retire_requests+0x181/0x280 [ 645.085313] [ 645.085352] [<ffffffff816352ba>] i915_gem_retire_work_handler+0xca/0xe0 [ 645.085440] [ 645.085471] [<ffffffff810c725b>] process_one_work+0x4fb/0x920 [ 645.085532] [ 645.085562] [<ffffffff810c770d>] worker_thread+0x8d/0x840 [ 645.085622] [ 645.085653] [<ffffffff810d21e5>] kthread+0x185/0x1b0 [ 645.085718] [ 645.085750] [<ffffffff819ad7a7>] ret_from_fork+0x27/0x40 [ 645.085811] Memory state around the buggy address: [ 645.085869] ffff880233564280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 645.085956] ffff880233564300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 645.086053] >ffff880233564380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 645.086138] ^ [ 645.086193] ffff880233564400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 645.086283] ffff880233564480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb v2: Add a comment to document the hint like nature of intel_engine_last_submit() Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline struct") Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161101100317.11129-1-chris@chris-wilson.co.uk
|
#
73cb9701 |
|
28-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Combine seqno + tracking into a global timeline struct Our timelines are more than just a seqno. They also provide an ordered list of requests to be executed. Due to the restriction of handling individual address spaces, we are limited to a timeline per address space but we use a fence context per engine within. Our first step to introducing independent timelines per context (i.e. to allow each context to have a queue of requests to execute that have a defined set of dependencies on other requests) is to provide a timeline abstraction for the global execution queue. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-23-chris@chris-wilson.co.uk
|
#
1353ec38 |
|
27-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Correct pipe fault reporting string Newline somehow ended up in the middle of the line. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1477572512-4030-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
5aa1ee4b |
|
12-Oct-2016 |
Akash Goel <akash.goel@intel.com> |
drm/i915: Add stats for GuC log buffer flush interrupts GuC firmware sends an interrupt to flush the log buffer when it becomes half full. GuC firmware also tracks how many times the buffer overflowed. It would be useful to maintain a statistics of how many flush interrupts were received and for which type of log buffer, along with the overflow count of each buffer type. Augmented i915_log_info debugfs to report back these statistics. v2: - Update the logic to detect multiple overflows between the 2 flush interrupts and also log a message for overflow (Tvrtko) - Track the number of times there was no free sub buffer to capture the GuC log buffer. (Tvrtko) v3: - Fix the printf field width for overflow counter, set it to 10 as per the max value of u32, which takes 10 digits in decimal form. (Tvrtko) v4: - Move the log buffer overflow handling to a new function for better readability. (Tvrtko) Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
4100b2ab |
|
12-Oct-2016 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Handle log buffer flush interrupt event from GuC GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state structure, once it has consumed the log buffer contents by copying them to a file or buffer. Even if Host couldn't copy the contents, it can still update the read pointer so that logging state is not disturbed on GuC side. v2: - Use a dedicated workqueue for handling flush interrupt. (Tvrtko) - Reduce the overall log buffer copying time by skipping the copy of crash buffer area for regular cases and copying only the state structure data in first page. v3: - Create a vmalloc mapping of log buffer. (Chris) - Cover the flush acknowledgment under rpm get & put.(Chris) - Revert the change of skipping the copy of crash dump area, as not really needed, will be covered by subsequent patch. v4: - Destroy the wq under the same condition in which it was created, pass dev_piv pointer instead of dev to newly added GuC function, add more comments & rename variable for clarity. (Tvrtko) v5: - Allocate & destroy the dedicated wq, for handling flush interrupt, from the setup/teardown routines of GuC logging. (Chris) - Validate the log buffer size value retrieved from state structure and do some minor cleanup. (Tvrtko) - Fix error/warnings reported by checkpatch. (Tvrtko) - Rebase. v6: - Remove the interrupts_enabled check from guc_capture_logs_work, need to process that last work item also, queued just before disabling the interrupt as log buffer flush interrupt handling is a bit different case where GuC is actually expecting an ACK from host, which should be provided to keep the logging going. Sync against the work will be done by caller disabling the interrupt. - Don't sample the log buffer size value from state structure, directly use the expected value to move the pointer & do the copy and that cannot go wrong (out of bounds) as Driver only allocated the log buffer and the relay buffers. Driver should refrain from interpreting the log packet, as much possible and let Userspace parser detect the anomaly. (Chris) v7: - Use switch statement instead of 'if else' for retrieving the GuC log buffer size. (Tvrtko) - Refactored the log buffer copying function and shortended the name of couple of variables for better readability. (Tvrtko) v8: - Make the dedicated wq as a high priority one to further reduce the turnaround time of handing log buffer flush event from GuC. Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
26705e20 |
|
12-Oct-2016 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Support for GuC interrupts There are certain types of interrupts which Host can receive from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel. This patch adds support to receive interrupts from GuC but currently enables & partially handles only the interrupt sent by GuC ukernel. Future patches will add support for handling other interrupt types. v2: - Use common low level routines for PM IER/IIR programming (Chris) - Rename interrupt functions to gen9_xxx from gen8_xxx (Chris) - Replace disabling of wake ref asserts with rpm get/put (Chris) v3: - Update comments for more clarity. (Tvrtko) - Remove the masking of GuC interrupt, which was kept masked till the start of bottom half, its not really needed as there is only a single instance of work item & wq is ordered. (Tvrtko) v4: - Rebase. - Rename guc_events to pm_guc_events so as to be indicative of the register/control block it is associated with. (Chris) - Add handling for back to back log buffer flush interrupts. v5: - Move the read & clearing of register, containing Guc2Host message bits, outside the irq spinlock. (Tvrtko) v6: - Move the log buffer flush interrupt related stuff to the following patch so as to do only generic bits in this patch. (Tvrtko) - Rebase. v7: - Remove the interrupts_enabled check from gen9_guc_irq_handler, want to process that last interrupt also before disabling the interrupt, sync against the work queued by irq handler will be done by caller disabling the interrupt. Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
f4e9af4f |
|
12-Oct-2016 |
Akash Goel <akash.goel@intel.com> |
drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set So far PM IER/IIR/IMR registers were being used only for Turbo related interrupts. But interrupts coming from GuC also use the same set. As a precursor to supporting GuC interrupts, added new low level routines so as to allow sharing the programming of PM IER/IIR/IMR registers between Turbo & GuC. Also similar to PM IMR, maintaining a bitmask for PM IER register, to allow easy sharing of it between Turbo & GuC without involving a rmw operation. v2: - For appropriateness & avoid any ambiguity, rename old functions enable/disable pm_irq to mask/unmask pm_irq and rename new functions enable/disable pm_interrupts to enable/disable pm_irq. (Tvrtko) - Use u32 in place of uint32_t. (Tvrtko) v3: - Rename the fields pm_irq_mask & pm_ier_mask and do some cleanup. (Chris) - Rebase. v4: Fix the inadvertent disabling of User interrupt for VECS ring causing failure for certain IGTs. v5: Use dev_priv with HAS_VEBOX macro. (Tvrtko) Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
eaa14c24 |
|
19-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Stop reporting error details in dmesg as well as the error-state As we already capture all the information from the registers into the error-state, also dumping that to dmesg just generates noise that upsets CI and users alike (and doesn't provide us with any more information). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20161019125203.28851-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
5db94019 |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_GEN macros only take dev_priv Saves 1416 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476352990-2504-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
55b8f2a7 |
|
14-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make INTEL_GEN only take dev_priv Saves 968 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) v3: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
3c9192bc |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make HAS_L3_DPF only take dev_priv Saves 472 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
e2d214ae |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_BROXTON only take dev_priv Saves 1392 bytes of .rodata strings. Also change a few function/macro prototypes in i915_gem_gtt.c from dev to dev_priv where it made more sense to do so. v2: Add parantheses around dev_priv. (Ville Syrjala) v3: Mention function prototype changes. (David Weinehall) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
|
#
772c2a51 |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make IS_HASWELL only take dev_priv Saves 2432 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
50a0bc90 |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make INTEL_DEVID only take dev_priv Saves 4472 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
6e266956 |
|
13-Oct-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Make INTEL_PCH_TYPE & co only take dev_priv This saves 1872 bytes of .rodata strings. v2: * Rebase. * Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
|
#
3b3f1650 |
|
13-Oct-2016 |
Akash Goel <akash.goel@intel.com> |
drm/i915: Allocate intel_engine_cs structure only for the enabled engines With the possibility of addition of many more number of rings in future, the drm_i915_private structure could bloat as an array, of type intel_engine_cs, is embedded inside it. struct intel_engine_cs engine[I915_NUM_ENGINES]; Though this is still fine as generally there is only a single instance of drm_i915_private structure used, but not all of the possible rings would be enabled or active on most of the platforms. Some memory can be saved by allocating intel_engine_cs structure only for the enabled/active engines. Currently the engine/ring ID is kept static and dev_priv->engine[] is simply indexed using the enums defined in intel_engine_id. To save memory and continue using the static engine/ring IDs, 'engine' is defined as an array of pointers. struct intel_engine_cs *engine[I915_NUM_ENGINES]; dev_priv->engine[engine_ID] will be NULL for disabled engine instances. There is a text size reduction of 928 bytes, from 1028200 to 1027272, for i915.o file (but for i915.ko file text size remain same as 1193131 bytes). v2: - Remove the engine iterator field added in drm_i915_private structure, instead pass a local iterator variable to the for_each_engine** macros. (Chris) - Do away with intel_engine_initialized() and instead directly use the NULL pointer check on engine pointer. (Chris) v3: - Remove for_each_engine_id() macro, as the updated macro for_each_engine() can be used in place of it. (Chris) - Protect the access to Render engine Fault register with a NULL check, as engine specific init is done later in Driver load sequence. v4: - Use !!dev_priv->engine[VCS] style for the engine check in getparam. (Chris) - Kill the superfluous init_engine_lists(). v5: - Cleanup the intel_engines_init() & intel_engines_setup(), with respect to allocation of intel_engine_cs structure. (Chris) v6: - Rebase. v7: - Optimize the for_each_engine_masked() macro. (Chris) - Change the type of 'iter' local variable to enum intel_engine_id. (Chris) - Rebase. v8: Rebase. v9: Rebase. v10: - For index calculation use engine ID instead of pointer based arithmetic in intel_engine_sync_index() as engine pointers are not contiguous now (Chris) - For appropriateness, rename local enum variable 'iter' to 'id'. (Joonas) - Use for_each_engine macro for cleanup in intel_engines_init() and remove check for NULL engine pointer in cleanup() routines. (Joonas) v11: Rebase. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476378888-7372-1-git-send-email-akash.goel@intel.com
|
#
86e83e35 |
|
07-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Merge duplicate gen4 and vlv/chv enable vblank callbacks gen4/vlv/chv all use the same bits in pipestat to enable the vblank interrupt, so they can share the same callbacks to enable/disable. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161007194953.15616-1-chris@chris-wilson.co.uk Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0e704476 |
|
12-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move common code out of i915_gpu_error.c In the next patch, I want to conditionally compile i915_gpu_error.c and that requires moving the functions used by debug out of i915_gpu_error.c! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161012090522.367-1-chris@chris-wilson.co.uk
|
#
27399eee |
|
03-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use correct index for backtracking HUNG semaphores When decoding the semaphores inside hangcheck, we need to use the hw-id and not the local array index. Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI ...") Testcase: igt/gem_exec_whisper/hang # gen6-7 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-3-chris@chris-wilson.co.uk (cherry picked from commit 348b9b1192144e13b779f8f9be301d492bebaff2) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
ac756941 |
|
21-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Restore current RPS state after reset Following commit 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") we no longer mark the context as lost on reset as we keep the requests (and contexts) alive. However, RPS remains reset and we need to restore the current state to match the in-flight requests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824 Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk (cherry picked from commit f2a91d1a6f5960c08f1ca60bd076f4dc020c50c6) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
348b9b11 |
|
03-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use correct index for backtracking HUNG semaphores When decoding the semaphores inside hangcheck, we need to use the hw-id and not the local array index. Fixes: de1add360522 ("drm/i915: Decouple execbuf uAPI ...") Testcase: igt/gem_exec_whisper/hang # gen6-7 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161003124516.12388-3-chris@chris-wilson.co.uk
|
#
f2a91d1a |
|
21-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Restore current RPS state after reset Following commit 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") we no longer mark the context as lost on reset as we keep the requests (and contexts) alive. However, RPS remains reset and we need to restore the current state to match the in-flight requests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824 Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
|
#
f9e61372 |
|
20-Sep-2016 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Try to print INSTDONE bits for all slice/subslice v2: (Imre) - Access only subslices that are known to exist. - Reset explicitly the MCR selector to slice/sub-slice ID 0 after the readout. - Use the subslice INSTDONE bits for the hangcheck/subunits-stuck detection too. - Take the uncore lock for the MCR-select/subslice-readout sequence. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474379673-28326-2-git-send-email-imre.deak@intel.com
|
#
d636951e |
|
20-Sep-2016 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Cleanup instdone collection Consolidate the instdone logic so we can get a bit fancier. This patch also removes the duplicated print of INSTDONE[0]. v2: (Imre) - Rebased on top of hangcheck INSTDONE changes. - Move all INSTDONE registers into a single struct, store it within the engine error struct during error capturing. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474379673-28326-1-git-send-email-imre.deak@intel.com
|
#
b20e3cfe |
|
12-Sep-2016 |
Dave Gordon <david.s.gordon@intel.com> |
drm/i915: clarify PMINTRMSK/pm_intr_keep usage No functional changes; just renaming a bit, tweaking a datatype, prettifying layout, and adding comments, in particular in the GuC setup code that touches this data. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473711577-11454-2-git-send-email-david.s.gordon@intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
32c2b4bd |
|
09-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid incrementing hangcheck whilst waiting for external fence If we are waiting upon an external fence, from the pov of hangcheck the engine is stuck on the last submitted seqno. Currently we give a small increment to the hangcheck score in order to catch a stuck waiter / driver. Now that we both have an independent wait hangcheck and may be stuck waiting on an external fence, resetting the GPU has little effect on that external fence. As we cannot advance by resetting, skip incrementing the hangcheck score. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-19-chris@chris-wilson.co.uk
|
#
80b5bdbd |
|
09-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Ignore valid but unknown semaphores If we find a ring waiting on a semaphore for another assigned but not yet emitted request, treat it as valid and waiting. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-18-chris@chris-wilson.co.uk
|
#
780f262a |
|
09-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace wait-on-mutex with wait-on-bit in reset worker Since we have a cooperative mode now with a direct reset, we can avoid the contention on struct_mutex and instead try then sleep on the I915_RESET_IN_PROGRESS bit. If the mutex is held and that bit is cleared, all is fine. Otherwise, we sleep for a bit and try again. In the worst case we sleep for an extra second waiting for the mutex to be released (no one touching the GPU is allowed the struct_mutex whilst the I915_RESET_IN_PROGRESS bit is set). But when we have a direct reset, this allows us to clean up the reset worker faster. v2: Remember to call wake_up_bit() after changing (for the faster wakeup as promised) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-12-chris@chris-wilson.co.uk
|
#
221fe799 |
|
09-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Perform a direct reset of the GPU from the waiter If a waiter is holding the struct_mutex, then the reset worker cannot reset the GPU until the waiter returns. We do not want to return -EAGAIN form i915_wait_request as that breaks delicate operations like i915_vma_unbind() which often cannot be restarted easily, and returning -EIO is just as useless (and has in the past proven dangerous). The remaining WARN_ON(i915_wait_request) serve as a valuable reminder that handling errors from an indefinite wait are tricky. We can keep the current semantic that knowing after a reset is complete, so is the request, by performing the reset ourselves if we hold the mutex. uevent emission is still handled by the reset worker, so it may appear slightly out of order with respect to the actual reset (and concurrent use of the device). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-11-chris@chris-wilson.co.uk
|
#
8af29b0c |
|
09-Sep-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Separate out reset flags from the reset counter In preparation for introducing a per-engine reset, we can first separate the mixing of the reset state from the global reset counter. The loss of atomicity in updating the reset state poses a small problem for handling the waiters. For requests, this is solved by advancing the seqno so that a waiter waking up after the reset knows the request is complete. For pending flips, we still rely on the increment of the global reset epoch (as well as the reset-in-progress flag) to signify when the hardware was reset. The advantage, now that we do not inspect the reset state during reset itself i.e. we no longer emit requests during reset, is that we can use the atomic updates of the state flags to ensure that only one reset worker is active. v2: Mika spotted that I transformed the i915_gem_wait_for_error() wakeup into a waiter wakeup. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470414607-32453-6-git-send-email-arun.siluvery@linux.intel.com Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160909131201.16673-7-chris@chris-wilson.co.uk
|
#
bafb0fce |
|
27-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Make for_each_engine_masked() more compact and quicker Rather than walk the full array of engines checking whether each is in the mask in turn, we can use the mask to jump to the right engines. This should quicker for a sparse array of engines or mask, whilst generating smaller code: text data bss dec hex filename 1251010 4579 800 1256389 132bc5 drivers/gpu/drm/i915/i915.ko 1250530 4579 800 1255909 1329e5 drivers/gpu/drm/i915/i915.ko The downside is that we have to pass in a temporary, alas no C99 iterators yet. [P.S. Joonas doesn't like having to pass extra temporaries into the macro, and even less that I called them tmp. As yet, we haven't found a macro that avoids passing in a temporary that is smaller. We probably will get C99 iterators first!] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160827075401.16470-2-chris@chris-wilson.co.uk
|
#
34730fed |
|
20-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Ignore stuck requests when considering hangs If the engine isn't being retired (worker starvation?) then it is possible for us to repeatedly observe that between consecutive hangchecks the seqno on the ring to be the same and there remain unretired requests. Ignore these completely and only regard the engine as busy for the purpose of hang detection (not stall detection) if there are outstanding breadcrumbs. In recent history we have looked at using both the request and seqno as indication of activity on the engine, but that was reduced to just inspecting seqno in commit cffa781e5907 ("drm/i915: Simplify check for idleness in hangcheck"). However, in commit dcff85c8443e ("drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex"), I made the decision to use the new common lockless function, under the assumption that request retirement was more frequent than hangcheck and so we would not have a stuck busy check. The flaw there was in forgetting that we accumulate the hang score, and so successive checks seeing a stuck request, albeit with the GPU advancing elsewhere and so not necessary the same stuck request, would eventually trigger the hang. Fixes: dcff85c8443e ("drm/i915: Enable i915_gem_wait_for_idle()...") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160820145408.32180-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
83348ba8 |
|
09-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from idle-worker") the racy detection of missed interrupts was removed when we went idle. This however opened up the issue that the stuck waiters were not being reported, causing a test case failure. If we move the stuck waiter detection out of hangcheck and into the breadcrumb mechanims (i.e. the waiter) itself, we can avoid this issue entirely. This leaves hangcheck looking for a stuck GPU (inspecting for request advancement and HEAD motion), and breadcrumbs looking for a stuck waiter - hopefully make both easier to understand by their segregation. v2: Reduce the error message as we now run independently of hangcheck, and the hanging batch used by igt also counts as a stuck waiter causing extra warnings in dmesg. v3: Move the breadcrumb's hangcheck kickstart to the first missed wait. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97104 Fixes: 2529d57050af (waiter"drm/i915: Drop racy markup of missed-irqs...") Testcase: igt/drv_missed_irq Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470761272-1245-2-git-send-email-chris@chris-wilson.co.uk
|
#
4194c088 |
|
03-Aug-2016 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Use drm official vblank_no_hw_counter callback. No functional change. Instead of defining a new empty function let's use what is available on drm. It gets cleaner, and easy to read, and understand. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
dcff85c8 |
|
05-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex The principal motivation for this was to try and eliminate the struct_mutex from i915_gem_suspend - but we still need to hold the mutex current for the i915_gem_context_lost(). (The issue there is that there may be an indirect lockdep cycle between cpu_hotplug (i.e. suspend) and struct_mutex via the stop_machine().) For the moment, enabling last request tracking for the engine, allows us to do busyness checking and waiting without requiring the struct_mutex - which is useful in its own right. As a side-effect of having a robust means for tracking engine busyness, we can replace our other busyness heuristic, that of comparing against the last submitted seqno. For paranoid reasons, we have a semi-ordered check of that seqno inside the hangchecker, which we can now improve to an ordered check of the engine's busyness (removing a locked xchg in the process). v2: Pass along "bool interruptible" as being unlocked we cannot rely on i915->mm.interruptible being stable or even under our control. v3: Replace check Ironlake i915_gpu_busy() with the common precalculated value Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-6-git-send-email-chris@chris-wilson.co.uk
|
#
7e37f889 |
|
02-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename struct intel_ringbuffer to struct intel_ring The state stored in this struct is not only the information about the buffer object, but the ring used to communicate with the hardware. Using buffer here is overly specific and, for me at least, conflates with the notion of buffer objects themselves. s/struct intel_ringbuffer/struct intel_ring/ s/enum intel_ring_hangcheck/enum intel_engine_hangcheck/ s/describe_ctx_ringbuf()/describe_ctx_ring()/ s/intel_ring_get_active_head()/intel_engine_get_active_head()/ s/intel_ring_sync_index()/intel_engine_sync_index()/ s/intel_ring_init_seqno()/intel_engine_init_seqno()/ s/ring_stuck()/engine_stuck()/ s/intel_cleanup_engine()/intel_engine_cleanup()/ s/intel_stop_engine()/intel_engine_stop()/ s/intel_pin_and_map_ringbuffer_obj()/intel_pin_and_map_ring()/ s/intel_unpin_ringbuffer()/intel_unpin_ring()/ s/intel_engine_create_ringbuffer()/intel_engine_create_ring()/ s/intel_ring_flush_all_caches()/intel_engine_flush_all_caches()/ s/intel_ring_invalidate_all_caches()/intel_engine_invalidate_all_caches()/ s/intel_ringbuffer_free()/intel_ring_free()/ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-15-git-send-email-chris@chris-wilson.co.uk Link: http://patchwork.freedesktop.org/patch/msgid/1470174640-18242-4-git-send-email-chris@chris-wilson.co.uk
|
#
9930ca1a |
|
27-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Update a couple of hangcheck comments to talk about engines We still have lots of comments that refer to the old ring when we mean struct intel_engine_cs and its hardware correspondence. This patch fixes an instance inside hangcheck to talk about engines. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1469432687-22756-10-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469606850-28659-5-git-send-email-chris@chris-wilson.co.uk
|
#
f2f0ed71 |
|
20-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename ring->virtual_start as ring->vaddr Just a different colour to better match virtual addresses elsewhere. s/ring->virtual_start/ring->vaddr/ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1469005202-9659-9-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1469017917-15134-8-git-send-email-chris@chris-wilson.co.uk
|
#
406ea8d2 |
|
20-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Treat ringbuffer writes as write to normal memory Ringbuffers are now being written to either through LLC or WC paths, so treating them as simply iomem is no longer adequate. However, for the older !llc hardware, the hardware is documentated as treating the TAIL register update as serialising, so we can relax the barriers when filling the rings (but even if it were not, it is still an uncached register write and so serialising anyway.). For simplicity, let's ignore the iomem annotation. v2: Remove iomem from ringbuffer->virtual_address v3: And for good measure add iomem elsewhere to keep sparse happy Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v2 Link: http://patchwork.freedesktop.org/patch/msgid/1469005202-9659-8-git-send-email-chris@chris-wilson.co.uk Link: http://patchwork.freedesktop.org/patch/msgid/1469017917-15134-7-git-send-email-chris@chris-wilson.co.uk
|
#
bc7135b9 |
|
01-Jul-2016 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Introduce Kabypoint PCH for Kabylake H/DT. Some Kabylake SKUs are going to use Kabypoint PCH. It is mainly for Halo and DT ones. >From our specs it doesn't seem that KBP brings any change on the display south engine. So let's consider this as a continuation of SunrisePoint, i.e., SPT+. Since it is easy to get confused by a letter change: KBL = Kabylake - CPU/GPU codename. KBP = Kabypoint - PCH codename. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96826 Link: http://patchwork.freedesktop.org/patch/msgid/1467418032-15167-1-git-send-email-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 22dea0be50b2eb0bafd3c82e1fb080113e0c889e) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
29ecd78d |
|
13-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Define a separate variable and control for RPS waitboost frequency To allow the user finer control over waitboosting, allow them to set the frequency we request for the boost. This also them allows to effectively disable the boosting by setting the boost request to a low frequency. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1468397438-21226-5-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
22dea0be |
|
01-Jul-2016 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Introduce Kabypoint PCH for Kabylake H/DT. Some Kabylake SKUs are going to use Kabypoint PCH. It is mainly for Halo and DT ones. >From our specs it doesn't seem that KBP brings any change on the display south engine. So let's consider this as a continuation of SunrisePoint, i.e., SPT+. Since it is easy to get confused by a letter change: KBL = Kabylake - CPU/GPU codename. KBP = Kabypoint - PCH codename. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96826 Link: http://patchwork.freedesktop.org/patch/msgid/1467418032-15167-1-git-send-email-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
aca34b6e |
|
05-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Group the irq breadcrumb variables into the same cacheline As we inspect both the tasklet (to check for an active bottom-half) and set the irq-posted flag at the same time (both in the interrupt handler and then in the bottom-halt), group those two together into the same cacheline. (Not having total control over placement of the struct means we can't guarantee the cacheline boundary, we need to align the kmalloc and then each struct, but the grouping should help.) v2: Try a couple of different names for the state touched by the user interrupt handler. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467805142-22219-3-git-send-email-chris@chris-wilson.co.uk
|
#
91c8a326 |
|
05-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert dev_priv->dev backpointers to dev_priv->drm Since drm_i915_private is now a subclass of drm_device we do not need to chase the drm_i915_private->dev backpointer and can instead simply access drm_i915_private->drm directly. text data bss dec hex filename 1068757 4565 416 1073738 10624a drivers/gpu/drm/i915/i915.ko 1066949 4565 416 1071930 105b3a drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ struct drm_i915_private *d; identifier i; @@ ( - d->dev->i + d->drm.i | - d->dev + &d->drm ) and for good measure the dev_priv->dev backpointer was removed entirely. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467711623-2905-4-git-send-email-chris@chris-wilson.co.uk
|
#
2b284288 |
|
04-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Clean up GPU hang message Remove some redundant kernel messages as we deduce a hung GPU and capture the error state. v2: Fix "hang" vs "no progress" message whilst I was there v3: s/snprintf/scnprintf/ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467618513-4966-2-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
b1379d49 |
|
05-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace lockless_dereference(bool) with READ_ONCE() After Joonas complained about using READ_ONCE() on the only use of the variable in the function, where the intent was to simply document that the read was intentionally racy and unlocked, I switched the READ_ONCE() over to lockless_dereference(). However, in linux-next that has a stronger type-check to only allow pointers and is no longer interchangeable with READ_ONCE(), see commit 331b6d8c7afc ("locking/barriers: Validate lockless_dereference() is used on a pointer type") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 67d97da34917 ("drm/i915: Only start retire worker when idle") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1467705276-707-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
|
#
fac5e23e |
|
04-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Mass convert dev->dev_private to to_i915(dev) Since we now subclass struct drm_device, we can save pointer dances by noting the equivalence of struct drm_device and struct drm_i915_private, i.e. by using to_i915(). text data bss dec hex filename 1073824 4562 416 1078802 107612 drivers/gpu/drm/i915/i915.ko 1068976 4562 416 1073954 106322 drivers/gpu/drm/i915/i915.ko Created by the coccinelle script: @@ expression E; identifier p; @@ - struct drm_i915_private *p = E->dev_private; + struct drm_i915_private *p = to_i915(E); Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467628477-25379-1-git-send-email-chris@chris-wilson.co.uk
|
#
c33d247d |
|
04-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Flush the RPS bottom-half when the GPU idles Make sure that the RPS bottom-half is flushed before we set the idle frequency when we decide the GPU is idle. This should prevent any races with the bottom-half and setting the idle frequency, and ensures that the bottom-half is bounded by the GPU's rpm reference taken for when it is active (i.e. between gen6_rps_busy() and gen6_rps_idle()). v2: Avoid recursively using the i915->wq - RPS does not touch the struct_mutex so has no place being on the ordered i915->wq. v3: Enable/disable interrupts for RPS busy/idle in order to prevent further HW access from RPS outside of the wakeref. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=89728 Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467616119-4093-6-git-send-email-chris@chris-wilson.co.uk
|
#
67d97da3 |
|
04-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only start retire worker when idle The retire worker is a low frequency task that makes sure we retire outstanding requests if userspace is being lax. We only need to start it once as it remains active until the GPU is idle, so do a cheap test before the more expensive queue_work(). A consequence of this is that we need correct locking in the worker to make the hot path of request submission cheap. To keep the symmetry and keep hangcheck strictly bound by the GPU's wakelock, we move the cancel_sync(hangcheck) to the idle worker before dropping the wakelock. v2: Guard against RCU fouling the breadcrumbs bottom-half whilst we kick the waiter. v3: Remove the wakeref assertion squelching (now we hold a wakeref for the hangcheck, any rpm error there is genuine). v4: To prevent excess work when retiring requests, we split the busy flag into two, a boolean to denote whether we hold the wakeref and a bitmask of active engines. v5: Reorder cancelling hangcheck upon idling to avoid a race where we might cancel a hangcheck after being preempted by a new task Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=88437 Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467616119-4093-1-git-send-email-chris@chris-wilson.co.uk
|
#
c5a7b5aa |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove debug noise on detecting fault-injection of missed interrupts Since the tests can and do explicitly check debugfs/i915_ring_missed_irqs for the handling of a "missed interrupt", adding it to the dmesg at INFO is just noise. When it happens for real, we still class it as an ERROR. Note that I have chose to remove it entirely because when we detect the "missed interrupt" is irrelevant and the message contains no more information than we glean from looking in debugfs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-20-git-send-email-chris@chris-wilson.co.uk
|
#
31bb59cc |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move the get/put irq locking into the caller With only a single callsite for intel_engine_cs->irq_get and ->irq_put, we can reduce the code size by moving the common preamble into the caller, and we can also eliminate the reference counting. For completeness, as we are no longer doing reference counting on irq, rename the get/put vfunctions to enable/disable respectively and are able to review the use of posting reads. We only require the serialisation with hardware when enabling the interrupt (i.e. so we cannot miss an interrupt by going to sleep before the hardware truly enables it). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-18-git-send-email-chris@chris-wilson.co.uk
|
#
3d5564e9 |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only apply one barrier after a breadcrumb interrupt is posted If we flag the seqno as potentially stale upon receiving an interrupt, we can use that information to reduce the frequency that we apply the heavyweight coherent seqno read (i.e. if we wake up a chain of waiters). v2: Use cmpxchg to replace READ_ONCE/WRITE_ONCE for more explicit control of the ordering wrt to interrupt generation and interrupt checking in the bottom-half. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-14-git-send-email-chris@chris-wilson.co.uk
|
#
f8973c21 |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Add a delay between interrupt and inspecting the final seqno (ilk) On Ironlake, there is no command nor register to ensure that the write from a MI_STORE command is completed (and coherent on the CPU) before the command parser continues. This means that the ordering between the seqno write and the subsequent user interrupt is undefined (like gen6+). So to ensure that the seqno write is completed after the final user interrupt we need to delay the read sufficiently to allow the write to complete. This delay is undefined by the bspec, and empirically requires 75us even though a register read combined with a clflush is less than 500ns. Hence, the delay is due to an on-chip buffer rather than the latency of the write to memory. Note that the render ring controls this by filling the PIPE_CONTROL fifo with stalling commands that force the earliest pipe-control with the seqno to be completed before the command parser continues. Given that we need a barrier operation for BSD, we may as well forgo the extra per-batch latency by using a common per-interrupt barrier. Studying the impact of adding the usleep shows that in both sequences of and individual synchronous no-op batches is negligible for the media engine (where the write now is unordered with the interrupt). Converting the render engine over from the current glutton of pie-controls over to the per-interrupt delays speeds up both the sequential and individual synchronous no-ops by 20% and 60%, respectively. This speed up holds even when looking at the throughput of small copies (4KiB->4MiB), both serial and synchronous, by about 20%. This is because despite adding a significant delay to the interrupt, in all likelihood we will see the seqno write without having to apply the barrier (only in the rare corner cases where the write is delayed on the last required is the delay necessary). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94307 Testcase: igt/gem_sync #ilk Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-12-git-send-email-chris@chris-wilson.co.uk
|
#
1b7744e7 |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use HWS for seqno tracking everywhere By using the same address for storing the HWS on every platform, we can remove the platform specific vfuncs and reduce the get-seqno routine to a single read of a cached memory location. v2: Fix semaphore_passed() to look at the signaling engine (not the waiter's) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-8-git-send-email-chris@chris-wilson.co.uk
|
#
688e6c72 |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Slaughter the thundering i915_wait_request herd One particularly stressful scenario consists of many independent tasks all competing for GPU time and waiting upon the results (e.g. realtime transcoding of many, many streams). One bottleneck in particular is that each client waits on its own results, but every client is woken up after every batchbuffer - hence the thunder of hooves as then every client must do its heavyweight dance to read a coherent seqno to see if it is the lucky one. Ideally, we only want one client to wake up after the interrupt and check its request for completion. Since the requests must retire in order, we can select the first client on the oldest request to be woken. Once that client has completed his wait, we can then wake up the next client and so on. However, all clients then incur latency as every process in the chain may be delayed for scheduling - this may also then cause some priority inversion. To reduce the latency, when a client is added or removed from the list, we scan the tree for completed seqno and wake up all the completed waiters in parallel. Using igt/benchmarks/gem_latency, we can demonstrate this effect. The benchmark measures the number of GPU cycles between completion of a batch and the client waking up from a call to wait-ioctl. With many concurrent waiters, with each on a different request, we observe that the wakeup latency before the patch scales nearly linearly with the number of waiters (before external factors kick in making the scaling much worse). After applying the patch, we can see that only the single waiter for the request is being woken up, providing a constant wakeup latency for every operation. However, the situation is not quite as rosy for many waiters on the same request, though to the best of my knowledge this is much less likely in practice. Here, we can observe that the concurrent waiters incur extra latency from being woken up by the solitary bottom-half, rather than directly by the interrupt. This appears to be scheduler induced (having discounted adverse effects from having a rbtree walk/erase in the wakeup path), each additional wake_up_process() costs approximately 1us on big core. Another effect of performing the secondary wakeups from the first bottom-half is the incurred delay this imposes on high priority threads - rather than immediately returning to userspace and leaving the interrupt handler to wake the others. To offset the delay incurred with additional waiters on a request, we could use a hybrid scheme that did a quick read in the interrupt handler and dequeued all the completed waiters (incurring the overhead in the interrupt handler, not the best plan either as we then incur GPU submission latency) but we would still have to wake up the bottom-half every time to do the heavyweight slow read. Or we could only kick the waiters on the seqno with the same priority as the current task (i.e. in the realtime waiter scenario, only it is woken up immediately by the interrupt and simply queues the next waiter before returning to userspace, minimising its delay at the expense of the chain, and also reducing contention on its scheduler runqueue). This is effective at avoid long pauses in the interrupt handler and at avoiding the extra latency in realtime/high-priority waiters. v2: Convert from a kworker per engine into a dedicated kthread for the bottom-half. v3: Rename request members and tweak comments. v4: Use a per-engine spinlock in the breadcrumbs bottom-half. v5: Fix race in locklessly checking waiter status and kicking the task on adding a new waiter. v6: Fix deciding when to force the timer to hide missing interrupts. v7: Move the bottom-half from the kthread to the first client process. v8: Reword a few comments v9: Break the busy loop when the interrupt is unmasked or has fired. v10: Comments, unnecessary churn, better debugging from Tvrtko v11: Wake all completed waiters on removing the current bottom-half to reduce the latency of waking up a herd of clients all waiting on the same request. v12: Rearrange missed-interrupt fault injection so that it works with igt/drv_missed_irq_hang v13: Rename intel_breadcrumb and friends to intel_wait in preparation for signal handling. v14: RCU commentary, assert_spin_locked v15: Hide BUG_ON behind the compiler; report on gem_latency findings. v16: Sort seqno-groups by priority so that first-waiter has the highest task priority (and so avoid priority inversion). v17: Add waiters to post-mortem GPU hang state. v18: Return early for a completed wait after acquiring the spinlock. Avoids adding ourselves to the tree if the is already complete, and skips the awkward question of why we don't do completion wakeups for waits earlier than or equal to ourselves. v19: Prepare for init_breadcrumbs to fail. Later patches may want to allocate during init, so be prepared to propagate back the error code. Testcase: igt/gem_concurrent_blit Testcase: igt/benchmarks/gem_latency Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: "Goel, Akash" <akash.goel@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> #v18 Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-6-git-send-email-chris@chris-wilson.co.uk
|
#
1f15b76f |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Separate GPU hang waitqueue from advance Currently __i915_wait_request uses a per-engine wait_queue_t for the dual purpose of waking after the GPU advances or for waking after an error. In the future, we may add even more wake sources and require greater separation, but for now we can conceptually simplify wakeups by separating the two sources. In particular, this allows us to use different wait-queues (e.g. one on the engine advancement, a global one for errors and one on each requests) without any hassle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-5-git-send-email-chris@chris-wilson.co.uk
|
#
26a02b8f |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Make queueing the hangcheck work inline Since the function is a small wrapper around schedule_delayed_work(), move it inline to remove the function call overhead for the principle caller. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-4-git-send-email-chris@chris-wilson.co.uk
|
#
77740025 |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove the dedicated hangcheck workqueue The queue only ever contains at most one item and has no special flags. It is just a very simple wrapper around the system-wq - a complication with no benefits. v2: Use the system_long_wq as we may wish to capture the error state after detecting the hang - which may take a bit of time. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-3-git-send-email-chris@chris-wilson.co.uk
|
#
05535726 |
|
01-Jul-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Delay queuing hangcheck to wait-request We can forgo queuing the hangcheck from the start of every request to until we wait upon a request. This reduces the overhead of every request, but may increase the latency of detecting a hang. However, if nothing every waits upon a hang, did it ever hang? It also improves the robustness of the wait-request by ensuring that the hangchecker is indeed running before we sleep indefinitely (and thereby ensuring that we never actually sleep forever waiting for a dead GPU). As pointed out by Tvrtko, it is possible for a GPU hang to go unnoticed for as long as nobody is waiting for the GPU. Though this rare, during that time we may be consuming more power than if we had promptly recovered, and in the most extreme case we may exhaust all memory before forcing the hangcheck. Something to be wary off in future. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467390209-3576-2-git-send-email-chris@chris-wilson.co.uk
|
#
14bb2c11 |
|
03-Jun-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Fix a buch of kerneldoc warnings Just a bunch of stale kerneldocs generating warnings when building the docs. Mostly function parameters so not very useful but still. v2: Tidy. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464958937-23344-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
e42aeef1 |
|
24-May-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Revert async unpin and nonblocking atomic commit This reverts the following patches: d55dbd06bb5e1399aba9ab5227465339d1bbefff drm/i915: Allow nonblocking update of pageflips. 15c86bdb760185e871c7a0f559978328aa500971 drm/i915: Check for unpin correctness. 95c2ccdc82d520f59ae3b6fdc097b63c9b7082bb Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" a6747b7304a9d66758a196d885dab8bbfa5e7d1f drm/i915: Make unpin async. 03f476e1fcb42fca88fc50b94b0d3adbdbe887f0 drm/i915: Prepare connectors for nonblocking checks. 2099deffef4404f949ba1b68d2b17e0608190bc2 drm/i915: Pass atomic states to fbc update functions. ee7171af72c39c18b7d7571419a4ac6ca30aea66 drm/i915: Remove reset_counter from intel_crtc. 2ee004f7c59b2e642f0bb2834f847d756f2dd7b7 drm/i915: Remove queue_flip pointer. b8d2afae557dbb9b9c7bc6f6ec4f5278f3c4c34e drm/i915: Remove use_mmio_flip kernel parameter. 8dd634d922615ec3a9af7976029110ec037f8b50 drm/i915: Remove cs based page flip support. 143f73b3bf48c089b40f58462dd7f7c199fd4f0f drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3. 84fc494b64e8c591be446a966b7447a9db519c88 drm/i915: Add the exclusive fence to plane_state. 6885843ae164e11f6c802209d06921e678a3f3f3 drm/i915: Convert flip_work to a list. aa420ddd8eeaa5df579894a412289e4d07c2fee9 drm/i915: Allow mmio updates on all platforms, v2. afee4d8707ab1f21b7668de995be3a5961e83582 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates" "drm/i915: Allow nonblocking update of pageflips" should have been split up, misses a proper commit message and seems to cause issues in the legacy page_flip path as demonstrated by kms_flip. "drm/i915: Make unpin async" doesn't handle the unthrottled cursor updates correctly, leading to an apparent pin count leak. This is caught by the WARN_ON in i915_gem_object_do_pin which screams if we have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins. Unfortuantely we can't just revert these two because this patch series came with a built-in bisect breakage in the form of temporarily removing the unthrottled cursor update hack for legacy cursor ioctl. Therefore there's no other option than to revert the entire pile :( There's one tiny conflict in intel_drv.h due to other patches, nothing serious. Normally I'd wait a bit longer with doing a maintainer revert, but since the minimal set of patches we need to revert (due to the bisect breakage) is so big, time is running out fast. And very soon (especially after a few attempts at fixing issues) it'll be really hard to revert things cleanly. Lessons learned: - Not a good idea to rush the review (done by someone fairly new to the area) and not make sure domain experts had a chance to read it. - Patches should be properly split up. I only looked at the two patches that should be reverted in detail, but both look like the mix up different things in one patch. - Patches really should have proper commit messages. Especially when doing more than one thing, and especially when touching critical and tricky core code. - Building a patch series and r-b stamping it when it has a built-in bisect breakage is not a good idea. - I also think we need to stop building up technical debt by postponing atomic igt testcases even longer. I think it's clear that there's enough corner cases in this beast that we really need to have the testcases _before_ the next step lands. (cherry picked from commit 5a21b6650a239ebc020912968a44047701104159 from drm-intel-next-queeud) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
1800ad25 |
|
31-May-2016 |
Sagar Arun Kamble <sagar.a.kamble@intel.com> |
drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled On Loading, GuC sets PM interrupts routing (bit 31) and clears ARAT expired interrupt (bit 9). Host turbo also updates this register in RPS flows. This patch ensures bit 31 and bit 9 setup by GuC persists. ARAT timer interrupt is needed in GuC for various features. It also facilitates halting GuC and hence achieving RC6. PM interrupt routing will not impact RPS interrupt reception by host as GuC will redirect them. This patch fixes igt test pm_rc6_residency that was failing with guc load/submission enabled. Tested with SKL GuC v6.1 and BXT GuC v5.1 and v8.7. v2: i915_irq/i915_pm decoupling from intel_guc. (ChrisW) v3: restructuring the mask update and rebase w.r.t Ville's patch. (ChrisW) v4: Updating the pm_intr_keep during direct_interrupts_to_guc. (Sagar) Cc: Chris Harris <chris.harris@intel.com> Cc: Zhe Wang <zhe1.wang@intel.com> Cc: Deepak S <deepak.s@intel.com> Cc: Satyanantha, Rama Gopal M <rama.gopal.m.satyanantha@intel.com> Cc: Akash Goel <akash.goel@intel.com> Testcase: igt/pm_rc6_residency Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Tested-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1464683307-19475-1-git-send-email-sagar.a.kamble@intel.com
|
#
5a21b665 |
|
24-May-2016 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Revert async unpin and nonblocking atomic commit This reverts the following patches: d55dbd06bb5e1399aba9ab5227465339d1bbefff drm/i915: Allow nonblocking update of pageflips. 15c86bdb760185e871c7a0f559978328aa500971 drm/i915: Check for unpin correctness. 95c2ccdc82d520f59ae3b6fdc097b63c9b7082bb Reapply "drm/i915: Avoid stalling on pending flips for legacy cursor updates" a6747b7304a9d66758a196d885dab8bbfa5e7d1f drm/i915: Make unpin async. 03f476e1fcb42fca88fc50b94b0d3adbdbe887f0 drm/i915: Prepare connectors for nonblocking checks. 2099deffef4404f949ba1b68d2b17e0608190bc2 drm/i915: Pass atomic states to fbc update functions. ee7171af72c39c18b7d7571419a4ac6ca30aea66 drm/i915: Remove reset_counter from intel_crtc. 2ee004f7c59b2e642f0bb2834f847d756f2dd7b7 drm/i915: Remove queue_flip pointer. b8d2afae557dbb9b9c7bc6f6ec4f5278f3c4c34e drm/i915: Remove use_mmio_flip kernel parameter. 8dd634d922615ec3a9af7976029110ec037f8b50 drm/i915: Remove cs based page flip support. 143f73b3bf48c089b40f58462dd7f7c199fd4f0f drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3. 84fc494b64e8c591be446a966b7447a9db519c88 drm/i915: Add the exclusive fence to plane_state. 6885843ae164e11f6c802209d06921e678a3f3f3 drm/i915: Convert flip_work to a list. aa420ddd8eeaa5df579894a412289e4d07c2fee9 drm/i915: Allow mmio updates on all platforms, v2. afee4d8707ab1f21b7668de995be3a5961e83582 Revert "drm/i915: Avoid stalling on pending flips for legacy cursor updates" "drm/i915: Allow nonblocking update of pageflips" should have been split up, misses a proper commit message and seems to cause issues in the legacy page_flip path as demonstrated by kms_flip. "drm/i915: Make unpin async" doesn't handle the unthrottled cursor updates correctly, leading to an apparent pin count leak. This is caught by the WARN_ON in i915_gem_object_do_pin which screams if we have more than DRM_I915_GEM_OBJECT_MAX_PIN_COUNT pins. Unfortuantely we can't just revert these two because this patch series came with a built-in bisect breakage in the form of temporarily removing the unthrottled cursor update hack for legacy cursor ioctl. Therefore there's no other option than to revert the entire pile :( There's one tiny conflict in intel_drv.h due to other patches, nothing serious. Normally I'd wait a bit longer with doing a maintainer revert, but since the minimal set of patches we need to revert (due to the bisect breakage) is so big, time is running out fast. And very soon (especially after a few attempts at fixing issues) it'll be really hard to revert things cleanly. Lessons learned: - Not a good idea to rush the review (done by someone fairly new to the area) and not make sure domain experts had a chance to read it. - Patches should be properly split up. I only looked at the two patches that should be reverted in detail, but both look like the mix up different things in one patch. - Patches really should have proper commit messages. Especially when doing more than one thing, and especially when touching critical and tricky core code. - Building a patch series and r-b stamping it when it has a built-in bisect breakage is not a good idea. - I also think we need to stop building up technical debt by postponing atomic igt testcases even longer. I think it's clear that there's enough corner cases in this beast that we really need to have the testcases _before_ the next step lands. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
11825b0d |
|
18-May-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable GSE interrupt on BDW+ We've never actually enabled or unmasked the GSE interrupt on BDW+, even though the interrupt handler was always prepared for it. Let's enable it and see what happens. Credit to Mark Kettenis who fixed this in the OpenBSD fork of the driver. He reports that it fixed the "ACPI _BCM/_BCQ-based brightness mechanism on a MacBookPro12,1 and a 3rd gen Lenovo X1 Carbon" for them. Mark says: "FWIW, this *is* needed if you want ACPI-based backlight control to work. On Linux you probably don't notice, since "hardware" backlight control is preferred over "firmware" or "platform" backlight control. It would help me if this did land in the Linux tree though, as it will make future imports of the i915 driver into OpenBSD easier." So even though we don't really need this, let's put it in to help Mark with future porting efforts. Should be harmless to have it enabled in any case. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/081799.html Reported-by: Mark Kettenis <mark.kettenis@xs4all.nl> Cc: Mark Kettenis <mark.kettenis@xs4all.nl> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463649283-28698-1-git-send-email-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
8dd634d9 |
|
17-May-2016 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Remove cs based page flip support. With mmio flips now available on all platforms it's time to remove support for cs flips. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-13-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
|
#
51cbaf01 |
|
17-May-2016 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Unify unpin_work and mmio_work into flip_work, v2. Rename intel_unpin_work to intel_flip_work and use it for mmio flips and unpinning. Use flip_queued_req to hold the wait request in the mmio case, and the vblank counter from intel_crtc_get_vblank_counter. MMIO flips get their own path through intel_finish_page_flip_mmio, handled on vblank. CS page flips go through *_cs. Changes since v1: - Clean up destinction between MMIO and CS flips. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-7-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
|
#
5251f04e |
|
17-May-2016 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Remove intel_prepare_page_flip, v3. Instead of calling prepare_flip right before calling finish_page_flip do everything from prepare_page_flip in finish_page_flip. Putting prepare and finish page_flip in a single step removes the need for INTEL_FLIP_COMPLETE, so it can be removed. This simplifies the code slightly. Changes since v1: - Invert if case to simplify code. - Add missing barrier. - Reword commit message. Changes since v2: - intel_page_flip_plane is removed. - work->pending is turned into a bool. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-5-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
|
#
ef58319d |
|
17-May-2016 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Remove intel_finish_page_flip_plane. This function is duplicated with intel_finish_page_flip, and is only ever used from planes that could use the other function anyway. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463490484-19540-4-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
|
#
7e22dbbb |
|
10-May-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx This way optimization from a previous patch works even better. v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
dc97997a |
|
10-May-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use drm_i915_private as the native pointer for intel_uncore.c Pass drm_i915_private to the uncore init/fini routines and their subservients as it is their native type. text data bss dec hex filename 6309978 3578778 696320 10585076 a183f4 vmlinux 6309530 3578778 696320 10584628 a18234 vmlinux a modest 400 bytes of saving, but 60 lines of code deleted! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462885804-26750-1-git-send-email-chris@chris-wilson.co.uk
|
#
c033666a |
|
06-May-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Store a i915 backpointer from engine, and use it text data bss dec hex filename 6309351 3578714 696320 10584385 a18141 vmlinux 6308391 3578714 696320 10583425 a17d81 vmlinux Almost 1KiB of code reduction. v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions text data bss dec hex filename 6304579 3578778 696320 10579677 a16edd vmlinux 6303427 3578778 696320 10578525 a16a5d vmlinux Now over 1KiB! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
|
#
91d14251 |
|
06-May-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Small display interrupt handlers tidy I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away with only dev_priv in the huge majority of cases. Tidying that up had a cascading effect on changing functions prototypes, so relatively big churn factor, but I think it is for the better. For example even where changes cascade out of i915_irq.c, for functions prefixed with intel_, genX_ or <plat>_, it makes more sense to take dev_priv directly anyway. This allows us to eliminate local variables and intermixed usage of dev and dev_priv where only one is good enough. End result is shrinkage of both source and the resulting binary. i915.ko: - .text 000b0899 + .text 000b0619 Or if we look at the Gen8 display irq chain: -00000000000006ad t gen8_irq_handler +0000000000000663 t gen8_irq_handler -0000000000000028 T intel_opregion_asle_intr +0000000000000024 T intel_opregion_asle_intr -000000000000008c t ilk_hpd_irq_handler +000000000000007f t ilk_hpd_irq_handler -0000000000000116 T intel_check_page_flip +0000000000000112 T intel_check_page_flip -000000000000011a T intel_prepare_page_flip +0000000000000119 T intel_prepare_page_flip -0000000000000014 T intel_finish_page_flip_plane +0000000000000013 T intel_finish_page_flip_plane -0000000000000053 t hsw_pipe_crc_irq_handler +000000000000004c t hsw_pipe_crc_irq_handler -000000000000022e t cpt_irq_handler +0000000000000213 t cpt_irq_handler So small shrinkage but it is all fast paths so doesn't harm. Situation is similar in other interrupt handlers as well. v2: Tidy intel_queue_rps_boost_for_request as well. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
98735739 |
|
19-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist Looks like DPF was not implemented for gen8+ but the IER and IMR are still enabled on initialization. Since there is no code to handle this interrupt, gate the irq enablement behind HAS_L3_DPF in case the feature gets enabled in the future. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
e30e251a |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split gen8_gt_irq_handler into ack+handle As we did on VLV, split the gt irq handling to ack and handler phases on CHV. Leave the BDW+ codepath mostly intact for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
261e40b8 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Eliminate passing dev+dev_priv to {snb,ilk}_gt_irq_handler() It looks silly to pass both dev and dev_priv to the snb/ilk gt irq handlers. Just pass dev_priv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
52894874 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move gt/pm irq handling out from irq disabled section on VLV No need to actually handle the GT/PM interrupt while we have interrupt sources disabled. Move the actual processing to happen after we've restored VLV_IER and master interrupt enable. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
2ecb8ca4 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split VLV/CVH PIPESTAT handling into ack+handler Minimize the amount of stuff we do with interrupt sources disabled by splitting the PIPESTAT irq handling into ack+handler phases. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
1ae3c34c |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split PORT_HOTPLUG_STAT ack out from i9xx_hpd_irq_handler() Split the VLV/CHV hoplug irq handling to ack and handler phases. This way we can move the actual irq handling outside the section where we have disabled the interrupt sources. For now, we leave things as is for pre-VLV GMCH platforms, but eventually they could get the same treatment. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
6e814800 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move variables to narrower scope in VLV/CHV irq handlers Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
1e1cace9 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Eliminate loop from VLV irq handler Now that we've dealt with the races in clearing IIR bits via VLV_IER and the master interrupt enable, we can go ahead aliminate the loop from the VLV interrupt handler. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a5e485a9 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clear VLV_IER around irq processing On VLV/CHV the master interrupt enable bit only affects GT/PM interrupts. Display interrupts are not affected by the master irq control. Also it seems that the CPU interrupt will only be generated when the combined result of all GT/PM/display interrupts has a 0->1 edge. We already use the master interrupt enable bit to make sure GT/PM interrupt can generate such an edge if we don't end up clearing all IIR bits. We must do the same for display interrupts, and for that we can simply clear out VLV_IER, and restore after we've acked all the interrupts we are about to process. So with both master interrupt enable and VLV_IER cleared out, we will guarantee that there will be a 0->1 edge if any IIR bits are still set at the end, and thus another CPU interrupt will be generated. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 579de73b048a ("drm/i915: Exit cherryview_irq_handler() after one pass") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
4a0a0202 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clear VLV_MASTER_IER around irq processing Like on CHV, let's clear out the master irq enable bit when we ack GT/PM interrupts. This will allow GT/PM interrupts to re-raise the CPU interrupt if we fail to clear all the bits from the IIR(s). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
7ce4d1f2 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clear VLV_IIR after PIPESTAT On VLV/CHV VLV_IIR is not double double buffered, and it doesn't detect edges from PIPESTAT & co. like it does on gen4. Instead it just directly latches the level from PIPESTAT & co. That means we must clear VLV_IIR after PIPESTAT & co. or else we'll get a spurious bit in VLV_IIR every single time. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
34c7b8a7 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Set up VLV_MASTER_IER consistently We're lacking VLV_MASTER_IER setup from valleyview_irq_preinstall(), so add it there. Also cargo cult in some POSTING_READ()s to match the other platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e5328c43 |
|
13-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use GEN8_MASTER_IRQ_CONTROL consistently Use GEN8_MASTER_IRQ_CONTROL instead of DE_MASTER_IRQ_CONTROL or MASTER_INTERRUPT_ENABLE with the GEN8_MASTER_IRQ register. They're all bit 31 so there's no actual bug here, but let's be consistent which name we use for the bit. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460571598-24452-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
d98c52cf |
|
13-Apr-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Tighten reset_counter for reset status In the reset_counter, we use two bits to track a GPU hang and reset. The low bit is a "reset-in-progress" flag that we set to signal when we need to break waiters in order for the recovery task to grab the mutex. As soon as the recovery task has the mutex, we can clear that flag (which we do by incrementing the reset_counter thereby incrementing the gobal reset epoch). By clearing that flag when the recovery task holds the struct_mutex, we can forgo a second flag that simply tells GEM to ignore the "reset-in-progress" flag. The second flag we store in the reset_counter is whether the reset failed and we consider the GPU terminally wedged. Whilst this flag is set, all access to the GPU (at least through GEM rather than direct mmio access) is verboten. PS: Fun is in store, as in the future we want to move from a global reset epoch to a per-engine reset engine with request recovery. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-6-git-send-email-chris@chris-wilson.co.uk
|
#
c19ae989 |
|
13-Apr-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Hide the atomic_read(reset_counter) behind a helper This is principally a little bit of syntatic sugar to hide the atomic_read()s throughout the code to retrieve the current reset_counter. It also provides the other utility functions to check the reset state on the already read reset_counter, so that (in later patches) we can read it once and do multiple tests rather than risk the value changing between tests. v2: Be more strict on converting existing i915_reset_in_progress() over to the more verbose i915_reset_in_progress_or_wedged(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-4-git-send-email-chris@chris-wilson.co.uk
|
#
71b8b41d |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move DPINVGTT setup to vlv_display_irq_reset() DPINVGTT lives inside the disp2d power well so we can't frob it unless we know the power well is active. Let's this stuff into vlv_display_irq_reset() which is only called at the right times so that we don't get unclaimed register access errors. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
6b7eafc1 |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Warn if irq_mask isn't ~0 during vlv/cvh display irq postinstall We expect vlv_display_irq_reset() to have been called prior to vlv_display_irq_postinstall() so let's WARN if that isn't the case. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
9ab981f2 |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use GEN5_IRQ_INIT() in vlv_display_irq_postinstall() Replace the hand rolled IMR/IER setup in vlv_display_irq_postinstall() with GEN5_IRQ_INIT(). Also rename the iir_mask to enable_mask to avoid consusion since we no longer deal with IIR here. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-7-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
d6c69803 |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clear display interrupt before enabling when turning on the power well For a bit of extra paranoia make sure the display irqs are all cleared before we enabled them when turning on the power well. This should really be the case already since the power well was off which resets everything. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
8bb61306 |
|
12-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move vlv/chv display irq code to a more logical place Reshuffle the code a bit to move the vlv/chv display irq functions away from the main irq hooks, next to the other sub (de,gt,etc.) hooks. v2: Rebased due to changes in vlv_display_irq_reset() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460476604-2035-1-git-send-email-ville.syrjala@linux.intel.com
|
#
9918271e |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Skip display irq setup if display irqs aren't flagged as enabled During runtime PM we'll be reinitializing interrupt support from the ground up. However since the display power well will be off at that time, well end up with a ton of unclaimed register accesses from the display irq setup. Since we turned off the power well already before runtime suspend, we've flagged display irqs as disabled during runtime PM transitions. So we can just check that flag to see if we should do skip display irqs during irq setup. During driver load display irqs will be flagged as enabled since we've turned on the power well already, however the power well code will have skipped the display irq setup since irq support as a whole wasn't yet enabled when the power well was enabled. So we'll want to do the display irq setup in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94164 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
ad22d106 |
|
12-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix up vlv/chv display irq setup The vlv/chv display irq setup was a bit of mess after I ran out of steam when working on it last. Fix it up so that we just have a _reset() and _postinstall() hooks for the display irqs, and use those consistently. v2: Clear out pipestat_irq_mask[] and PIPE_FIFO_UNDERRUN_STATUS in vlv_display_irq_reset() (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1460476574-1921-1-git-send-email-ville.syrjala@linux.intel.com
|
#
93de68f9 |
|
11-Apr-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove "VLV magic" from irq setup No clue what this is supposed to achieve. I think it's been there since the very beginning, so presumably some kind of kludge for very early silicon. Let's just throw it out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460382992-28728-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
12471ba8 |
|
09-Apr-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Harden detection of missed interrupts Only declare a missed interrupt if we find that the GPU is idle with waiters and a hangcheck interval has passed in which no new user interrupts have been raised. v2: Clear the stuck interrupt marker between successful batches Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-3-git-send-email-chris@chris-wilson.co.uk
|
#
c04e0f3b |
|
09-Apr-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Separate out the seqno-barrier from engine->get_seqno In order to simplify future patches, extract the lazy_coherency optimisation our of the engine->get_seqno() vfunc into its own callback. v2: Rename the barrier to engine->irq_seqno_barrier to try and better reflect that the barrier is only required after the user interrupt before reading the seqno (to ensure that the seqno update lands in time as we do not have strict seqno-irq ordering on all platforms). Reviewed-by: Dave Gordon <david.s.gordon@intel.com> [#v2] v3: Comments for hangcheck paranoia. Mika wanted to keep the extra barrier inside the hangcheck, just in case. I can argue that it doesn't provide a barrier against anything, but the side-effects of applying the barrier may prevent a false declaration of a hung GPU. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460195877-20520-2-git-send-email-chris@chris-wilson.co.uk
|
#
cffa781e |
|
07-Apr-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Simplify check for idleness in hangcheck Having fixed the tracking of the engine's last_submitted_seqno, we can now rely on it for detecting when the engine is idle (and not have to touch the requests pointer). Testcase: igt/gem_exec_whisper Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-9-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
7c90b7de |
|
07-Apr-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Apply a mb between emitting the request and hangcheck Seal the request and mark it as pending execution before we submit it to hardware. We assume that the actual submission cannot fail (that guarantee is provided by preallocating space in the request for the submission). As we may inspect this state without holding any locks during hangcheck we should apply a barrier to ensure that we do not see a more recent value in the HWS than we are tracking. Based on a patch by Mika Kuoppala. Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460010558-10705-8-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
|
#
2d1fe073 |
|
07-Apr-2016 |
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
drm/i915: Do not use {HAS_*, IS_*, INTEL_INFO}(dev_priv->dev) dev_priv is what the macro works hard to extract, pass it directly. > sed 's/\([A-Z].*(dev_priv\)->dev)/\1)/g' v2: - Include all wrapper macros too (Chris) v3: - Include sed cmdline (Chris) v4: - Break long line - Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460016485-8089-1-git-send-email-joonas.lahtinen@linux.intel.com
|
#
d252bf68 |
|
31-Mar-2016 |
Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> |
drm/i915: Set invert bit for hpd based on VBT This patch sets the invert bit for hpd detection for each port based on VBT configuration. Since each AOB can be designed to depend on invert bit or not, it is expected if an AOB requires invert bit, the user will set respective bit in VBT. v2: Separated VBT parsing from the rest of the logic. (Jani) v3: Moved setting invert bit logic to bxt_hpd_irq_setup() and changed its logic to avoid looping twice. (Ville) v4: Changed the logic to mask out the bits first and then set them to remove need of temporary variable. (Ville) v5: Moved defines to existing set of defines for the register and added required breaks. (Ville) Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [Jani: fixed some checkpatch noise, added kernel-doc.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459420907-11383-2-git-send-email-shubhangi.shrivastava@intel.com
|
#
9dbaab56 |
|
14-Mar-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Exit cherryview_irq_handler() after one pass This effectively reverts commit 8e5fd599eb219f1054e39b40d18b217af669eea9 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Apr 9 13:28:50 2014 +0300 drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed as under continuous execlists load we can saturate the IRQ handler, destablising the tsc clock and triggering the NMI watchdog to declare a hung CPU. [ 552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 552.756080] clocksource: 'refined-jiffies' wd_now: 10003b480 wd_last: 10003b28c mask: ffffffff [ 552.756091] clocksource: 'tsc' cs_now: d55d31aa50 cs_last: d17446166c mask: ffffffffffffffff [ 552.756210] clocksource: Switched to clocksource refined-jiffies [ 575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 [ 575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18 [ 575.217905] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 575.217915] 0000000000000000 ffff88027fd05bc0 ffffffff81288c6d 0000000000000000 [ 575.217935] 0000000000000001 ffff88027fd05be0 ffffffff810e72d1 0000000000000000 [ 575.217951] ffff88027fd05c80 ffff88027fd05c20 ffffffff81114b60 0000000181015f1e [ 575.217967] Call Trace: [ 575.217973] <NMI> [<ffffffff81288c6d>] dump_stack+0x4f/0x72 [ 575.217994] [<ffffffff810e72d1>] watchdog_overflow_callback+0x151/0x160 [ 575.218003] [<ffffffff81114b60>] __perf_event_overflow+0xa0/0x1e0 [ 575.218016] [<ffffffff811154c4>] perf_event_overflow+0x14/0x20 [ 575.218028] [<ffffffff8101d2ca>] intel_pmu_handle_irq+0x1da/0x460 [ 575.218042] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218052] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218064] [<ffffffff81014ae8>] perf_event_nmi_handler+0x28/0x50 [ 575.218075] [<ffffffff81007540>] nmi_handle+0x60/0x130 [ 575.218086] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218096] [<ffffffff810079c0>] do_nmi+0x140/0x470 [ 575.218108] [<ffffffff81559ec7>] end_repeat_nmi+0x1a/0x1e [ 575.218119] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218129] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218139] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218148] <<EOE>> [<ffffffff814a8353>] cpuidle_enter_state+0xf3/0x2f0 [ 575.218164] [<ffffffff814a8587>] cpuidle_enter+0x17/0x20 [ 575.218175] [<ffffffff810aaa3a>] call_cpuidle+0x2a/0x40 [ 575.218185] [<ffffffff810aade3>] cpu_startup_entry+0x273/0x330 [ 575.218196] [<ffffffff81033a1e>] start_secondary+0x10e/0x130 However, not servicing all available IIR within the handler does hurt the throughput of pathological nop execbuf by about 20%, with a similar effect upon the dispatch latency of a series of execbuf. v2: use do {} while(0) for a smaller patch, and easier to revert again I have reasonable confidence that we do not miss GT interrupts (as execlists provides a stress case with a failure mechanism easily detected by igt), however I have less confidence about all the other sources of interrupts and worry that may lose a display hotplug interrupt, for example. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467 Testcase: igt/gem_exec_nop/basic # requires NMI watchdog Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Antti Koskipää <antti.koskipaa@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457946117-6714-1-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 579de73b048a0a4c66c25a033ac76a2836e0cf73) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
27af5eea |
|
03-Apr-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Move execlists irq handler to a bottom half Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole system can be brought into multi-second periods of complete non-interactivty. That can look for example like this: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] Modules linked in: [redacted for brevity] CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ #183 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1 Workqueue: i915 gen6_pm_rps_work [i915] task: ffff8800aae88000 ti: ffff8800aae90000 task.ti: ffff8800aae90000 RIP: 0010:[<ffffffff8104a3c2>] [<ffffffff8104a3c2>] __do_softirq+0x72/0x1d0 RSP: 0000:ffff88014f403f38 EFLAGS: 00000206 RAX: ffff8800aae94000 RBX: 0000000000000000 RCX: 00000000000006e0 RDX: 0000000000000020 RSI: 0000000004208060 RDI: 0000000000215d80 RBP: ffff88014f403f80 R08: 0000000b1b42c180 R09: 0000000000000022 R10: 0000000000000004 R11: 00000000ffffffff R12: 000000000000a030 R13: 0000000000000082 R14: ffff8800aa4d0080 R15: 0000000000000082 FS: 0000000000000000(0000) GS:ffff88014f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa53b90c000 CR3: 0000000001a0a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: 042080601b33869f ffff8800aae94000 00000000fffc2678 ffff88010000000a 0000000000000000 000000000000a030 0000000000005302 ffff8800aa4d0080 0000000000000206 ffff88014f403f90 ffffffff8104a716 ffff88014f403fa8 Call Trace: <IRQ> [<ffffffff8104a716>] irq_exit+0x86/0x90 [<ffffffff81031e7d>] smp_apic_timer_interrupt+0x3d/0x50 [<ffffffff814f3eac>] apic_timer_interrupt+0x7c/0x90 <EOI> [<ffffffffa01c5b40>] ? gen8_write64+0x1a0/0x1a0 [i915] [<ffffffff814f2b39>] ? _raw_spin_unlock_irqrestore+0x9/0x20 [<ffffffffa01c5c44>] gen8_write32+0x104/0x1a0 [i915] [<ffffffff8132c6a2>] ? n_tty_receive_buf_common+0x372/0xae0 [<ffffffffa017cc9e>] gen6_set_rps_thresholds+0x1be/0x330 [i915] [<ffffffffa017eaf0>] gen6_set_rps+0x70/0x200 [i915] [<ffffffffa0185375>] intel_set_rps+0x25/0x30 [i915] [<ffffffffa01768fd>] gen6_pm_rps_work+0x10d/0x2e0 [i915] [<ffffffff81063852>] ? finish_task_switch+0x72/0x1c0 [<ffffffff8105ab29>] process_one_work+0x139/0x350 [<ffffffff8105b186>] worker_thread+0x126/0x490 [<ffffffff8105b060>] ? rescuer_thread+0x320/0x320 [<ffffffff8105fa64>] kthread+0xc4/0xe0 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 [<ffffffff814f351f>] ret_from_fork+0x3f/0x70 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 I could not explain, or find a code path, which would explain a +20 second lockup, but from some instrumentation it was apparent the interrupts off proportion of time was between 10-25% under heavy load which is quite bad. When a interrupt "cliff" is reached, which was >~320k irq/s on my machine, the whole system goes into a terrible state of the above described multi-second lockups. By moving the GT interrupt handling to a tasklet in a most simple way, the problem above disappears completely. Testing the effect on sytem-wide latencies using igt/gem_syslatency shows the following before this patch: gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us This shows that the unrelated process is experiencing huge delays in its wake-up latency. After the patch the results look like this: gem_syslatency: cycles=808907, latency mean=53.133us max=1640us gem_syslatency: cycles=862154, latency mean=62.778us max=2117us gem_syslatency: cycles=856039, latency mean=58.079us max=2123us gem_syslatency: cycles=841683, latency mean=56.914us max=1667us Showing a huge improvement in the unrelated process wake-up latency. It also shows an approximate halving in the number of total empty batches submitted during the test. This may not be worrying since the test puts the driver under a very unrealistic load with ncpu threads doing empty batch submission to all GPU engines each. Another benefit compared to the hard-irq handling is that now work on all engines can be dispatched in parallel since we can have up to number of CPUs active tasklets. (While previously a single hard-irq would serially dispatch on one engine after another.) More interesting scenario with regards to throughput is "gem_latency -n 100" which shows 25% better throughput and CPU usage, and 14% better dispatch latencies. I did not find any gains or regressions with Synmark2 or GLbench under light testing. More benchmarking is certainly required. v2: * execlists_lock should be taken as spin_lock_bh when queuing work from userspace now. (Chris Wilson) * uncore.lock must be taken with spin_lock_irq when submitting requests since that now runs from either softirq or process context. v3: * Expanded commit message with more testing data; * converted missed locking sites to _bh; * added execlist_lock comment. (Chris Wilson) v4: * Mention dispatch parallelism in commit. (Chris Wilson) * Do not hold uncore.lock over MMIO reads since the block is already serialised per-engine via the tasklet itself. (Chris Wilson) * intel_lrc_irq_handler should be static. (Chris Wilson) * Cancel/sync the tasklet on GPU reset. (Chris Wilson) * Document and WARN that tasklet cannot be active/pending on engine cleanup. (Chris Wilson/Imre Deak) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Testcase: igt/gem_exec_nop/all Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1459768316-6670-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
579de73b |
|
14-Mar-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Exit cherryview_irq_handler() after one pass This effectively reverts commit 8e5fd599eb219f1054e39b40d18b217af669eea9 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Apr 9 13:28:50 2014 +0300 drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed as under continuous execlists load we can saturate the IRQ handler, destablising the tsc clock and triggering the NMI watchdog to declare a hung CPU. [ 552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 552.756080] clocksource: 'refined-jiffies' wd_now: 10003b480 wd_last: 10003b28c mask: ffffffff [ 552.756091] clocksource: 'tsc' cs_now: d55d31aa50 cs_last: d17446166c mask: ffffffffffffffff [ 552.756210] clocksource: Switched to clocksource refined-jiffies [ 575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 [ 575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18 [ 575.217905] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 575.217915] 0000000000000000 ffff88027fd05bc0 ffffffff81288c6d 0000000000000000 [ 575.217935] 0000000000000001 ffff88027fd05be0 ffffffff810e72d1 0000000000000000 [ 575.217951] ffff88027fd05c80 ffff88027fd05c20 ffffffff81114b60 0000000181015f1e [ 575.217967] Call Trace: [ 575.217973] <NMI> [<ffffffff81288c6d>] dump_stack+0x4f/0x72 [ 575.217994] [<ffffffff810e72d1>] watchdog_overflow_callback+0x151/0x160 [ 575.218003] [<ffffffff81114b60>] __perf_event_overflow+0xa0/0x1e0 [ 575.218016] [<ffffffff811154c4>] perf_event_overflow+0x14/0x20 [ 575.218028] [<ffffffff8101d2ca>] intel_pmu_handle_irq+0x1da/0x460 [ 575.218042] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218052] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218064] [<ffffffff81014ae8>] perf_event_nmi_handler+0x28/0x50 [ 575.218075] [<ffffffff81007540>] nmi_handle+0x60/0x130 [ 575.218086] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218096] [<ffffffff810079c0>] do_nmi+0x140/0x470 [ 575.218108] [<ffffffff81559ec7>] end_repeat_nmi+0x1a/0x1e [ 575.218119] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218129] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218139] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218148] <<EOE>> [<ffffffff814a8353>] cpuidle_enter_state+0xf3/0x2f0 [ 575.218164] [<ffffffff814a8587>] cpuidle_enter+0x17/0x20 [ 575.218175] [<ffffffff810aaa3a>] call_cpuidle+0x2a/0x40 [ 575.218185] [<ffffffff810aade3>] cpu_startup_entry+0x273/0x330 [ 575.218196] [<ffffffff81033a1e>] start_secondary+0x10e/0x130 However, not servicing all available IIR within the handler does hurt the throughput of pathological nop execbuf by about 20%, with a similar effect upon the dispatch latency of a series of execbuf. v2: use do {} while(0) for a smaller patch, and easier to revert again I have reasonable confidence that we do not miss GT interrupts (as execlists provides a stress case with a failure mechanism easily detected by igt), however I have less confidence about all the other sources of interrupts and worry that may lose a display hotplug interrupt, for example. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467 Testcase: igt/gem_exec_nop/basic # requires NMI watchdog Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Antti Koskipää <antti.koskipaa@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457946117-6714-1-git-send-email-chris@chris-wilson.co.uk
|
#
b4ac5afc |
|
24-Mar-2016 |
Dave Gordon <david.s.gordon@intel.com> |
drm/i915: replace for_each_engine() Having provided for_each_engine_id() for cases where the third (id) argument is useful, we can now replace all the remaining instances with a simpler version that takes only two parameters. In many cases, this also allows the elimination of the local variable used in the iterator (usually 'i'). v2: s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson] Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458757194-17783-2-git-send-email-david.s.gordon@intel.com
|
#
c3232b18 |
|
23-Mar-2016 |
Dave Gordon <david.s.gordon@intel.com> |
drm/i915: introduce for_each_engine_id() Equivalent to the existing for_each_engine() macro, this will replace the latter wherever the third argument *is* actually wanted (in most places, it is not used). The third argument is renamed to emphasise that it is an engine id (type enum intel_engine_id). All the callers of the macro that actually need the third argument are updated to use this version, and the argument (generally 'i') is also updated to be 'id'. Other callers (where the third argument is unused) are untouched for now; they will be updated in the next patch. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
14b730fc |
|
18-Mar-2016 |
arun.siluvery@linux.intel.com <arun.siluvery@linux.intel.com> |
drm/i915/tdr: Prepare error handler to accept mask of hung engines In preparation for engine reset, the wedged argument of i915_handle_error() is extended to reflect as a mask of engines that are hung. This is further passed down to error state capture functions which are also updated. Engine reset recovery mechanism uses this mask and schedules recovery work for those particular engines. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458331676-567-3-git-send-email-arun.siluvery@linux.intel.com
|
#
bd39ec5d |
|
16-Mar-2016 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Move load time IRQ SW init earlier Most of the IRQ init is setting up hooks so move that part earlier. Leave the pm_qos_add_request() call in place. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1458128348-15730-4-git-send-email-imre.deak@intel.com
|
#
117897f4 |
|
16-Mar-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: More renaming of rings to engines This time using only sed and a few by hand. v2: Rename also intel_ring_id and intel_ring_initialized. v3: Fixed typo in intel_ring_initialized. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1458126040-33105-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
666796da |
|
16-Mar-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: More intel_engine_cs renaming Some trivial ones, first pass done with Coccinelle: @@ @@ ( - I915_NUM_RINGS + I915_NUM_ENGINES | - intel_ring_flag + intel_engine_flag | - for_each_ring + for_each_engine | - i915_gem_request_get_ring + i915_gem_request_get_engine | - intel_ring_idle + intel_engine_idle | - i915_gem_reset_ring_status + i915_gem_reset_engine_status | - i915_gem_reset_ring_cleanup + i915_gem_reset_engine_cleanup | - init_ring_lists + init_engine_lists ) But that didn't fully work so I cleaned it up with: for f in *.[hc]; do sed -i -e s/I915_NUM_RINGS/I915_NUM_ENGINES/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_request_get_ring/i915_gem_request_get_engine/ $f; done for f in *.[hc]; do sed -i -e s/intel_ring_flag/intel_engine_flag/ $f; done for f in *.[hc]; do sed -i -e s/intel_ring_idle/intel_engine_idle/ $f; done for f in *.[hc]; do sed -i -e s/init_ring_lists/init_engine_lists/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_cleanup/i915_gem_reset_engine_cleanup/ $f; done for f in *.[hc]; do sed -i -e s/i915_gem_reset_ring_status/i915_gem_reset_engine_status/ $f; done v2: Rebase. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
4a570db5 |
|
16-Mar-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Rename intel_engine_cs struct members below and a couple manual fixups. @@ identifier I, J; @@ struct I { ... - struct intel_engine_cs *J; + struct intel_engine_cs *engine; ... } @@ identifier I, J; @@ struct I { ... - struct intel_engine_cs J; + struct intel_engine_cs engine; ... } @@ struct drm_i915_private *d; @@ ( - d->ring + d->engine ) @@ struct i915_execbuffer_params *p; @@ ( - p->ring + p->engine ) @@ struct intel_ringbuffer *r; @@ ( - r->ring + r->engine ) @@ struct drm_i915_gem_request *req; @@ ( - req->ring + req->engine ) v2: Script missed the tracepoint code - fixed up by hand. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
0bc40be8 |
|
16-Mar-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Rename intel_engine_cs function parameters @@ identifier func; @@ func(..., struct intel_engine_cs * - ring + engine , ...) { <... - ring + engine ...> } @@ identifier func; type T; @@ T func(..., struct intel_engine_cs * - ring + engine , ...); Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e2f80391 |
|
16-Mar-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915: Rename local struct intel_engine_cs variables Done by the Coccinelle script below plus a manual intervention to GEN8_RING_SEMAPHORE_INIT. @@ expression E; @@ - struct intel_engine_cs *ring = E; + struct intel_engine_cs *engine = E; <+... - ring + engine ...+> @@ @@ - struct intel_engine_cs *ring; + struct intel_engine_cs *engine; <+... - ring + engine ...+> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
24a65e62 |
|
02-Mar-2016 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915/hangcheck: Prevent long walks across full-ppgtt With full-ppgtt, it takes the GPU an eon to traverse the entire 256PiB address space, causing a loop to be detected. Under the current scheme, if ACTHD walks off the end of a batch buffer and into an empty address space, we "never" detect the hang. If we always increment the score as the ACTHD is progressing then we will eventually timeout (after ~46.5s (31 * 1.5s) without advancing onto a new batch). To counter act this, increase the amount we reduce the score for good batches, so that only a series of almost-bad batches trigger a full reset. DoS detection suffers slightly but series of long running shader tests will benefit. Based on a patch from Chris Wilson. Testcase: igt/drv_hangman/hangcheck-unterminated Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1456930109-21532-1-git-send-email-mika.kuoppala@intel.com
|
#
6831f3e3 |
|
19-Feb-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add for_each_pipe_masked() for_each_pipe_masked() can be used to iterate over the pipes included in the user provided pipe mask. Removes a few lines of duplicated code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
aae8ba84 |
|
19-Feb-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make sure pipe interrupts are processed before turning off power well on BDW+ Starting from BDW the DE_PIPE interrupts for pipe B and C belong to the relevant display power well. So we should make sure we've finished processing them before turning off the power well. The pipe interrupts shouldn't really happen at this point anymore since we've already shut down the planes/pipes/whatnot, but being a bit paranoid shouldn't hurt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
1ca993d2 |
|
18-Feb-2016 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Skip PIPESTAT reads from irq handler on VLV/CHV when power well is down PIPESTAT registers live in the display power well on VLV/CHV, so we shouldn't access them when things are powered down. Let's check whether the display interrupts are on or off before accessing the PIPESTAT registers. Another option would be to read the PIPESTAT registers only when the IIR register indicates that there's a pending pipe event. But that would mean we might miss even more underrun reports than we do now, because the underrun status bit lives in PIPESTAT but doesn't actually generate an interrupt. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93738 Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455825266-24686-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
f11a0f46 |
|
12-Jan-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915/gen8: Factor out display interrupt handling Tidy quite long interrupt service routine by factoring out the display part. This simplifies the exit path a little bit, makes the code a bit more readable, and potentialy makes code reuse in the future easier. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452614647-13973-2-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
e32192e1 |
|
12-Jan-2016 |
Tvrtko Ursulin <tvrtko.ursulin@intel.com> |
drm/i915/gen8: Tidy display interrupt processing One bugfix and a few tidy-ups: * Pipe fault logging was broken on Gen9+. * Removed some unnecessary local variables. * Removed unnecessary initializers. * Decreased pipe iir block indentation level. * Grouped variable initialization close to use sites. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Chris Wilson <chris@cris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1452614647-13973-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
#
ccda3a72 |
|
07-Jan-2016 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: shut up gen8+ SDE irq dmesg noise, again We still keep getting [ 4.249930] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! This reverts commit 820da7ae46332fa709b171eb7ba57cbd023fa6df Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:23 2015 +0200 Revert "drm/i915: shut up gen8+ SDE irq dmesg noise" which in itself is a revert, so this is just doing commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise all over again. I'll stop pretending I understand what's going on like I did when I thought I'd fixed this for good in commit 6a39d7c986be4fd18eb019e9cdbf774ec36c9f77 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:22 2015 +0200 drm/i915: fix the SDE irq dmesg warnings properly Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reference: http://mid.gmane.org/20151213124945.GA5715@nuc-i3427.alporthouse.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 820da7ae4633 ("Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"") Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452155350-14658-1-git-send-email-jani.nikula@intel.com (cherry picked from commit 2dfb0b816d224379efc534764388745c474abeb4) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
75714940 |
|
16-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Do one shot unclaimed mmio detection less frequently We have done unclaimed register access check in normal (mmio_debug=0) mode once per write. This adds probability of finding the exact sequence where we did the bad access, but also adds burden to each write. As we have mmio_debug available for more fine grained analysis, give up accuracy of detecting correct spot at the first occurrence by doing the one shot detection and arming of mmio_debug in hangcheck and in modeset. This removes the write path performance burden. v2: Remove gratuitous DRM_DEBUG and return value, comments (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450250808-14864-1-git-send-email-mika.kuoppala@intel.com
|
#
fc97618b |
|
15-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Introduce intel_uncore_unclaimed_mmio Currently interrupt code is the only place checking for the unclaimed register access prior to actual register macros using the same functionality. Rename the function and make it return bool so that the possible error message context is clear in the caller side. The motivation is to allow usage of unclaimed detection on arbitrary places. v2: rebase, s/access/mmio, s/dev/dev_priv Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450189512-30360-2-git-send-email-mika.kuoppala@intel.com
|
#
61642ff0 |
|
01-Dec-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Inspect subunit states on hangcheck If head seems stuck and engine in question is rcs, inspect subunit state transitions from undone to done, before deciding that this really is a hang instead of limited progress. Only account the transitions of subunits from undone to done once, to prevent unstable subunit states to keep us falsely active. As this adds one extra steps to hangcheck heuristics, before hang is declared, it adds 1500ms to to detect hang for render ring to a total of 7500ms. We could sample the subunit states on first head stuck condition but decide not to do so only in order to mimic old behaviour. This way the check order of promotion from seqno > atchd > instdone is consistently done. v2: Deal with unstable done states (Arun) Clear instdone progress on head and seqno movement (Chris) Report raw and accumulated instdone's in in debugfs (Chris) Return HANGCHECK_ACTIVE on undone->done References: https://bugs.freedesktop.org/show_bug.cgi?id=93029 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448985372-19535-1-git-send-email-mika.kuoppala@intel.com
|
#
2dfb0b81 |
|
07-Jan-2016 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: shut up gen8+ SDE irq dmesg noise, again We still keep getting [ 4.249930] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! This reverts commit 820da7ae46332fa709b171eb7ba57cbd023fa6df Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:23 2015 +0200 Revert "drm/i915: shut up gen8+ SDE irq dmesg noise" which in itself is a revert, so this is just doing commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise all over again. I'll stop pretending I understand what's going on like I did when I thought I'd fixed this for good in commit 6a39d7c986be4fd18eb019e9cdbf774ec36c9f77 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:22 2015 +0200 drm/i915: fix the SDE irq dmesg warnings properly Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reference: http://mid.gmane.org/20151213124945.GA5715@nuc-i3427.alporthouse.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 820da7ae4633 ("Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"") Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452155350-14658-1-git-send-email-jani.nikula@intel.com
|
#
1f814dac |
|
15-Dec-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: add support for checking if we hold an RPM reference Atm, we assert that the device is not suspended until the point when the device is truly put to a suspended state. This is fine, but we can catch more problems if we check that RPM refcount is non-zero. After that one drops to zero we shouldn't access the device any more, even if the actual device suspend may be delayed. Change assert_rpm_wakelock_held() accordingly to check for a non-zero RPM refcount in addition to the current device-not-suspended check. For the new asserts to work we need to annotate every place explicitly in the code where we expect that the device is powered. The places where we only assume this, but may not hold an RPM reference: - driver load We assume the device to be powered until we enable RPM. Make this explicit by taking an RPM reference around the load function. - system and runtime sudpend/resume handlers These handlers are called when the RPM reference becomes 0 and know the exact point after which the device can get powered off. Disable the RPM-reference-held check for their duration. - the IRQ, hangcheck and RPS work handlers These handlers are flushed in the system/runtime suspend handler before the device is powered off, so it's guaranteed that they won't run while the device is powered off even though they don't hold any RPM reference. Disable the RPM-reference-held check for their duration. In all these cases we still check that the device is not suspended. These explicit annotations also have the positive side effect of documenting our assumptions better. This caught additional WARNs from the atomic modeset path, those should be fixed separately. v2: - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville) v3: - use a new dedicated RPM wakelock refcount to also catch cases where our own RPM get/put functions were not called (Chris) - assert also that the new RPM wakelock refcount is 0 in the RPM suspend handler (Chris) - change the assert error message to be more meaningful (Chris) - prevent false assert errors and check that the RPM wakelock is 0 in the RPM resume handler too - prevent false assert errors in the hangcheck work too - add a device not suspended assert check to the hangcheck work v4: - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts and wakelock_count to wakeref_count - disable the wakeref asserts in the IRQ handlers and RPS work too - update/clarify commit message v5: - mark places we plan to change to use proper RPM refcounting with separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1450227139-13471-1-git-send-email-imre.deak@intel.com
|
#
666a4537 |
|
09-Dec-2015 |
Wayne Boyer <wayne.boyer@intel.com> |
drm/i915: Separate cherryview from valleyview The cherryview device shares many characteristics with the valleyview device. When support was added to the driver for cherryview, the corresponding device info structure included .is_valleyview = 1. This is not correct and leads to some confusion. This patch changes .is_valleyview to .is_cherryview in the cherryview device info structure and simplifies the IS_CHERRYVIEW macro. Then where appropriate, instances of IS_VALLEYVIEW are replaced with IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent. v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro. Also add followup patches to fix issues discovered during the first review. (Ville) v3: Fix some style issues and one gen check. Remove CRT related changes as CRT is not supported on CHV. (Imre, Ville) v4: Make a few more optimizations. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
81fd874e |
|
25-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix kerneldoc indent fails Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448461290-12333-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
013d3752 |
|
23-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce bdw_{update,enable,disable}_pipe_irq() Pull the BDW+ DE pipe interrupt mask frobbing into a central place, like we have for other platforms. v2: Fix the kerneldoc (Daniel) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448294777-13722-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fbdedaea |
|
23-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make ironlake_{enable,disable}_display_irq() static inlines ironlake_{enable,disable}_display_irq() each just call ilk_update_display_irq() so let's make them static inlines. While at it s/ironlake/ilk/ to make things shorter, and a bit more consistent with the ibx functions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448294777-13722-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
820da7ae |
|
25-Nov-2015 |
Jani Nikula <jani.nikula@intel.com> |
Revert "drm/i915: shut up gen8+ SDE irq dmesg noise" This reverts commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise With the proper fix ("drm/i915: fix the SDE irq dmesg warnings properly") reliably in place, bring back the error message. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448462843-32739-2-git-send-email-jani.nikula@intel.com
|
#
6a39d7c9 |
|
25-Nov-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: fix the SDE irq dmesg warnings properly We had the "The master control interrupt lied (SDE)!" check and error message in place for a long time without any problems, until commit aaf5ec2e51ab1d9c5e962b4728a1107ed3ff7a3e Author: Sonika Jindal <sonika.jindal@intel.com> Date: Wed Jul 8 17:07:47 2015 +0530 drm/i915: Handle HPD when it has actually occurred caused the errors to start happening. This was bisected and reported, but the error message was silenced in commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise shooting the messenger while the debugging for why Sonika's commit triggered the errors was still in progress. It looks like we need to read and acknowledge the PCH_PORT_HOTPLUG register even though the hotplug trigger indicates there isn't a hotplug irq to handle. The PCH doesn't seem to really ack the the interrupt to the CPU unless we touch the hotplug register. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Fixes: aaf5ec2e51ab ("drm/i915: Handle HPD when it has actually occurred") [Jani: added a comment and amended the commit message while applying] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448462843-32739-1-git-send-email-jani.nikula@intel.com
|
#
f0f59a00 |
|
18-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Type safe register read/write Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
|
#
6fa1c5f1 |
|
04-Nov-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Parametrize L3 error registers Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-15-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b2916819 |
|
03-Nov-2015 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Extend DSL readout fix to BDW and SKL. Those platforms have the same bug as haswell, and the same fix applies to them. The original HSW fix that this extends is commit 41b578fb0e8b930f2470d3f673b0fa279e77a7b8 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Sep 22 12:15:54 2015 -0700 drm/i915: workaround bad DSL readout v3 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org # v4.3 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91579 Link: http://patchwork.freedesktop.org/patch/msgid/1446535913-31970-3-git-send-email-maarten.lankhorst@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
75aa3f63 |
|
22-Oct-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Turn __raw_i915_read8() & co. in to inline functions There's no need for __raw_i915_read8() & co. to be macros, so make them inline functions. To avoid typo mistakes generate the inline functions using preprocessor templates. We have a few users of the raw register acces functions outside intel_uncore.c, so let's also move the functions into intel_drv.h. While doing that switch I915_READ_FW() & co. to use the __raw_i915_read() functions, and use the _FW macros everywhere outside intel_uncore.c where we want to read registers without grabbing forcewake and whatnot. The only exception is i915_check_vgpu() which itself gets called from intel_uncore.c, so using the __raw_i915_read stuff there seems appropriate. v2: Squash in the intel_uncore.c->i915_drv.h move Convert I915_READ_FW() to use __raw_i915_read(), and use I915_READ_FW() outside of intel_uncore.c (Chris) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445517300-28173-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
97e5ed11 |
|
23-Oct-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: shut up gen8+ SDE irq dmesg noise We get tons of cases where the master interrupt handler apparently set a bit, with the SDEIIR disagreeing. No idea what's going on there, but it's consistent on gen8+, no one seems to care about it and it's making CI results flaky. Shut it up. No idea what's going on here, but we've had fun with PCH interrupts before: commit 44498aea293b37af1d463acd9658cdce1ecdf427 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 22 17:05:28 2013 -0300 drm/i915: also disable south interrupts when handling them Note that there's a regression report in Bugzilla, and other regression reports on the mailing lists keep croping up. But no ill effects have ever been reported. But for paranoia still keep the message at a debug level as a breadcrumb, just in case. This message was introduced in commit 38cc46d73ed99dd7002f1406002e52d7975d16cc Author: Oscar Mateo <oscar.mateo@intel.com> Date: Mon Jun 16 16:10:59 2014 +0100 drm/i915/bdw: Ack interrupts before handling them (GEN8) v2: Improve commit message a bit. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445590572-23631-2-git-send-email-daniel.vetter@ffwll.ch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80896 Acked-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f9e3dc78 |
|
21-Oct-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: add hotplug activation period to hotplug update mask commit 0706f17c307b056ff6f1848320ba82d76945a6ff Author: Egbert Eich <eich@suse.de> Date: Wed Sep 23 16:15:27 2015 +0200 drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2 added a check with WARN to ensure only bits within the mask are enabled. Turns out that doesn't hold for G4X, which spits out: [ 2.641439] ------------[ cut here ]------------ [ 2.641444] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/i915_irq.c:182 i915_hotplug_interrupt_update_locked+0x45/0x83() [ 2.641446] WARN_ON(bits & ~mask) etc. Add CRT_HOTPLUG_ACTIVATION_PERIOD_64 to the mask to fix the warning. Reported-and-tested-by: Oleksij Rempel <linux@rempel-privat.de> References: https://bugzilla.kernel.org/show_bug.cgi?id=104991 Fixes: 0706f17c307b ("drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2") Cc: Egbert Eich <eich@suse.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1445437363-3030-1-git-send-email-jani.nikula@intel.com
|
#
e4ba99b9 |
|
21-Oct-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fix formatting for gen8_cs_irq_handler Requested by Chris, and since we're no longer rebasing the -next queue I can't rectify history. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445415633-21897-1-git-send-email-daniel.vetter@ffwll.ch Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fbcc1a0c |
|
20-Oct-2015 |
Nick Hoath <nicholas.hoath@intel.com> |
drm/i915: Break out common code from gen8_gt_irq_handler Break out common code from gen8_gt_irq_handler and put it in to an always inlined function. gcc optimises out the shift at compile time. (Thomas Daniel/Daniel Vetter/Chris Wilson) Issue: VIZ-4277 Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> Cc: Thomas Daniel <thomas.daniel@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1445333036-22164-3-git-send-email-nicholas.hoath@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5dd280b0 |
|
20-Oct-2015 |
Nick Hoath <nicholas.hoath@intel.com> |
drm/i195: Rename gt_irq_handler variable Renamed tmp variable to the more descriptive iir. (Daniel Vetter/ Thomas Daniel) Issue: VIZ-4277 Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Gordon <david.s.gordon@intel.com> Cc: Thomas Daniel <thomas.daniel@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445333036-22164-2-git-send-email-nicholas.hoath@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
649636ef |
|
22-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Throw out some useless variables Drop some useless 'reg' variables when we only use them once. v2: A few more, including a few variable moves Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fd8f507c |
|
18-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc. The PIPE_FRMCOUNT_GM45 and PIPE_FLIPCOUNT_GM45 names have bothered me for a long time. The work equally well for ELK and onwards, so let's s/GM45/G4X/. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b51a2842 |
|
18-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
381e8ae3 |
|
08-Oct-2015 |
Tomas Elf <tomas.elf@intel.com> |
drm/i915: Early exit from semaphore_waits_for for execlist mode. When submitting semaphores in execlist mode the hang checker crashes in this function because it is only runnable in ring submission mode. The reason this is of particular interest to the TDR patch series is because we use semaphores as a mean to induce hangs during testing (which is the recommended way to induce hangs for gen8+). It's not clear how this is supposed to work in execlist mode since: 1. This function requires a ring buffer. 2. Retrieving a ring buffer in execlist mode requires us to retrieve the corresponding context, which we get from a request. 3. Retieving a request from the hang checker is not straight-forward since that requires us to grab the struct_mutex in order to synchronize against the request retirement thread. 4. Grabbing the struct_mutex from the hang checker is nothing that we will do since that puts us at risk of deadlock since a hung thread might be holding the struct_mutex already. Therefore it's not obvious how we're supposed to deal with this. For now, we're doing an early exit from this function, which avoids any kernel panic situation when running our own internal TDR ULT. * v2: (Chris Wilson) Turned the execlist mode check into a ringbuffer NULL check to make it more submission mode agnostic and less of a layering violation. Signed-off-by: Tomas Elf <tomas.elf@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
aafd8581 |
|
08-Oct-2015 |
Javier Martinez Canillas <javier@osg.samsung.com> |
drm/i915/irq: Fix misspelled word register in kernel-doc There is a typo in the function i915_handle_error() kernel-doc and the word register is spelled wrongly. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
468f9d29 |
|
08-Oct-2015 |
Javier Martinez Canillas <javier@osg.samsung.com> |
drm/i915/irq: Fix kernel-doc warnings Add the dev parameter for the functions i915_enable_asle_pipestat() and i915_reset_and_wakeup() to the kernel-doc to fix the following warnings: .//drivers/gpu/drm/i915/i915_irq.c:586: warning: No description found for parameter 'dev' .//drivers/gpu/drm/i915/i915_irq.c:2400: warning: No description found for parameter 'dev' Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
88e72717 |
|
24-Sep-2015 |
Thierry Reding <treding@nvidia.com> |
drm/irq: Use unsigned int pipe in public API This continues the pattern started in commit cc1ef118fc09 ("drm/irq: Make pipe unsigned and name consistent"). This is applied to the public APIs and driver callbacks, so pretty much all drivers need to be updated to match the new prototypes. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Inki Dae <inki.dae@samsung.com> Cc: Jianwei Wang <jianwei.wang.chn@gmail.com> Cc: Alison Wang <alison.wang@freescale.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: David Airlie <airlied@linux.ie> Cc: Rob Clark <robdclark@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7bad74d5 |
|
24-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use czclk_freq in vlv c0 residency calculations Replace the use of mem_freq/4 with czclk_freq in the vlv c0 residency calculations. Also deal with VLV_COUNT_RANGE_HIGH which affects all RCx residency counters. We have just enough bits to do this without intermediate divisions. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3bb403bf |
|
14-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Stop using linedur_ns and pixeldur_ns for vblank timestamps linedur_ns, and especially pixeldur_ns are becoming rather inaccurate to be used for the vblank timestamp correction. With 4k@60 the pixel duration is already below 2ns, so the amount of error due to the truncation to nanoseconds is introducing quite a bit of error. We can avoid such problems if we instead calculate the timestamp delta_ns directly from the dislay timings, avoiding the use of these intermediate truncated values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in fixup from Thierry Reding for amdgpu.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
eba1f35d |
|
14-Sep-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Move timestamping constants into drm_vblank_crtc Collect the timestamping constants alongside the rest of the relevant stuff under drm_vblank_crtc. We can now get rid of the 'refcrtc' parameter to drm_calc_vbltimestamp_from_scanoutpos(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0706f17c |
|
23-Sep-2015 |
Egbert Eich <eich@suse.de> |
drm/i915: Avoid race of intel_crt_detect_hotplug() with HPD interrupt, v2 An HPD interrupt may fire while we are in a function that changes the PORT_HOTPLUG_EN register - especially when an HPD interrupt storm occurs. Since the interrupt handler changes the enabled HPD lines when it detects such a storm the read-modify-write cycles may interfere. To avoid this, shiled the rmw cycles with IRQ save spinlocks. Changes since v1: - Implement a function which takes care of accessing PORT_HOTPLUG_EN. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
41b578fb |
|
22-Sep-2015 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: workaround bad DSL readout v3 On HSW at least (still testing other platforms, but should be harmless elsewhere), the DSL reg reads back as 0 when read around vblank start time. This ends up confusing the atomic start/end checking code, since it causes the update to appear as if it crossed a frame count boundary. Avoid the problem by making sure we don't return scanline_offset from the get_crtc_scanline function. In moving the code there, I add to add an additional delay since it could be called and have a legitimate 0 result for some time (depending on the pixel clock). v2: move hsw dsl read hack to get_crtc_scanline (Ville) v3: use break instead of goto (Ville) update comment with workaround details (Ville) References: https://bugs.freedesktop.org/show_bug.cgi?id=91579 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
b4834a50 |
|
02-Sep-2015 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Future proof interrupt handler. These functions are already being called for gen >= 9, so let's be sure when this happens we use whatever is there already for the latest platform. No functional change. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
58f2cf24 |
|
28-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't call intel_get_hpd_pins() when there's no hotplug interrupt On GMCH plaforms we are now getting the following spew on aux interrupts: [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x00000000, pins 0x00000000 [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 Prevent it by not calling intel_get_hpd_pins() unless one of the HPD interrupt bits are actually set. I already fixed similar annoyance once with 4bca26d0a6518d51a9abe64fbde4b12f04c74053 drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV but another source for it got added in fd63e2a972c670887e5e8a08440111d3812c0996 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins due to pch_get_hpd_pins() being chosen over i9xx_get_hpd_pins() to serve as the new unified piece of code. pch_get_hpd_pins() had the debug print, and i9xx_get_hpd_pins() didn't. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a52bb15b |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rewrite BXT HPD code to conform to pre-existing style Rewrite the BXT hpd setup to match the way we do it on other platforms: - Throw out BXT_HOTPLUG_CTL since it's the same as PCH_PORT_HOTPLUG - Enable the HPD bits in the DE port IER in gen8_de_irq_postinstall() - Update DE port IMR using bdw_update_port_irq() Also throw out port D from bxt_port_hotplug_long_detect() since BXT only goes up to C. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
40e56410 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Refactor the hpd irq handling functions A lot of the hpd irq handling is duplicated code, so refactor it a bit by observing that in several places the only difference is the hpd[] array. So pull the code to a few functions and pass in the hpd[] array from the caller. Another option would be to determine the correct array to use within the functions themselves, but somehow passing it in felt nicer. Further code reduction could be achieved by passing in the hotplug register offset, and the long pulse detection function pointer. But that didn't feel as good for some reason, so I left it at the middle ground. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cebd87a0 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rewrite bxt_hpd_handler() to look like everyone else bxt_hpd_handler() looks different to everyone else for no good reason. Rewrite it to use the standard variable namees etc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
74c0b395 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add port A HPD support for SPT On SKL the port A HPD has moved to the PCH. Hook it up. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3a3b3c7d |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add port A HPD support for BDW Wire up the port A HPD for BDW. Compared to earlier platforms the interrupt setup is a bit different, but basically everything else looks the same. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Check for BDW before processing the HPD to not break BXT Set found=true when processing port A HPD Sort out the mess I made of the irq setup in v1 Warn about bad irq mask vs. enable bits in bdw_update_port_irq() (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0b2eb33e |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: LPT:LP needs port A HPD enabled in both north and south If the CPU and PCH are on the same package we must enabled the port A HPD also in the south hotplug register. To identify the package type we simply look at the PCH type: LPT-H means separate package, and LPT-LP means multi chip package (MCP). v2: Add comment and pimp commit message Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
23bb4cb5 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add port A HPD support for IVB/HSW As with ILK/SNB wire up the port A HPD on IVB/HSW. This might be more important on HSW with PSR. BSpec tells us that if the automagic link training performed by the hardware fails for some reason, we're going to get a short HPD and are supposed to re-train the link manyally. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Add a comment about the pulse duration bits being reserved on HSW+ like we have for LPT+ in ibx_hpd_irq_setup() Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e4ce95aa |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add port A HPD support for ILK/SNB ILK/SNB support port A HPD. While HPD is optional on eDP let's at least try to wite it up so that we might notice if the link has issues. The eDP spec suggests that if HPD is not wired up, one should poll the link status instead. We don't even do that currently. v2: 0 initialize pin_mask/long_mask due to intel_get_hpd_pins() changes Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6dbf30ce |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce spt_irq_handler() Starting from SPT the only interrupts living in the south are GMBUS and HPD. What's worse some of the SPT specific new bits conflict with some other bits on earlier PCH generations. So better not use the cpt_irq_handler() for SPT+ anymore. Also kill the hand rolled port E handling with something more standardish. This also avoids accidentally confusing port B and port E long pulses since the bits occupy the same positions, just in different registers. Also add a comment noting that the short pulse duration bits are reserved on LPT+. The 2ms value we program is 0, so no issue wrt. the MBZ in the spec. v2: Call intel_hpd_irq_handler() only once (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
42db67d6 |
|
28-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Move {pin, long}_mask initialization to caller from intel_get_hpd_pins() Move the 0 initialization of pin_mask and long_mask from intel_get_hpd_pins() into each caller. This we we can call intel_get_hpd_pins() multiple times to accumulate more pins from several sources. v2: Add a comment explaining the dangers of intel_get_hpd_pins() (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
195baa06 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rename BXT PORTA HPD defines The PORTA HPD defines are not BXT specific. They also exist on SPT, and partially already on LPT:LP. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d9dc34f1 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Factor out ilk_update_display_irq() Extract the core of ironlake_{enable,disable}_display_irq() into a new function. We'll have further use for it later. v2: Warn about invalid mask vs. enable bits (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
87a02106 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_hpd_enabled_irqs() Eliminate a bunch of duplicated code that calculates the currently enabled HPD interrupt bits. v2: s/;/:/ in patch subject (Paulo) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4e3d1e26 |
|
27-Aug-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass hpd_status_i915[] to intel_get_hpd_pins() in pre-g4x Pass the correct hpd[] array to intel_get_hpd_pins() on pre-g4x platforms. This got broken in the following commit: commit fd63e2a972c670887e5e8a08440111d3812c0996 Author: Imre Deak <imre.deak@intel.com> Date: Tue Jul 21 15:32:44 2015 -0700 drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Egbert Eich <eich@suse.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
26951caf |
|
17-Aug-2015 |
Xiong Zhang <xiong.y.zhang@intel.com> |
drm/i915/skl: enable DDI-E hotplug v2: fix one error found by checkpath.pl v3: Add one ignored break for switch-case. DDI-E hotplug function doesn't work after updating drm-intel tree, I checked the code and found this missing which isn't the root cause for broke DDI-E hp. The broken DDI-E hp function is fixed by "Adding DDI_E power well domain". Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
7f3561be |
|
09-Aug-2015 |
Sonika Jindal <sonika.jindal@intel.com> |
drm/i915/bxt: Add HPD support for DDIA Also remove redundant comments. Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
805de8f4 |
|
23-Apr-2015 |
Peter Zijlstra <peterz@infradead.org> |
atomic: Replace atomic_{set,clear}_mask() usage Replace the deprecated atomic_{set,clear}_mask() usage with the now ubiquous atomic_{or,andnot}() functions. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
#
63c88d22 |
|
20-Jul-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: add support for HPD long/short pulse detection on HPD_PORT_A pin This is a requirement for enabling display port HPD support on the port A HPD pin. This support is to be added by follow-up patches. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cc24fcdc |
|
21-Jul-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: don't use HPD_PORT_A as an alias for HPD_NONE Currently HPD_PORT_A is used as an alias for HPD_NONE to mean that the given port doesn't support long/short HPD pulse detection. SDVO and CRT ports are like this and for these ports we only want to know whether an hot plug event was detected on the corresponding pin. Since at least on BXT we need long/short pulse detection on PORT A as well (added by the next patch) remove this aliasing of HPD_PORT_A/HPD_NONE and let the return value of intel_hpd_pin_to_port() show whether long/short pulse detection is supported on the passed in pin. No functional change. v2: - rebase on top of -nightly (Daniel) - make the check for intel_hpd_pin_to_port() return value more readable (Sivakumar) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fd63e2a9 |
|
21-Jul-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins These functions are quite similar, so combine them with the use of a new argument for a function that detects long pulses. This will be also needed by an upcoming patch adding support for BXT long pulse detection. No functional change. v2: - rebase on top -nightly (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
94f7bbe1 |
|
09-Jul-2015 |
Tomas Elf <tomas.elf@intel.com> |
drm/i915: Snapshot seqno of most recently submitted request. The hang checker needs to inspect whether or not the ring request list is empty as well as if the given engine has reached or passed the most recently submitted request. The problem with this is that the hang checker cannot grab the struct_mutex, which is required in order to safely inspect requests since requests might be deallocated during inspection. In the past we've had kernel panics due to this very unsynchronized access in the hang checker. One solution to this problem is to not inspect the requests directly since we're only interested in the seqno of the most recently submitted request - not the request itself. Instead the seqno of the most recently submitted request is stored separately, which the hang checker then inspects, circumventing the issue of synchronization from the hang checker entirely. This fixes a regression introduced in commit 44cdd6d219bc64f6810b8ed0023a4d4db9e0fe68 Author: John Harrison <John.C.Harrison@Intel.com> Date: Mon Nov 24 18:49:40 2014 +0000 drm/i915: Convert 'ring_idle()' to use requests not seqnos v2 (Chris Wilson): - Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather than compute it over again. - Remove extra whitespace. Issue: VIZ-5998 Signed-off-by: Tomas Elf <tomas.elf@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add regressing commit citation provided by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
aaf5ec2e |
|
08-Jul-2015 |
Sonika Jindal <sonika.jindal@intel.com> |
drm/i915: Handle HPD when it has actually occurred Writing to PCH_PORT_HOTPLUG for each interrupt is not required. Handle it only if hpd has actually occurred like we handle other interrupts. v2: Make few variables local to if block (Ville) v3: Add check for ibx/cpt both (Ville). While at it, remove the redundant check for hotplug_trigger from pch_get_hpd_pins v4: Indentation (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8c841e57 |
|
18-Jun-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: reduce line width in {pch, i9xx}_get_hpd_pins() Make Paulo happier. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
77913b39 |
|
18-Jun-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move generic hotplug code into new intel_hotplug.c file We have enough generic hotplug functions sprinkled all over i915_irq.c to warrant moving them to a file of their own. This should further underline the distinction between generic code in the new file and platform specific hotplug and irq code that remains in i915_irq.c. Add new intel_hpd_init_work to keep work functions static, and rename get_port_from_pin to intel_hpd_pin_to_port while increasing its visibility, but keep everything else the same. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
10b0e9e9 |
|
18-Jun-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: clarify irq storm related function naming We'll have three functions: intel_hpd_irq_storm_detect for detecting irq storms, intel_hpd_irq_storm_disable for disabling hotplugs after detected storms, intel_hpd_irq_storm_reenable_work for re-enabling hotplug. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
70f71d5f |
|
18-Jun-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: abstract irq storm hotplug disabling Continue abstracting hotplug storm related functions to clarify the code. This time, abstract hotplug irq storm related hotplug disabling. While at it, clean up the loop iterating over connectors for readability. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a0049865 |
|
18-Jun-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: move hotplug even debug print to second connector loop The hotplug work function has two loops iterating over connectors, the first for handling hotplug disabling due to irq storms and the second for actually handling the hotplug events. Move the debug printing into the second one, so we can abstract the storm handling better. This may change the output ordering slightly when there are multiple simultaneous hotplug events. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fc467a22 |
|
31-May-2015 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Use crtc->hwmode for vblanks, v2. intel_crtc->config will be removed eventually, so use crtc->hwmode. drm_atomic_helper_update_legacy_modeset_state updates hwmode, but crtc->active will eventually be gone too. Set dotclock to zero to indicate the crtc is inactive. Changes since v1: - With the hwmode update in drm*update_legacy_modeset_state removed, intel_modeset_update_state has to assign it instead. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
53d9f4e9 |
|
31-May-2015 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Use crtc_state->active instead of crtc_state->enable crtc_state->enable means a crtc is configured, but it may be turned off for dpms. Until the commit "use intel_crtc_control everywhere" crtc_state->active was not updated on crtc off, but now crtc_state->active should be used for tracking whether a crtc is scanning out or not. A few commits from now dpms will be handled by calling intel_set_mode with a different value for crtc_state->active, which causes a crtc to turn on or off. At this point crtc->active should mirror crtc_state->active, so some paranoia from the crtc_disable functions can be removed. intel_set_mode_setup_plls still checks for ->enable, because all resources that are needed have to be calculated, else dpms changes may not succeed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
a2ee48d6 |
|
29-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: abstract hpd irq storm detection Simplify intel_hpd_irq_handler() by extracting HPD irq storm detection to a separate function. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
475c2e3b |
|
28-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/bxt: clear hpd status sticky bits earlier The hotplug status is cached in hp_control, and will be passed on to bottom halves through intel_hpd_irq_handler(), so we can clear the sticky bits earlier. While at it, drop the redundant logging of the hotplug status, which will also be logged by pch_get_hpd_pins(). Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
676574df |
|
28-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: abstract away platform specific parts from hpd handling Split intel_hpd_irq_handler into platforms specific and platform agnostic parts. The platform specific parts decode the registers into information about which hpd pins triggered, and if they were long pulses. The platform agnostic parts do further processing, such as interrupt storm mitigation and scheduling bottom halves. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c8727233 |
|
28-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: simplify condition for digital port As the hpd loops have been merged together, we don't have to maintain state for all hpd triggers. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9ace0433 |
|
28-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: merge the two hpd loops in intel_hpd_irq_handler to one Nothing in the two consecutive loops over hpd pins depends on state in a larger context than the single hpd pin. If we skip the rest of the loop on short hpd pulses, we can merge the two loops into one. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ab68d5bb |
|
28-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: put back the indent in intel_hpd_irq_handler In an unfortunate back and forth stepping, retract the earlier change to reduce indent. This is to make merging the two loops easier. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
641a969e |
|
28-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: simplify conditions for skipping the 2nd hpd loop iterations Multiple positive and negative checks for hpd[i] & hotplug_trigger gets hard to read. Simplify. This should make follow-up patches merging the two loops easier. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c91711f9 |
|
28-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: add for_each_hpd_pin to iterate over hotplug pins No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5fcece80 |
|
27-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: group all hotplug related fields into a new struct in dev_priv There are plenty of hotplug related fields in struct drm_i915_private scattered all around. Group them under one hotplug struct. Clean up naming while at it. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b0c29a33 |
|
27-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: reduce indent in intel_hpd_irq_handler Continue to loop early if there's nothing to do. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
369712e8 |
|
27-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: reduce duplicate conditions in i9xx_hpd_irq_handler Move dp aux irq handling within the same branch instead of duplicating the conditions. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0d2e4297 |
|
27-May-2015 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: reduce indent in i9xx_hpd_irq_handler Bail out early if nothing to do. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8d3afd7d |
|
21-May-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use spinlocks for checking when to waitboost In commit 1854d5ca0dd7a9fc11243ff220a3e93fce2b4d3e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:32 2015 +0100 drm/i915: Deminish contribution of wait-boosting from clients we removed an atomic timer based check for allowing waitboosting and moved it below the mutex taken during RPS. However, that mutex can be held for long periods of time on Vallyview/Cherryview as communication with the PCU is slow. As clients may frequently wait for results (e.g. such as tranform feedback) we introduced contention between the client and the RPS worker. We can take advantage of the RPS worker, by switching the wait boost decision to use spin locks and defer the actual reclocking to the worker. Fixes a regression of up to 45% on Baytrail and Baswell! v2 (Daniel): - Use max_freq_softlimit instead of the not-yet-merged boost frequency. - Don't inject a fake irq into the boost work, instead treat client_boost as just another legit waker. v3: Drop the now unused mask (Chris). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f5a4c67d |
|
27-Apr-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Don't downclock whilst we have clients waiting for GPU results If we have clients stalled waiting for requests, ignore the GPU if it signals that it should downclock due to low load. This helps prevent the automatic timeout from causing extremely long running batches from taking even longer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4bca26d0 |
|
11-May-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use HOTPLUG_INT_STATUS_G4X on VLV/CHV Use HOTPLUG_INT_STATUS_G4X instead of HOTPLUG_INT_STATUS_I915 on VLV/CHV so that we don't confuse the AUX status bits with SDVO status bits. Avoid pointless log spam as below while handling AUX interrupts: [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00000040, dig 0x00000000 [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00000040, dig 0x00000000 [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00000040, dig 0x00000000 [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00000040, dig 0x00000000 [drm:intel_hpd_irq_handler] hotplug event received, stat 0x00000040, dig 0x00000000 [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x71450064 Note that there's no functional issue, it's just that the sdvo bits overlap with the dp aux bits. Hence every time we receive an aux interrupt we also think there's an sdvo hpd interrupt, but due to lack of any sdvo encoders nothing ever happens because of that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Add Ville's explanation why nothing functional really changes.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8fc3b42e |
|
11-May-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove excess inline keywords Remove some inline keywords. One of the functions has clearly outgrown it anyway, so let's just leave it to the compiler. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
37ef01ab |
|
01-Apr-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Dont enable CS_PARSER_ERROR interrupts at all We stopped handling them in commit aaecdf611a05cac26a94713bad25297e60225c29 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Nov 4 15:52:22 2014 +0100 drm/i915: Stop gathering error states for CS error interrupts but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (*cough* coreboot *cough*) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang. Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171 Tested-by: Mono <mono-for-kernel-org@donderklumpen.de> Tested-by: info@gluglug.org.uk Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
9e63743e |
|
22-Aug-2014 |
Shashank Sharma <shashank.sharma@intel.com> |
drm/i915/bxt: Enable GMBUS IRQ GMBUS interrupt has been moved to CPU side in BXT. What this patch does is: 1. Enable GMBUS IRQ in de_post_install function 2. Handle this interrupt as a port interrupt in display irq handler v2: Rebase on top of the for_each_pipe() change adding dev_priv as first argument (Damien). v3: read BXT_DE_PORT_GMBUS IIR flag only on BXT on other platforms it's reserved (imre) v4: (jani) - remove redundant 'BXT GMBUS' comment - fix formatting of BXT_DE_PORT_GMBUS definition Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> (v1) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
266ea3d9 |
|
22-Aug-2014 |
Shashank Sharma <shashank.sharma@intel.com> |
drm/i915/bxt: Add BXT support in gen8_irq functions This patch adds conditional checks in gen8_irq functions to support BXT. Most of the checks just look for PCH split availability, and block the call to PCH interrupt functions if not available. v2: (jani) - drop redundant TODO comment about PCH IRQ flags on BXT - check HAS_PCH_SPLIT instead of IS_BROXTON when handling PCH specific IRQ events in gen8_irq_handler() - check HAS_PCH_SPLIT before calling the function instead of a corresponding early return within the called function for ibx_irq_reset(), ibx_irq_pre_postinstall(), ibx_irq_postinstall() v3: (jani) - in ironlake_irq_postinstall() and ironlake_irq_reset() HAS_PCH_SPLIT is always true, so drop the check for it Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Shashank Sharma <ppashank.sharma@intel.com> (v1) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d04a492d |
|
22-Aug-2014 |
Shashank Sharma <shashank.sharma@intel.com> |
drm/i915/bxt: Add DDI hpd handler This patch adds a hot plug interrupt handler function for BXT. What this function typically does is: 1. Check if hot plug is enabled from hot plug control register. 2. Call hpd_irq_handler with appropriate trigger to detect a plug storm and schedule a bottom half. 3. Clear sticky status bits in hot plug control register.. v2: (jani) - drop redundant unlikely() - s/Todo/FIXME:/ in code comment - declare 'found' var in the scope where it's used - check for IS_BROXTON before handling BXT_DE_PORT_HOTPLUG_MASK Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> (v1) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6b5ad42f |
|
27-Mar-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915/bxt: support for HPD long/short status decoding All non-GMCH platforms have the same register layout for HPD long/short status, so let's use this condition instead of HAS_PCH_SPLIT, as the latter doesn't apply for BXT. Noticed by Daniel. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e0a20ad7 |
|
27-Mar-2015 |
Shashank Sharma <shashank.sharma@intel.com> |
drm/i915/bxt: DDI Hotplug interrupt setup In BXT, DDI hotplug control has been moved to CPU from PCH. This patch adds a new IRQ setup function for BXT which: 1. Checks which HPD ports are requested to be enabled by encoders. 2. Enables those ports in the hot plug control register. 3. Un-masks these port interrupts in the IMR register. 4. Enables these port interrupts in the IER register. V3: Kept the default HPD filter count to default (500 us) as per satheesh's comment v4: Remove unused HPD filter defines (Damien) v5: warn if trying to setup HPD on port A (imre) v6: fix order of definitions for register bitfields (Daniel) v7: (jani) - define the size of the hpd_bxt array explicitly for bound checking - use for_each_intel_encoder instead of open coding it - fix format/order of definitions for BXT_HOTPLUG_CTL reg bitfields Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> (v4) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
74cdb337 |
|
07-Apr-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Tidy gen8 IRQ handler Remove some needless variables and parameter passing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cb0d205e |
|
07-Apr-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reduce locking in gen8 IRQ handler Similar in vain in reducing the number of unrequired spinlocks used for execlist command submission (where the forcewake is required but manually controlled), we know that the IRQ registers are outside of the powerwell and so we can access them directly. Since we now have direct access exported via I915_READ_FW/I915_WRITE_FW, lets put those to use in the irq handlers as well. In the process, reorder the execlist submission to happen as early as possible. v2: Restrict the untraced register mmio to just the GT path (i.e. the hotpath for execlists) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
edcf284b |
|
07-Apr-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Fix computation of last_adjustment for RPS autotuning The issue is that by computing the last_adj value after applying the clamping, we can end up with a bogus value for feeding into the next RPS autotuning step. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8fb55197 |
|
07-Apr-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Agressive downclocking on Baytrail Reuse the same reclocking strategy for Baytail as on its bigger brethren, Sandybridge and Ivybridge. In particular, this makes the device quicker to reclock (both up and down) though the tendency now is to downclock more aggressively to compensate for the RPS boosts. v2: Rebase v3: Exclude Cherrytrail as Deepak was concerned that the increased number of register writes would wake the common powerwell too often. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
096fad9e |
|
23-Mar-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: move clearing of RPS interrupt bits from disable to reset time The logical place for clearing the RPS latched interrupt bits is when resetting the RPS interrupts, so move the corresponding part from the RPS disable function to the reset function. During resetting we already cleared the IIR bits, so the only thing missing there was clearing pm_iir. Note that we call gen6_disable_rps_interrupts() also during driver load and resume time via intel_uncore_sanitize() when i915 interrupts are still not installed. If there are any pending RPS bits at this point (which after this patch wouldn't be cleared) they will be cleared by the reset code via the interrupt preinstall hooks. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
58072ccb |
|
23-Mar-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix race when clearing RPS IIR bits When disabling RPS interrupts there is a race where we disable RPS inerrupts while the interrupt handler is running and the handler has already latched the pending RPS interrupt from the master IIR register. Afterwards the disabling path clears the PM IIR bits, making the state of pending interrupts inconsistent from the interrupt handler's point of view. This triggers the following warning: "The master control interrupt lied (PM)!". To fix this make sure that any running interrupt handler (which may have already latched the master IIR) finishes before clearing the IIR bits. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87347 Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6f4b12f8 |
|
18-Mar-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use down ei for manual Baytrail RPS calculations Use both up/down manual ei calcuations for symmetry and greater flexibility for reclocking, instead of faking the down interrupt based on a fixed integer number of up interrupts. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
43cf3bf0 |
|
18-Mar-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Improved w/a for rps on Baytrail Rewrite commit 31685c258e0b0ad6aa486c5ec001382cf8a64212 Author: Deepak S <deepak.s@linux.intel.com> Date: Thu Jul 3 17:33:01 2014 -0400 drm/i915/vlv: WA for Turbo and RC6 to work together. Other than code clarity, the major improvement is to disable the extra interrupts generated when idle. However, the reclocking remains rather slow under the new manual regime, in particular it fails to downclock as quickly as desired. The second major improvement is that for certain workloads, like games, we need to combine render+media activity counters as the work of displaying the frame is split across the engines and both need to be taken into account when deciding the global GPU frequency as memory cycles are shared. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
aa448626 |
|
05-Mar-2015 |
Akash Goel <akash.goel@intel.com> |
drm/i915/skl: Enabling processing of Turbo interrupts Earlier Turbo interrupts were not being processed for SKL, as something was amiss in turbo programming for SKL. Now missing changes have been added, so enabling the Turbo interrupt processing for SKL. Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d14c0343 |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Restore pipe interrupt registers after power well enabling The pipe interrupt registers are in the actual pipe power well, so we need to restore them when re-enable the corresponding power well. I've also copied what we do on HSW/BDW for VGA, even if the we haven't enabled unclaimed registers just yet. v2: Don't run skl_power_well_post_enable() if the power well is already enabled (Paulo) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4c6c03be |
|
06-Mar-2015 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Make gen8_irq_power_well_post_enable() take a pipe mask While we only need to restore pipe B/C interrupt registers on BDW when enabling the power well, skylake a bit more flexible and we'll also need to restore the pipe A registers as it has its own power well that can be toggled. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
83d65738 |
|
25-Feb-2015 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Use enabled value from crtc_state rather than crtc (v2) As vendors transition their drivers from legacy to atomic there's some duplication of data between drm_crtc and drm_crtc_state (since unconverted drivers likely won't have a state structure). i915 is partially converted and does have a crtc->state structure, but still uses direct crtc fields internally in many places, which causes the two sets of data to get out of sync. As of commit commit 31c946e85ce6b48ce0f25e3cdca8362e4fe8b300 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Feb 22 12:24:17 2015 +0100 drm: If available use atomic state in getcrtc ioctl This way drivers fully converted to atomic don't need to update these legacy state variables in their modeset code any more. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> the DRM core starts assuming that the presence of a ->state structure implies that it should make use of the values stored there which, on i915, leads to the core code using stale values for CRTC 'enabled' status. Let's switch over to using the state value of 'enable' internally rather than using the drm_crtc field. This ensures that our driver internals are working from the same data that the DRM core is, avoiding mismatches. This patch was generated with Coccinelle using the following semantic patch: <smpl> @@ struct drm_crtc C; struct drm_crtc *CP; @@ ( - C.enabled + C.state->enable | - CP->enabled + CP->state->enable ) // For assignments, we still update the legacy value as well as the state value // so add an extra assignment statement for that. @@ struct drm_crtc C; struct drm_crtc *CP; expression E; @@ ( C.state->enable = E; + C.enabled = E; | CP->state->enable = E; + CP->enabled = E; ) </smpl> The crtc->mode and crtc->hwmode fields should probably be transitioned over as well eventually, but we seem to do an okay job of keeping those up-to-date already so I want to minimize the changes that will clash with Ander's in-progress atomic work. v2: Don't remove the assignments to the legacy value when we assign to the state value. A second cocci stanza takes care of adding the legacy assignment back where appropriate. (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2dd2a883 |
|
24-Feb-2015 |
Imre Deak <imre.deak@intel.com> |
drm/i915: avoid processing spurious/shared interrupts in low-power states Atm, it's possible that the interrupt handler is called when the device is in D3 or some other low-power state. It can be due to another device that is still in D0 state and shares the interrupt line with i915, or on some platforms there could be spurious interrupts even without sharing the interrupt line. The latter case was reported by Klaus Ethgen using a Lenovo x61p machine (gen 4). He noticed this issue via a system suspend/resume hang and bisected it to the following commit: commit e11aa362308f5de467ce355a2a2471321b15a35c Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jun 18 09:52:55 2014 -0700 drm/i915: use runtime irq suspend/resume in freeze/thaw This is a problem, since in low-power states IIR will always read 0xffffffff resulting in an endless IRQ servicing loop. Fix this by handling interrupts only when the driver explicitly enables them and so it's guaranteed that the interrupt registers return a valid value. Note that this issue existed even before the above commit, since during runtime suspend/resume we never unregistered the handler. v2: - clarify the purpose of smp_mb() vs. synchronize_irq() in the code comment (Chris) v3: - no need for an explicit smp_mb(), we can assume that synchronize_irq() and the mmio read/writes in the install hooks provide for this (Daniel) - remove code comment as the remaining synchronize_irq() is self explanatory (Daniel) v4: - drm_irq_uninstall() implies synchronize_irq(), so no need to call it explicitly (Daniel) Reference: https://lkml.org/lkml/2015/2/11/205 Reported-and-bisected-by: Klaus Ethgen <Klaus@Ethgen.ch> Cc: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
f3a5c3f6 |
|
13-Feb-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Flatten DRIVER_MODESET checks in i915_irq.c UMS is no more! Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
1efa2e35 |
|
13-Feb-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Drop pipe_enable checks in vblank funcs With Ville's rework to use drm_crtc_vblank_on/off the core will take care of rejecting drm_vblank_get calls when the pipe is off. Also the core won't call the get_vblank_counter hooks in that case either. And since we've dropped ums support recently we can now remove these hacks, yay! Noticed while trying to answer questions Laurent had about how the new atomic helpers work. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
ffe02b40 |
|
02-Feb-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_set_rps() Replace the valleyview_set_rps() and gen6_set_rps() calls with intel_set_rps() which itself does the IS_VALLEYVIEW() check. The code becomes simpler since the callers don't have to do this check themselves. Most of the change was performe with the following semantic patch: @@ expression E1, E2, E3; @@ - if (IS_VALLEYVIEW(E1)) { - valleyview_set_rps(E2, E3); - } else { - gen6_set_rps(E2, E3); - } + intel_set_rps(E2, E3); Adding intel_set_rps() and making valleyview_set_rps() and gen6_set_rps() static was done manually. Also valleyview_set_rps() had to be moved a bit avoid a forward declaration. v2: Use a less greedy semantic patch Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> 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>
|
#
b838cbee |
|
03-Feb-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Remove bogus locking check in the hangcheck code You can _never_ assert that a lock is not held, except in some very restricted corner cases where it's guranteed that your code is running single-threade (e.g. driver load before you've published any pointers leading to that lock). In addition the early return breaks a bunch of testcases since with highly concurrent hangcheck stress tests the reset fails to work and the test doesn't recover and time out. This regression has been introduced in commit b8d24a06568368076ebd5a858a011699a97bfa42 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Wed Jan 28 17:03:14 2015 +0200 drm/i915: Remove nested work in gpu error handling Aside: It is possible to check whether a given task doesn't hold a lock, but only when lockdep is enabled, using the lockdep_assert_held stuff. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908 Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
b8d24a06 |
|
28-Jan-2015 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Remove nested work in gpu error handling Now when we declare gpu errors only through our own dedicated hangcheck workqueue there is no need to have a separate workqueue for handling the resetting and waking up the clients as the deadlock concerns are no more. The only exception is i915_debugfs::i915_set_wedged, which triggers error handling through process context. However as this is only used through test harness it is responsibility for test harness not to introduce hangs through both debug interface and through hangcheck mechanism at the same time. Remove gpu_error.work and let the hangcheck work do the tasks it used to. v2: Add a big warning sign into i915_debugfs::i915_set_wedged (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
737b1506 |
|
26-Jan-2015 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert hangcheck from a timer into a delayed work item When run as a timer, i915_hangcheck_elapsed() must adhere to all the rules of running in a softirq context. This is advantageous to us as we want to minimise the risk that a driver bug will prevent us from detecting a hung GPU. However, that is irrelevant if the driver bug prevents us from resetting and recovering. Still it is prudent not to rely on mutexes inside the checker, but given the coarseness of dev->struct_mutex doing so is extremely hard. Give in and run from a work queue, i.e. outside of softirq. v2: Use own workqueue to avoid deadlocks (Daniel) Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Remove accidental kerneldoc comment starter, to appease the 0 day builder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b2c5c181 |
|
22-Jan-2015 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Use symbolic irqreturn for ->hpd_pulse Self-explanatory code is better code. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6e3c9717 |
|
15-Jan-2015 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Make intel_crtc->config a pointer To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2d112de7 |
|
15-Jan-2015 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Embedded struct drm_crtc_state in intel_crtc_state And get rid of the duplicate mode structures. This patch was generated with the following semantic patch: @@ @@ struct intel_crtc_state { +struct drm_crtc_state base; + ... -struct drm_display_mode requested_mode; -struct drm_display_mode adjusted_mode; ... } @@ struct intel_crtc_state *state; @@ -state->adjusted_mode +state->base.adjusted_mode @@ struct intel_crtc_state *state; @@ -state->requested_mode +state->base.mode @@ struct intel_crtc_state state; @@ -state.adjusted_mode +state.base.adjusted_mode @@ struct intel_crtc_state state; @@ -state.requested_mode +state.base.mode @@ struct drm_crtc *crtc; @@ -to_intel_crtc(crtc)->config.adjusted_mode +to_intel_crtc(crtc)->config.base.adjusted_mode @@ identifier member; expression E; @@ -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E); +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E); @@ identifier member; @@ -PIPE_CONF_CHECK_I(adjusted_mode.member); +PIPE_CONF_CHECK_I(base.adjusted_mode.member); @@ identifier member; @@ -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member); +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member); v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
778eb334 |
|
09-Jan-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove I915_HAS_HOTPLUG() check from i915_hpd_irq_setup() The dev_priv->display.hpd_irq_setup hook is optional, so we can move the I915_HAS_HOTPLUG() check out of i915_hpd_irq_setup() and only set up the hook when hotplug support is present. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7c7e10db |
|
09-Jan-2015 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make hpd arrays big enough to avoid out of bounds access intel_hpd_irq_handler() walks the passed in hpd[] array assuming it contains HPD_NUM_PINS elements. Currently that's not true as we don't specify an explicit size for the arrays when initializing them. Avoid the out of bounds accesses by specifying the size for the arrays. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f24eeb19 |
|
19-Dec-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: sanitize RPS interrupt mask during GPU idling We apply the RPS interrupt workaround on VLV everywhere except when writing the mask directly during idling the GPU. For consistency do this also there. While at it also extend the code comment about affected platforms. I couldn't reproduce the issue on VLV fixed by this workaround, by removing the workaround from everywhere, while it's 100% reproducible on SNB using igt/gem_reset_stats/ban-ctx-render. So also add a note that it hasn't been verified if the workaround really applies to VLV/CHV. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
59d02a1f |
|
19-Dec-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix HW lockup due to missing RPS IRQ workaround on GEN6 In commit dbea3cea69508e9d548ed4a6be13de35492e5d15 Author: Imre Deak <imre.deak@intel.com> Date: Mon Dec 15 18:59:28 2014 +0200 drm/i915: sanitize RPS resetting during GPU reset we disable RPS interrupts during GPU resetting, but don't apply the necessary GEN6 HW workaround. This leads to a HW lockup during a subsequent "looping batchbuffer" workload. This is triggered by the testcase that submits exactly this kind of workload after a simulated GPU reset. I'm not sure how likely the bug would have triggered otherwise, since we would have applied the workaround anyway shortly after the GPU reset, when enabling GT powersaving from the deferred work. This may also fix unrelated issues, since during driver loading / suspending we also disable RPS interrupts and so we also had a short window during the rest of the loading / resuming where a similar workload could run without the workaround applied. v2: - separate the fix to route RPS interrupts to the CPU on GEN9 too to a separate patch (Daniel) Bisected-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Testcase: igt/gem_reset_stats/ban-ctx-render Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87429 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
7d47559e |
|
17-Dec-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't call intel_prepare_page_flip() multiple times on gen2-4 The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That means if we first call intel_prepare_page_flip() but don't call intel_finish_page_flip(), the next stall check will erroneosly think the page flip was somehow stuck. With enough debug spew emitted from the interrupt handler my 830 hangs when this happens. My theory is that the previous vblank interrupt gets sufficiently delayed that the handler will see the pending bit set in IIR, but ISR still has the bit set as well (ie. the flip was processed by CS but didn't complete yet). In this case the handler will proceed to call intel_check_page_flip() immediately after intel_prepare_page_flip(). It then tries to print a backtrace for the stuck flip WARN, which apparetly results in way too much debug spew delaying interrupt processing further. That then seems to cause an endless loop in the interrupt handler, and the machine is dead until the watchdog kicks in and reboots. At least limiting the number of iterations of the loop in the interrupt handler also prevented the hang. So it seems better to not call intel_prepare_page_flip() without immediately calling intel_finish_page_flip(). The IIR/ISR trickery avoids races here so this is a perfectly safe thing to do. v2: Fix typo in commit message (checkpatch) Cc: stable@vger.kernel.org Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
78e68d36 |
|
15-Dec-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: move RPS PM_IER enabling to gen6_enable_rps_interrupts Paulo noticed that we don't enable RPS interrupts via PM_IER in gen6_enable_rps_interrupts(). This wasn't a problem so far, since the only place we disabled RPS interrupts was during system/runtime suspend and after that we reenable all interrupts in the IRQ pre/postinstall hooks. In the next patch we'll disable/reenable RPS interrupts during GPU reset too, but not call IRQ uninstall, pre/postinstall hooks, so there the above wouldn't work. The logical place for programming PM_IER is gen6_enable_rps_interrupts() and this also makes the function more symmetric with gen6_disable_rps_interrupts(), so move the programming there from the postinstall hooks. Note that these changes don't affect the ILK RPS interrupt code, which could be sanitized in a similar way. But that can be done as a follow-up. Credits-to: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
3f7531c3 |
|
10-Dec-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Name the lrc irq handler correctly We consistently use the _irq_handler postfix for functions called in hardirq context. Especially when it's a non-static function hardirq is a crazy enough calling context to warrant this level of ocd. So rename it. Cc: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Thomas Daniel <thomas.daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
c352d1ba |
|
20-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: fix IRQ masking when uninstalling interrupts irq_mask should include all IRQ bits that we want to mask, but atm we set it incorrectly to the inverse of this. If the mask is used subsequently to enable/disable some IRQ bits, we may unintentionally unmask unrelated IRQs. I can't see any way that this can lead to a real problem in the current -nightly code, since the first place the mask will be used next (after a suspend/resume cycle) is in valleyview_irq_postinstall(), but the mask is reset there to its proper value. This causes a problem in the upstream kernel though, where - due to another issue - the mask is used in the above way to disable only the display IRQs. This other issue is fixed by: commit 950eabaf5a87257040e0c207be09487954113f54 Author: Imre Deak <imre.deak@intel.com> Date: Mon Sep 8 15:21:09 2014 +0300 drm/i915: vlv: fix display IRQ enable/disable Interestingly, even with the above two bugs, we shouldn't in theory have any real problems (arguably a famous last sentence:). That's because even if we unmask something unintentionally via the VLV_IMR/VLV_IER register the master IRQ masking bit in VLV_MASTER_IER is still set and should prevent all i915 interrupts. According to my testing on an ASUS T100 with DSI output this isn't the case at least with the MIPIA_INTERRUPT. Leaving this one unmasked in IMR/IER, while having VLV_MASTER_IER set to 0 may lead to a lockup during system suspend as shown in the bugzilla ticket below. This fix should get rid of the problem reported there in upstream and older kernels. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85920 Cc: stable@vger.kernel.org (v3.15+) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
15a17aae |
|
08-Dec-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Check mask/bit helper functions After a bit of irc discussion we've concluded that it would be prudent to check that callers use the mask/enable paramters correctly. So add a WARN_ON. Spurred by Damien's bugfix which added _MASKED_FIELD. v2: We use WARN_ON(1) a lot to catch default cases in switch blocks which should always be extended. So this doesn't work really. Dunno why gcc only started complaining when I've moved the WARN out of the static inline helper to address a feedback from Jani. Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
bcfcc8ba |
|
05-Dec-2014 |
John Harrison <John.C.Harrison@Intel.com> |
drm/i915: Additional request structure tracing Added the request structure's 'uniq' identifier to the trace information. Also renamed the '_complete' trace event to '_notify' as it actually happens in the IRQ 'notify_ring()' function. The intention is to add a new '_complete' trace event which occurs when a request structure is actually marked as complete. However, at the moment the completion status is re-tested every time the query is made so there isn't a completion event as such. v2: New patch added to series. v3: Rebased to remove completion caching as that is apparently contentious. Change-Id: Ic9bcde67d175c6c03b96217cdcb6e4cc4aa45d67 For: VIZ-4377 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1b5a433a |
|
24-Nov-2014 |
John Harrison <John.C.Harrison@Intel.com> |
drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed' Almost everywhere that caled i915_seqno_passed() was really asking 'has the given seqno popped out of the hardware yet?'. Thus it had to query the current hardware seqno and then do a signed delta comparison (which copes with wrapping around zero but not with seqno values more than 2GB apart, although the latter is unlikely!). Now that the majority of seqno instances have been replaced with request structures, it is possible to convert this test to be request based as well. There is now a 'i915_gem_request_completed()' function which takes a request and returns true or false as appropriate. Note that this currently just wraps up the original _passed() test but a later patch in the series will reduce this to simply returning a cached internal value, i.e.: _completed(req) { return req->completed; }' This checkin converts almost all _seqno_passed() calls. The only one left is in the semaphore code which still requires seqnos not request structures. For: VIZ-4377 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com> [danvet: Drop hunk touching the trace_irq code since I've dropped the patch which converts that, and resolve resulting conflict.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
44cdd6d2 |
|
24-Nov-2014 |
John Harrison <John.C.Harrison@Intel.com> |
drm/i915: Convert 'ring_idle()' to use requests not seqnos More seqno value to request structure conversions. Note, this change temporarily moves the 'get_seqno()' call inside ring_idle() but this will disappear again in a later patch when i915_seqno_passed() itself is converted. For: VIZ-4377 Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9939fba2 |
|
20-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: mask RPS IRQs properly when disabling RPS Atm, igt/gem_reset_stats can trigger the recently added WARN on left-over PM_IIR bits in gen6_enable_rps_interrupts(). There are two reasons for this: 1. we call intel_enable_gt_powersave() without a preceeding intel_disable_gt_powersave() 2. gen6_disable_rps_interrupts() doesn't mask interrupts in PM_IMR 1. means RPS interrupts will remain enabled and can be serviced during the HW initialization after a GPU reset. 2. means even if we called gen6_disable_rps_interrupts() any new RPS interrupt during RPS initialization would still propagate to PM_IIR too early (though wouldn't be serviced). This patch solves the 2. issue by also masking interrupts in PM_IMR, the following patch fixes 1. getting rid of the WARN. This also makes intel_enable_gt_powersave() and intel_disable_gt_powersave() more symmetric. Since gen6_disable_rps_interrupts() is called during driver loading with i915 interrupts disabled add a new version of gen6_disable_pm_irq() that doesn't WARN for this. Also while at it, get the irq_lock around the whole PM_IMR/IER/IIR programming sequence and make sure that any queued PM_IIR bit is also cleared. The WARN was caught by PRTS after I sent my previous RPS sanitizing patchset and I could easily reproduce it on HSW. To actually fix it we also need the next patch. Reported-by: He, Shuang <shuang.he@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
34273620 |
|
26-Nov-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Tune down spurious CRC interrupt warning We don't really synchronously turn them off from debugfs. We try to avoid hitting them too badly by waiting one vblank, but apparently the irq handler can still race through that gap. Since this isn't really all that important for testcases, only for debugging CRC issues let's tune it down to a debug message. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82602 Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
7514747d |
|
24-Nov-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Grab modeset locks for GPU rest on pre-ctg On gen4 and earlier the GPU reset also resets the display, so we should protect against concurrent modeset operations. Grab all the modeset locks around the entire GPU reset dance, remebering first ti dislogde any pending page flip to make sure we don't deadlock. Any pageflip coming in between these two steps should fail anyway due to reset_in_progress, so this should be safe. This fixes a lot of failed asserts in the modeset code when there's a modeset racing with the reset. Naturally the asserts aren't happy when the expected state has disappeared. v2: Drop UMS checks, complete pending flips after the reset (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
aaecdf61 |
|
04-Nov-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Stop gathering error states for CS error interrupts There's quite a few bug reports with error states where the error reasons makes just about no sense at all. Like dying on tlbs for a display plane that's not even there. Also users don't really report a lot of bad side effects generally, just the error states. Furthermore we don't even enable these interrupts any more on gen5+ (though the handling code is still there). So this mostly concerns old platforms. Given all that lets make our lives a bit easier and stop capturing error states, in the hopes that we can just ignore them. In case that's not true and the gpu indeed dies the hangcheck should eventually kick in. And I've left some debug log in to make this case noticeble. Referenced bug is just an example. v2: Fix missing \n Jani spotted. References: https://bugs.freedesktop.org/show_bug.cgi?id=82095 References: https://bugs.freedesktop.org/show_bug.cgi?id=85944 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d9e600b2 |
|
20-Nov-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only call mod_timer() if not already pending The final arrangement of updating timer->expires and calling mod_timer() used in commit 672e7b7c1849c904b2c55185906b3940843c55c6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 19 09:47:19 2014 +0000 drm/i915: Don't continually defer the hangcheck turns out to be very unsafe. Try again. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5c6c6003 |
|
06-Sep-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove DRI1 ring accessors and API With the deprecation of UMS, and by association DRI1, we have a tough choice when updating the ring access routines. We either rewrite the DRI1 routines blindly without testing (so likely to be broken) or take the liberty of declaring them no longer supported and remove them entirely. This takes the latter approach. v2: Also remove the DRI1 sarea updates Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fix rebase conflicts.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d4d70aa5 |
|
19-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: sanitize rps irq disabling When disabling the RPS interrupts there is a tricky dependency between the thread disabling the interrupts, the RPS interrupt handler and the corresponding RPS work. The RPS work can reenable the interrupts, so there is no straightforward order in the disabling thread to (1) make sure that any RPS work is flushed and to (2) disable all RPS interrupts. Currently this is solved by masking the interrupts using two separate mask registers (first level display IMR and PM IMR) and doing the disabling when all first level interrupts are disabled. This works, but the requirement to run with all first level interrupts disabled is unnecessary making the suspend / unload time ordering of RPS disabling wrt. other unitialization steps difficult and error prone. Removing this restriction allows us to disable RPS early during suspend / unload and forget about it for the rest of the sequence. By adding a more explicit method for avoiding the above race, it also becomes easier to prove its correctness. Finally currently we can hit the WARN in snb_update_pm_irq(), when a final RPS work runs with the first level interrupts already disabled. This won't lead to any problem (due to the separate interrupt masks), but with the change in this and the next patch we can get rid of the WARN, while leaving it in place for other scenarios. To address the above points, add a new RPS interrupts_enabled flag and use this during RPS disabling to avoid requeuing the RPS work and reenabling of the RPS interrupts. Since the interrupt disabling happens now in intel_suspend_gt_powersave(), we will disable RPS interrupts explicitly during suspend (and not just through the first level mask), but there is no problem doing so, it's also more consistent and allows us to unify more of the RPS disabling during suspend and unload time in the next patch. v2/v3: - rebase on patch "drm/i915: move rps irq disable one level up" in the patchset Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3cc134e3 |
|
19-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: sanitize rps irq enabling Atm we first enable the RPS interrupts then we clear any pending ones. By this we could lose an interrupt arriving after we unmasked it. This may not be a problem as the caller should handle such a race, but logic still calls for the opposite order. Also we can delay enabling the interrupts until after all the RPS initialization is ready with the following order: 1. disable left-over RPS (earlier via intel_uncore_sanitize) 2. clear any pending RPS interrupts 3. initialize RPS 4. enable RPS interrupts This also allows us to do the 2. and 4. step the same way for all platforms, so let's follow this order to simplifying things. Also make sure any queued interrupts are also cleared. v2: - rebase on the GEN9 patches where we don't support RPS yet, so we musn't enable RPS interrupts on it (Paulo) v3: - avoid enabling RPS interrupts on GEN>9 too (Paulo) - clarify the RPS init sequence in the log message (Chris) - add POSTING_READ to gen6_reset_rps_interrupts() (Paulo) - WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts() (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4a74de82 |
|
19-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: WARN if we receive any rps interrupts on gen>9 This extends commit 132f3f1767dbabfb01f3c9bd63098c65d91eeac9 Author: Imre Deak <imre.deak@intel.com> Date: Mon Nov 10 15:34:33 2014 +0200 drm/i915: WARN if we receive any gen9 rps interrupts to GEN>9 platforms as suggested by Paulo. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
672e7b7c |
|
19-Nov-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Don't continually defer the hangcheck With multiple rings, we may continue to render on the blitter whilst executing an infinite shader on the render ring. As we currently, rearm the timer with each execbuf, in this scenario the hangcheck will never fire and we will never detect the lockup on the render ring. Instead, only arm the timer once per hangcheck, so that hangcheck runs more frequently. v2: Rearrange code to avoid triggering a BUG_ON in add_timer from softirq context. Testcase: igt/gem_reset_stats/defer-hangcheck* Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86225 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c2b66797 |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use vlv display irq setup code for chv Throw away the hand rolled display irq setup code on chv, and instead just call vlv_display_irq_postinstall() and vlv_display_irq_uninstall(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8ea0be4f |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Refactor vlv_display_irq_uninstall() Pull the vlv display irq uninstall code into a separate function, for eventual sharing with chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
88e04703 |
|
13-Nov-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915/skl: AUX irqs have moved Use the new AUX port irq bits where needed. v2: Rebase on top of upstream changes v3: Rebase on top of Oscar change to write IIR as soon as possible (Damien) v4: Rebase on top of the for_each_pipe() change adding dev_priv as first argument (Damien) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
132f3f17 |
|
10-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: WARN if we receive any gen9 rps interrupts Paulo noticed that we don't support RPS on GEN9 yet, so WARN for and ignore any RPS interrupts on that platform. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b900b949 |
|
05-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: move rps irq enable/disable to i915_irq.c The logical place for these functions is in i915_irq.c next to the rest of PM interrupt handling functions. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c9a9a268 |
|
05-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: unify gen6/gen8 rps irq handler After the previous patch the GEN8 RPS handler became very similar to the GEN6 version, so unify the two functions. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Move one misplaced hunk from a later patch to fix a bisect issue as reported by Wu Fengguang's 0-day builder and fix suggested by Imre.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a72fbc3a |
|
05-Nov-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: unify gen6/gen8 pm irq helpers The helpers to enable/disable PM IRQs for GEN6 and GEN8 are the same except for the PM interrupt mask register, so abstract away this register in the GEN6 versions and use these everywhere. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
536f5b5e |
|
06-Nov-2014 |
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> |
drm/i915: Make mmio flip wait for seqno in the work function This simplifies the code quite a bit compared to iterating over all rings during the ring interrupt. Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip struct is only accessed in two places. The first is when the flip is queued and the other when the mmio writes are done. Since a flip cannot be queued while there is a pending flip, the two paths shouldn't ever run in parallel. We might need to revisit that if support for replacing flips is implemented though. v2: Don't hold dev->struct_mutext while waiting (Chris) v3: Make the wait uninterruptable (Chris) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5eba929d |
|
31-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill leftover GTIIR writes from valleyview_irq_preinstall() There are two leftover GTIIR writes in valleyview_irq_preinstall(). Looks like the were originally left behind by: commit d18ea1b58a5003eb6fca03aff03c4c01321e6cb1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 12 22:43:25 2013 +0200 drm/i915: unify PM interrupt preinstall sequence and then the GTIIR reset was added back here: commit f86f3fb005d0c907285fa8685badcb24ec31ee59 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Apr 1 15:37:14 2014 -0300 drm/i915: properly clear IIR at irq_uninstall on Gen5+ so we can kill the leftovers from the vlv code. Cc: Paulo Zanoni <przanoni@gmail.com> Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9b2e8c94 |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop useless VLV_IIR writes from vlv_display_irq_postinstall() The extra VLV_IIR writes at the end of vlv_display_irq_postinstall() serve no purpose. Remove them. The VLV_IMR/IER/IIR setup at the start of the function also seems a bit pointless since it doesn't unmask/enable anything. But leave it be for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0e6c9a9e |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i914: Refactor vlv_display_irq_postinstall() Split the vlv display irq postinstall code to a separate function so that we can share it with chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
70591a41 |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Refactor vlv_display_irq_reset() Pull the vlv display irq reset code to a new functions. The aim is to share the code with chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
120dda4f |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make valleyview_display_irqs_(un)install() work for chv Genralize valleyview_display_irqs_install() and valleyview_display_irqs_uninstall() enough so that they work on chv. The only difference to vlv here being the third pipe that chv brings. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
893fce8e |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Call gen5_gt_irq_reset() from valleyview_irq_uninstall() Looks like we forgot to call gen5_gt_irq_reset() for vlv in the uninstall phase. Do so. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
23a09c76 |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use GEN5_IRQ_RESET() on vlv/chv Replace the hand rolled IIR,IER,IMR disable sequences with GEN5_IRQ_RESET(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
76e41860 |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use a consistent order between IIR, IER, IMR writes on vlv/chv Follow the same ordering rules for the IIR,IER,IMR writes on vlv/chv that we do on other gen5+ platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8e20599a |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop the extra GEN8_PCU_IIR posting read from cherryview_irq_preinstall() Looks like a leftover POSTING_READ(GEN8_PCU_IIR) in cherryview_irq_preinstall() from some earlier age. GEN5_IRQ_RESET() already does the posting read so this changes nothing, so kill it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a2c30fba |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use gen8_gt_irq_reset() in cherryview_irq_uninstall() Replace the hand rolled macros with gen8_gt_irq_reset() and GEN5_IRQ_RESET() in cherryview_irq_uninstall(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7c4cde39 |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use DPINVGTT_STATUS_MASK Some has given a name for the DPINVGTT status bitmask, so let's use it instead of the magic number. Looks more like the chv code now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7d1bd539 |
|
30-Oct-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Apply some ocd for IMR vs. IER order during irq enable When disabling interrupts we do the writes in this order: IMR,IER,IIR,IIR. But when enabling interrupts we don't do use the mirrored order, and instead do IIR,IIR,IMR,IER. I like consistency unless there's a good reason against it, which I can't think of here, so change the enable order to IIR,IIR,IER,IMR. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0f239f4c |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Filter gmch fifo underruns in the shared handler This simplifies the code in the vlv irq handler. Also this now means that we correctly filter underruns on gen2-4. And as the real upshot I need to document one less function for the fifo underrun code. v2: Shorten one long line. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1f7247c0 |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Add wrappers to handle fifo underrun interrupts Way too much copypasta all over. And this also clarifies a bit what's going on since it separates the "do we have an underrun irq" from the "should we report the underrun" check. v2: Fix excessively long lines. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
a72e4c9f |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Use dev_priv in public intel_fifo_underrun.c functions It's the new rule! Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
47339cd9 |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Extract intel_fifo_underrun.c Prep work for some nice documentation. Requires that we export the display irq enable/disable functions on ilk/ibx. But we already export them for vlv/i915. So not more inconsistency. v2: Rebase on top of skl stage 1. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
07c338ce |
|
02-Oct-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: fix short vs. long hpd detection Fix short vs. long hpd detection for non-g4x and non-pch split platforms. Broken since introduction in commit 13cf550448b58abf8f44f5d6a560f2d20871c965 Author: Dave Airlie <airlied@redhat.com> Date: Wed Jun 18 11:29:35 2014 +1000 drm/i915: rework digital port IRQ handling (v2) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83175 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
1180e206 |
|
07-Oct-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: properly reenable gen8 pipe IRQs We were missing the pipe B/C vblank bits! Take a look at gen8_de_irq_postinstall for a comparison. This should fix a bunch of IGT tests. There are a few more things we could improve on this code, but this should be the minimal fix to unblock us. v2: s/extra_iir/extra_ier/ because IIR doesn't make sense (Ville) Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=83640 Testcase: igt/* Cc: stable@vger.kernel.org Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
fca52a55 |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: kerneldoc for interrupt enable/disable functions Just start with the basics for now. Since there's a lot of different functionality in i915_irq.c I've decided to split it into different sections and pull in just the relevant functions. Splitting into different files looks like a lot more work since the interrupt handlers do an awful lot of reuse all over. v2: Rebase onto changed function names. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b963291c |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Use dev_priv instead of dev in irq setup functions It's the new world order! Not going full monty on these here and rolling this out throughout the subsequent call chains since this is just for the kerneldoc. Later on we can go more crazy, especially once we've embedded drm_device correctly. v2: Also frob the runtime_pm functions ... Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2aeb7d3a |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: s/pm._irqs_disabled/pm.irqs_enabled/ Double negations just parse harder. Also this allows us to ditch some init code since clearing to 0 dtrt. Also ditch the assignment in intel_pm_setup, that's not redundant since we do the assignement now while setting up interrupts. While at it do engage in a bit of OCD and wrap up the few lines of setup/teardown code into little helper functions: intel_irq_fini for cleanup and intel_irq_init_hw for hw setup. v2: Use _install/_uninstall for the new wrapper function names as Paulo suggested. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f458ebbc |
|
30-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Bikeshed rpm functions name a bit. - fini goes with init, so call it intel_power_domains_fini. While at it shovel some of the fini code that leaked out of it back in. - give power_enabled functions the verb _is_ to make the meaning clearer. Also use a __ prefix instead of _unlocked to really discourage users. - rename runtime_pm_init/fini to enable/disable since that's what they do. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7526ed79 |
|
29-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
Revert "drm/i915/bdw: BDW Software Turbo" This reverts commit c76bb61a71083b2d90504cc6d0dda2047c5d63ca. It's apparently too broken so that Rodrigo submitted a patch to add a config option for it. Given that the design is also ... suboptimal and that I've only merged this to get lead engineers and managers off my back for one second let's just revert this. /me puts on combat gear again It was worth a shot ... References: http://mid.mail-archive.com/1411686380-1953-1-git-send-email-rodrigo.vivi@intel.com Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Daisy Sun <daisy.sun@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
#
770de83d |
|
20-Mar-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Adjust the display engine interrupts To accomodate the extra planes, the bit definitions were shuffled around a bit. v2: Rebase on top of the for_each_pipe() change adding dev_priv as first argument. v3: Rebase after yet another change int that area (done with wiggle) Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a440ca6f |
|
04-Jun-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: SKL shares the same underrun interrupt as BDW Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8a8b009d |
|
08-Apr-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915/skl: Skylake shares the interrupt logic with Broadwell Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
13321786 |
|
15-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Clarify irq_lock locking, special cases Grab bag for all the special cases: - i9xx_check_fifo_underruns is only called from crtc_enable hooks, i.e. process context. - i915_enable_asle_pipestat is only called from interrupt postinstall hooks. So again process context. - gen8_irq_power_well_post_enable is called from the runtime pm code, which again means process context. - The open-coded hpd_irq_setup loop in _thaw is also running in process context. So for all of them the plain _irq variant is sufficient. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
222c7f51 |
|
15-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Clarify irq_lock locking, irq handlers irq handlers always run with interrupts locally disabled, so plain spinlocks is all we need. I've also reviewed again that they all follow the _irq_handler postfix convention. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d6207435 |
|
15-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Clarify irq_lock locking, interrupt install/uninstall All the interrupt setup/teardown hooks are always run from plain process context. So again just the _irq variant is good enough. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4cb21832 |
|
15-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Clarify irq_lock locking, work functions Work functions are in process context, so plain _irq spinlock variants is all we need. The hpd reenable work didn't follow the _work/_work_func postfix naming scheme, so adjust that while at it. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
950eabaf |
|
08-Sep-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: fix display IRQ enable/disable We want to enable/disable display IRQs only if global i915 IRQs are enabled. To check the latter it's not enough to consult the DRM dev->irq_enabled flag, since runtime PM can disable/enable IRQs and it won't adjust this flag only the i915 specific dev_priv->pm._irqs_disabled flag. Fix this by using the proper intel_irqs_enabled() helper instead. Fortunately this didn't cause an actual problem since even if we enabled display IRQs too early (before enabling global i915 IRQs) the VLV_MASTER_IER would still be clear masking all IRQs. This issue was caught by commit 920dd15a2b2fc60d054646a8a1ffd6aeb6090e05 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 27 10:43:37 2014 +0200 drm/i915: WARN if interrupts aren't on in en/disable_pipestat Signed-off-by: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d518ce50 |
|
27-Aug-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: WARN if interrupts aren't on in en/disable_pipestat Now that vlv has runtime pm we kinda should check for that like on the pch split platforms. Looks like this was simply lost in the vlv rpm enabling. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3d3cbd84 |
|
10-Sep-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm: Clarify vblank ts/scanoutpos sampling #defines I've read INVBL as "invalid backlight" and got mightly confused. The #defines are already fairly long and we can afford to extend them a bit more without resulting in ugly code all over. I'm not sure how useful the complicated bitmask return value of these functions really are since no one checks them. But for now let's keep things as is. Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d6bbafa1 |
|
05-Sep-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Check for a stalled page flip after each vblank Long ago, back in the racy haydays of 915gm interrupt handling, page flips would occasionally go astray and leave the hardware stuck, and the display not updating. This annoyed people who relied on their systems being able to display continuously updating information 24/7, and so some code to detect when the driver missed the page flip completion signal was added. Until recently, it was presumed that the interrupt handling was now flawless, but once again Simon Farnsworth has found a system whose display will stall. Reinstate the pageflip stall detection, which works by checking to see if the hardware has been updated to the new framebuffer address following each vblank. If the hardware is scanning out from the new framebuffer, but we still think the flip is pending, then we kick our driver into submision. This is a continuation of the effort started with commit 4e5359cd053bfb7d8dabe4a63624a5726848ffbc Author: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Date: Wed Sep 1 17:47:52 2010 +0100 drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt This now includes a belt-and-braces approach to make sure the driver (or the hardware) doesn't miss an interrupt and cause us to stop updating the display should the unthinkable happen and the pageflip fail - i.e. that the user is able to continue submitting flips. v2: Cleanup, refactor, and rename v3: Only start counting vblanks after the flip command has been seen by the hardware. v4: Record the seqno after we touch the ring, or else there may be no seqno allocated yet. v5: Rebase on mmio-flip. v6: Rebase, rebase. Reported-by: Simon Farnsworth <simon@farnz.org.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75502 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [v4] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a3ed6aad |
|
03-Sep-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use HAS_GMCH_DISPLAY un underrun reporting code A few open coded HAS_GMCH_DISPLAY() remain in the underrun reporting code. Convert them over. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6c65a587 |
|
29-Aug-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't use WaGsvRC0ResidenncyMethod on chv WaGsvRC0ResidenncyMethod is for vlv, it doesn't deal with chv appropriately (eg. doesn't limit rps values to even numbers). Fix a typo in the w/a name while at it. Cc: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c76bb61a |
|
11-Aug-2014 |
Daisy Sun <daisy.sun@intel.com> |
drm/i915/bdw: BDW Software Turbo BDW supports GT C0 residency reporting in constant time unit. Driver calculates GT utilization based on C0 residency and adjusts RP frequency up/down accordingly. For offscreen workload specificly, set frequency to RP0. Offscreen task is not restricted by frame rate, it can be executed as soon as possible. Transcoding and serilized workload between CPU and GPU both need high GT performance, RP0 is a good option in this case. RC6 will kick in to compensate power consumption when GT is not active. v2: Rebase on recent drm-intel-nightly v3: Add flip timerout monitor, when no flip is deteced within 100ms, set frequency to RP0. Signed-off-by: Daisy Sun <daisy.sun@intel.com> [torourke: rebased on latest and resolved conflict] Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9a2d2d87 |
|
21-Aug-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915: Fix to Enable GT/PM Interrupts Programing GT IER interrupts was fumbled while enabling Interrupts for gen8 We forgot to program PM IER interrupt in gen8_gt_irq_postinstall based on the new re-worked interrupt routines. v2: Kill the loop and init GT interrupts individually (Ville) Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Adjust commit message as per discussion with Deepak.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
055e393f |
|
18-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Use dev_priv as first argument of for_each_pipe() Chris has decided that enough is enough. It's time to fixup dev Vs dev_priv. This is a modest contribution to the crusade. v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode the info struct with defines (Chris) Rename the macro argument from 'dev' to 'dev_priv' (Jani) v3: Use names unlikely to be used as macro arguments (Chris) Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6323751d |
|
18-Aug-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix HPD IRQ reenable work cancelation Atm, the HPD IRQ reenable timer can get rearmed right after it's canceled. Also to access the HPD IRQ mask registers we need to wake up the HW. Solve both issues by converting the reenable timer to a delayed work and grabbing a runtime PM reference in the work. By this we can also forgo canceling the timer during runtime suspend, since the only important thing there is that the HW is awake when we write the registers and that's ensured by the RPM ref. So do the cancelation only during driver unload time; this is also a requirement for an upcoming patch where we want to cancel all HPD related works only during system suspend and driver unload time, but not during runtime suspend. Note that there is still a race between the HPD IRQ reenable work and drm_irq_uninstall() during driver unload, where the work can reenable the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since the HPD IRQs will still be effectively masked by the first level interrupt mask. v2-3: - unchanged v4: - use proper API for changing the expiration time for an already pending delayed work (Jani) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Cc: stable@vger.kernel.org (3.16+) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
e981e7b1 |
|
24-Jul-2014 |
Thomas Daniel <thomas.daniel@intel.com> |
drm/i915/bdw: Handle context switch events Handle all context status events in the context status buffer on every context switch interrupt. We only remove work from the execlist queue after a context status buffer reports that it has completed and we only attempt to schedule new contexts on interrupt when a previously submitted context completes (unless no contexts are queued, which means the GPU is free). We canot call intel_runtime_pm_get() in an interrupt (or with a spinlock grabbed, FWIW), because it might sleep, which is not a nice thing to do. Instead, do the runtime_pm get/put together with the create/destroy request, and handle the forcewake get/put directly. Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> v2: Unreferencing the context when we are freeing the request might free the backing bo, which requires the struct_mutex to be grabbed, so defer unreferencing and freeing to a bottom half. v3: - Ack the interrupt inmediately, before trying to handle it (fix for missing interrupts by Bob Beckett <robert.beckett@intel.com>). - Update the Context Status Buffer Read Pointer, just in case (spotted by Damien Lespiau). v4: New namespace and multiple rebase changes. v5: Squash with "drm/i915/bdw: Do not call intel_runtime_pm_get() in an interrupt", as suggested by Daniel. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Checkpatch ...] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
73d477f6 |
|
24-Jul-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/bdw: Interrupts with logical rings We need to attend context switch interrupts from all rings. Also, fixed writing IMR/IER and added HWSTAM at ring init time. Notice that, if added to irq_enable_mask, the context switch interrupts would be incorrectly masked out when the user interrupts are due to no users waiting on a sequence number. Therefore, this commit adds a bitmask of interrupts to be kept unmasked at all times. v2: Disable HWSTAM, as suggested by Damien (nobody listens to these interrupts, anyway). v3: Add new get/put_irq functions. Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> (v1) Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> (v2 & v3) Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Drop the GEN8_ prefix from the context switch interrupt define and move it to its brethren.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
26fbb774 |
|
11-Aug-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make hpd debug messages less cryptic Don't print raw numbers, use port_name() and tell the user whether it's long or short without having to figure out what the other magic number means. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4fa79042 |
|
08-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Fix erroneous conversion to u8 adj was defined as u8. The issue is last_adj can be negative and adj is initialized with: adj = dev_priv->rps.last_adj; and we were also happily doing things like: if (adj < 0) (thank static analysers!) v2: Make new_delay an int in case we overflow the u8 in the intermediate computations. new_delay will get clamped at the end anyway. (Ville) Cc: Deepak S <deepak.s@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b2784e15 |
|
05-Aug-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Introduce a for_each_intel_encoder() macro Following the established idom, let's provide a macro to iterate through the encoders. spatch helps, once more, for the substitution: @@ iterator name list_for_each_entry; iterator name for_each_intel_encoder; struct intel_encoder * encoder; struct drm_device * dev; @@ -list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head) { +for_each_intel_encoder(dev, encoder) { ... } I also modified a few call sites by hand where a pointer to mode_config was directly used (to avoid overflowing 80 chars). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Wrap paramters correctly in the macro and remove spurious space checkpatch noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
06ffc778 |
|
17-Jul-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
d rm/i915: freeze display before the interrupts and GT Since we started using intel_runtime_pm_disable_interrupts() at normal (non-runtime) suspend/resume, we had to remove a WARN from ironlake_disable_display_irq to avoid a case where we were doing the correct thing and the WARN was not really needed. The problem is that the WARN was useful in other cases, and its removal can hide some bugs that we would catch automatically. To be able to add back the WARN, we have to call intel_crtc_control() before interrupts are disabled, which is what this patch currently does. Also notice that Ville's patch from the Watermarks series "drm/i915: Leave interrupts enabled while disabling crtcs during suspend" also did a change that's equivalent to the one we're doing on this patch, with the exception that its original patch, when applied to the current tree, procduces a WARN. Related commits: commit daa390e5ee45cc051d6bf37b296901f2f92b002d Author: Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: don't warn if IRQs are disabled when shutting down display IRQs commit e11aa362308f5de467ce355a2a2471321b15a35c Author: Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: use runtime irq suspend/resume in freeze/thaw Note that the function part of this patch has already been done in commit 0e32b39ceed665bfa4a77a4bc307b6652b991632 Author: Dave Airlie <airlied@redhat.com> Date: Fri May 2 14:02:48 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) with the fixup commit 09b64267c1f72f2670fcde9f11e5453ce365ca23 Author: Dave Airlie <airlied@redhat.com> Date: Wed Jul 23 14:25:24 2014 +1000 drm/i915: don't suspend gt until after we disable irqs and display (v2) so all that's left from Paulo's patch is reinstating the WARNING. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Explain conflict resolution with Dave's DP MST patches with a note in the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
210871b6 |
|
22-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill intel_crtc->vbl_wait Share the waitqueue that drm_irq uses when performing the vblank evade trick for atomic pipe updates. v2: Keep intel_pipe_handle_vblank() (Chris) Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f260fe7b |
|
05-Aug-2014 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Don't accumulate hangcheck score on forward progress If the actual head has progressed forward inside a batch (request), don't accumulate hangcheck score. As the hangcheck score in increased only by acthd jumping backwards, the result is that we only declare an active batch as stuck if it is trapped inside a loop. Or that the looping will dominate the batch progression so that it overcomes the bonus that forward progress gives. v2: Improved commit message (Chris Wilson) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: s/active_loop/active (loop)/ as requested by Chris.] Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
21da2700 |
|
06-Aug-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Opt out of vblank disable timer on >gen2 Now that the vblank races are plugged, we can opt out of using the vblank disable timer and just let vblank interrupts get disabled immediately when the last reference is dropped. Gen2 is the exception since it has no hardware frame counter. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
95f25bed |
|
20-Jun-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: set pm._irqs_disabled at IRQ init time Before we've installed the handler, we can set this and avoid confusing init code that then thinks IRQs are enabled and spews complaints everywhere. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9df7575f |
|
20-Jun-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: add helper for checking whether IRQs are enabled Now that we use the runtime IRQ enable/disable functions in our suspend path, we can simply check the pm._irqs_disabled flag everywhere. So rename it to catch the users, and add an inline for it to make the checks clear everywhere. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9a76e495 |
|
20-Jun-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: don't warn if IRQs are disabled when shutting down display IRQs This was always the case on our suspend path, but it was recently exposed by the change to use our runtime IRQ disable routine rather than the full DRM IRQ disable. Keep the warning on the enable side, as that really would indicate a bug. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d49bdb0e |
|
04-Jul-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: extract and improve gen8_irq_power_well_post_enable Move it from hsw_power_well_post_enable() (intel_pm.c) to i915_irq.c so we can reuse the nice IRQ macros we have there. The main difference is that now we're going to check if the IIR register is non-zero when we try to re-enable the interrupts. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
813bde43 |
|
04-Jul-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't write powered down IRQ registers on Gen 8 If we enable unclaimed register reporting on Gen 8, we will discover that the IRQ registers for pipes B and C are also on the power well, so writes to them when the power well is disabled result in unclaimed register errors. Also, hsw_power_well_post_enable() already takes care of re-enabling them once the power well is enabled. Testcase: igt/pm_rpm/rte Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
480c8033 |
|
16-Jul-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Use genX_ prefix for gt irq enable/disable functions Traditionally we use genX_ for GT/render stuff and the codenames for display stuff. But the gt and pm interrupt handling functions on gen5/6+ stuck out as exceptions, so convert them. Looking at the diff this nicely realigns our ducks since almost all the callers are already platform-specific functions following the genX_ pattern. Spotted while reviewing some internal rps patches. No function change in this patch. Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6af257cd |
|
15-Jul-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: PM irq enabling is generic on gen8, too No need to list all the platforms explicitly. The prefix is a bit inconsistent since we usually pick gen8_ for GT related functions. But this anti-pattern is already established with snb, so material for a different patch. Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0e32b39c |
|
01-May-2014 |
Dave Airlie <airlied@redhat.com> |
drm/i915: add DP 1.2 MST support (v0.7) This adds DP 1.2 MST support on Haswell systems. Notes: a) this reworks irq handling for DP MST ports, so that we can avoid the mode config locking in the current hpd handlers, as we need to process up/down msgs at a better time. Changes since v0.1: use PORT_PCH_HOTPLUG to detect short vs long pulses add a workqueue to deal with digital events as they can get blocked on the main workqueue beyong mode_config mutex fix a bunch of modeset checker warnings acks irqs in the driver cleanup the MST encoders Changes since v0.2: check irq status again in work handler move around bring up and tear down to fix DPMS on/off use path properties. Changes since v0.3: updates for mst apis more state checker fixes irq handling improvements fbcon handling support improved reference counting of link - fixes redocking. Changes since v0.4: handle gpu reset hpd reinit without oopsing check link status on HPD irqs fix suspend/resume Changes since v0.5: use proper functions to get max link/lane counts fix another checker backtrace - due to connectors disappearing. set output type in more places fro, unknown->displayport don't talk to devices if no HPD asserted check mst on short irqs only check link status properly rebase onto prepping irq changes. drop unsued force_act Changes since v0.6: cleanup unused struct entry. [airlied: fix some sparse warnings]. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a0d036b0 |
|
18-Jul-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reorder the semaphore deadlock check, again commit 4be173813e57c7298103a83155c2391b5b167b4c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 6 10:22:29 2014 +0100 drm/i915: Reorder semaphore deadlock check did the majority of the work, but it missed one crucial detail: The check for the unkickable deadlock on this ring must come after the check whether the ring that we are waiting on has already passed its target seqno. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80709 Tested-by: Stefan Huber <shuber@sthu.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
36cd7444 |
|
01-May-2014 |
Dave Airlie <airlied@redhat.com> |
drm/i915: check connector->encoder before using it. DP MST will need connectors that aren't connected to specific encoders, add some checks in advance to avoid oopses. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
3497a562 |
|
10-Jul-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915/chv: Add basic PM interrupt support for CHV Enabled PM interrupt programming for CHV. Re-using gen8 code and extending same for CHV. Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bf225f20 |
|
10-Jul-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move RPS evaluation interval counters to i915->rps Place the RPS counters inside the RPS struct. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
31685c25 |
|
03-Jul-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915/vlv: WA for Turbo and RC6 to work together. With RC6 enabled, BYT has an HW issue in determining the right Gfx busyness. WA for Turbo + RC6: Use SW based Gfx busy-ness detection to decide on increasing/decreasing the freq. This logic will monitor C0 counters of render/media power-wells over EI period and takes necessary action based on these values v2: Refactor duplicate code. (Ville) v3: Reformat the comments. (Ville) v4: Enable required counters and remove unwanted code (Ville) v5: Added frequency change acceleration support and remove kernel-doc style comments. (Ville) v6: Updated comment section and Fix w/a comment. (Ville) Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
50c3dc97 |
|
27-Jun-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/fb-helper: Fix hpd vs. initial config races Some drivers need to be able to have a perfect race-free fbcon setup. Current drivers only enable hotplug processing after the call to drm_fb_helper_initial_config which leaves a tiny but important race. This race is especially noticable on embedded platforms where the driver itself enables the voltage for the hdmi output, since only then will monitors (after a bit of delay, as usual) respond by asserting the hpd pin. Most of the infrastructure is already there with the split-out drm_fb_helper_init. And drm_fb_helper_initial_config already has all the required locking to handle concurrent hpd events since commit 53f1904bced78d7c00f5d874c662ec3ac85d0f9f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Mar 20 14:26:35 2014 +0100 drm/fb-helper: improve drm_fb_helper_initial_config locking The only missing bit is making drm_fb_helper_hotplug_event save against concurrent calls of drm_fb_helper_initial_config. The only unprotected bit is the check for fb_helper->fb. With that drivers can first initialize the fb helper, then enabel hotplug processing and then set up the initial config all in a completely race-free manner. Update kerneldoc and convert i915 as a proof of concept. Feature requested by Thierry since his tegra driver atm reliably boots slowly enough to misses the hotplug event for an external hdmi screen, but also reliably boots to quickly for the hpd pin to be asserted when the fb helper calls into the hdmi ->detect function. Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
a6cdb93a |
|
30-Jun-2014 |
Rodrigo Vivi <rodrigo.vivi@intel.com> |
drm/i915: Implement MI decode for gen8 Ipehr just carries Dword 0 and on Gen 8, offsets are located on Dword 2 and 3 of MI_SEMAPHORE_WAIT. This implementation was based on Ben's work and on Ville's suggestion for Ben Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fixup format string.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
13cf5504 |
|
17-Jun-2014 |
Dave Airlie <airlied@redhat.com> |
drm/i915: rework digital port IRQ handling (v2) The digital ports from Ironlake and up have the ability to distinguish between long and short HPD pulses. Displayport 1.1 only uses the short form to request link retraining usually, so we haven't really needed support for it until now. However with DP 1.2 MST we need to handle the short irqs on their own outside the modesetting locking the long hpd's involve. This patch adds the framework to distinguish between short/long to the current code base, to lay the basis for future DP 1.2 MST work. This should mean we get better bisectability in case of regression due to the new irq handling. v2: add GM45 support (untested, due to lack of hw) Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Todd Previte <tprevite@gmail.com> [danvet: Fix conflicts in i915_irq.c with Oscar Mateo's irq handling race fixes and a trivial one in intel_drv.h with the psr code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
27b6c122 |
|
16-Jun-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/chv: Ack interrupts before handling them (CHV) Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. Without an atomic XCHG operation with mmio space, this patch merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). Notice that, before clearing a port-sourced interrupt in the IIR, the corresponding interrupt source status in the PORT_HOTPLUG_STAT must be cleared. Spotted by Bob Beckett <robert.beckett@intel.com>. v2: - Add warning to commit message and comments to the code as per Chris Wilson's request. - Imre Deak pointed out that the pipe underrun flag might not be signaled in IIR, so do not make valleyview_pipestat_irq_handler depend on it. v3: Improve the source code comment. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
38cc46d7 |
|
16-Jun-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/bdw: Ack interrupts before handling them (GEN8) Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. The right order should be: 1 - Disable Master Interrupt Control. 2 - Find the category of interrupt that is pending. 3 - Find the source(s) of the interrupt and clear the Interrupt Identity bits (IIR) 4 - Process the interrupt(s) that had bits set in the IIRs. 5 - Re-enable Master Interrupt Control. Without an atomic XCHG operation with mmio space, the above merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). Spotted by Bob Beckett <robert.beckett@intel.com>. v2: Add warning to commit message and comments to the code as per Chris Wilson's request. v3: Improve the source code comment. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3ff60f89 |
|
16-Jun-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915/vlv: Ack interrupts before handling them (VLV) Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. Without an atomic XCHG operation with mmio space, this patch merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). Notice that, before clearing a port-sourced interrupt in the IIR, the corresponding interrupt source status in the PORT_HOTPLUG_STAT must be cleared. Spotted by Bob Beckett <robert.beckett@intel.com>. v2: - Reorder the IIR clearing to reduce the window even further. - Add warning to commit message and comments to the code as per Chris Wilson's request. - Imre Deak pointed out that the pipe underrun flag might not be signaled in IIR, so do not make valleyview_pipestat_irq_handler depend on it. v3: Improve the source code comment. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
72c90f62 |
|
16-Jun-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915: Ack interrupts before handling them (GEN5 - GEN7) Otherwise, we might receive a new interrupt before we have time to ack the first one, eventually missing it. According to BSPec, the right order should be: 1 - Disable Master Interrupt Control. 2 - Find the source(s) of the interrupt. 3 - Clear the Interrupt Identity bits (IIR). 4 - Process the interrupt(s) that had bits set in the IIRs. 5 - Re-enable Master Interrupt Control. Without an atomic XCHG operation with mmio space, the above merely reduces the window in which we can miss an interrupt (especially when you consider how heavyweight the I915_READ/I915_WRITE operations are). We maintain the "disable SDE interrupts when handling" hack since apparently it works. Spotted by Bob Beckett <robert.beckett@intel.com>. v2: Add warning to commit message and comments to the code as per Chris Wilson's request. v3: Improve the source comments. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
84c33a64 |
|
02-Jun-2014 |
Sourab Gupta <sourab.gupta@intel.com> |
drm/i915: Replaced Blitter ring based flips with MMIO flips This patch enables the framework for using MMIO based flip calls, in contrast with the CS based flip calls which are being used currently. MMIO based flip calls can be enabled on architectures where Render and Blitter engines reside in different power wells. The decision to use MMIO flips can be made based on workloads to give 100% residency for Media power well. v2: The MMIO flips now use the interrupt driven mechanism for issuing the flips when target seqno is reached. (Incorporating Ville's idea) v3: Rebasing on latest code. Code restructuring after incorporating Damien's comments v4: Addressing Ville's review comments -general cleanup -updating only base addr instead of calling update_primary_plane -extending patch for gen5+ platforms v5: Addressed Ville's review comments -Making mmio flip vs cs flip selection based on module parameter -Adding check for DRIVER_MODESET feature in notify_ring before calling notify mmio flip. -Other changes mostly in function arguments v6: -Having a seperate function to check condition for using mmio flips (Ville) -propogating error code from i915_gem_check_olr (Ville) v7: -Adding __must_check with i915_gem_check_olr (Chris) -Renaming mmio_flip_data to mmio_flip (Chris) -Rebasing on latest nightly v8: -Rebasing on latest code -squash 3rd patch in series(mmio setbase vs page flip race) with this patch -Added new tiling mode update in intel_do_mmio_flip (Chris) v9: -check for obj->last_write_seqno being 0 instead of obj->ring being NULL in intel_postpone_flip, as this is a more restrictive condition (Chris) v10: -Applied Chris's suggestions for squashing patches 2,3 into this patch. These patches make the selection of CS vs MMIO flip at the page flip time, and make the module parameter for using mmio flips as tristate, the states being 'force CS flips', 'force mmio flips', 'driver discretion'. Changed the logic for driver discretion (Chris) v11: Minor code cleanup(better readability, fixing whitespace errors, using lockdep to check mutex locked status in postpone_flip, removal of __must_check in function definition) (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Sourab Gupta <sourab.gupta@intel.com> Signed-off-by: Akash Goel <akash.goel@intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # snb, ivb [danvet: Fix up parameter alignement checkpatch spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
13a5660c |
|
23-May-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915/chv: Freq(opcode) request for CHV. On CHV, All the freq request should be even. So, we need to make sure we request the opcode accordingly. v2: Avoid vairable for freq request (ville) Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4be17381 |
|
06-Jun-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reorder semaphore deadlock check If a semaphore is waiting on another ring, which in turn happens to be waiting on the first ring, but that second semaphore has been signalled, we will be able to kick the second ring and so can treat the first ring as a valid WAIT and not as HUNG. v2: Be paranoid and cap the potential recursion depth whilst visiting the semaphore signallers. (Mika) References: https://bugs.freedesktop.org/show_bug.cgi?id=54226 References: https://bugs.freedesktop.org/show_bug.cgi?id=75502 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
12fabbcb9 |
|
25-Feb-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Set AGPBUSY# bit in init_clock_gating I don't see why we wouldn't want interrupts to wake up the CPU from C3 always, so just set the AGPBUSY# bit in gen3_init_clock_gating(). 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>
|
#
d6e3cca3 |
|
22-May-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Extract gen8_gt_irq_reset Fallout from an intermediate patch revision that I deemed worth saving. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
723761b8 |
|
22-May-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Inline ilk/gen8_irq_reset No point in having this indirection. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2ae2a50c |
|
22-May-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fix up fifo underrun tracking, take N So apparently this is tricky. We need to consider: - We start out with all the hw enabling bits disabled, both the individual fifo underrun interrupts and the shared display error interrupts masked. Otherwise if the bios config is broken we'll blow up with a NULL deref in our interrupt handler since the crtc structures aren't set up yet at driver load time. - On gmch we need to mask fifo underruns on the sw side, so always need to set that in sanitize_crtc for those platforms. - On other platforms we try to set the sw tracking so that it reflects the real state. But since a few platforms have shared bits we must _not_ disable fifo underrun reporting. Otherwise we'll never enable the shared error interrupt. This is the state before out patch, but unfortunately this is not good enough. But after a suspend resume operation this is broken: 1. We don't enable the hw interrupts since the same code runs on resume as on driver load. 2. The fifo underrun state adjustments we do in sanitize_crtc doesn't fire on resume since (except for hilarious firmware) all pipes are off at that point. But they also don't hurt since the subsequent crtc enabling due to force_restore will enable fifo underruns. Which means when we enable fifo underrun reporting we notice that the per-crtc state is already correct and short-circuit everthing out. And the interrupt doesn't get enabled. A similar problem would happen if the bios doesn't light up anything when the driver loads. Which is exactly what happens when we reload the driver since our unload functions disables all outputs. Now we can't just rip out the short-circuit logic and unconditionally update the fifo underrun reporting interrupt masking: We have some checks for shared error interrupts to catch issues that happened when the shared error interrupt was disabled. The right fix is to push down this logic so that we can always update the hardware state, but only check for missed fifo underruns on a real enabled->disabled transition and ignore them when we're already disabled. On platforms with shared error interrupt the pipe CRC interrupts are grouped together with the fifo underrun reporting this fixes pipe CRC support after suspend and driver reloads. Testcase: igt/kms_pipe_crc_basic/suspend-* Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c23cc417 |
|
03-Jun-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: replace drm_get_connector_name() with direct name field use Generated using semantic patches: @@ expression E; @@ - drm_get_connector_name(&E) + E.name @@ expression E; @@ - drm_get_connector_name(E) + E->name v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
93b0a4e0 |
|
22-May-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915: Split the ringbuffers from the rings (3/3) Manual cleanup after the previous Coccinelle script. Yes, I could write another Coccinelle script to do this but I don't want labor-replacing robots making an honest programmer's work obsolete (also, I'm lazy). Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ee1b1e5e |
|
22-May-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915: Split the ringbuffers from the rings (2/3) This refactoring has been performed using the following Coccinelle semantic script: @@ struct intel_engine_cs r; @@ ( - (r).obj + r.buffer->obj | - (r).virtual_start + r.buffer->virtual_start | - (r).head + r.buffer->head | - (r).tail + r.buffer->tail | - (r).space + r.buffer->space | - (r).size + r.buffer->size | - (r).effective_size + r.buffer->effective_size | - (r).last_retired_head + r.buffer->last_retired_head ) @@ struct intel_engine_cs *r; @@ ( - (r)->obj + r->buffer->obj | - (r)->virtual_start + r->buffer->virtual_start | - (r)->head + r->buffer->head | - (r)->tail + r->buffer->tail | - (r)->space + r->buffer->space | - (r)->size + r->buffer->size | - (r)->effective_size + r->buffer->effective_size | - (r)->last_retired_head + r->buffer->last_retired_head ) @@ expression E; @@ ( - LP_RING(E)->obj + LP_RING(E)->buffer->obj | - LP_RING(E)->virtual_start + LP_RING(E)->buffer->virtual_start | - LP_RING(E)->head + LP_RING(E)->buffer->head | - LP_RING(E)->tail + LP_RING(E)->buffer->tail | - LP_RING(E)->space + LP_RING(E)->buffer->space | - LP_RING(E)->size + LP_RING(E)->buffer->size | - LP_RING(E)->effective_size + LP_RING(E)->buffer->effective_size | - LP_RING(E)->last_retired_head + LP_RING(E)->buffer->last_retired_head ) Note: On top of this this patch also removes the now unused ringbuffer fields in intel_engine_cs. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> [danvet: Add note about fixup patch included here.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a4872ba6 |
|
22-May-2014 |
Oscar Mateo <oscar.mateo@intel.com> |
drm/i915: s/intel_ring_buffer/intel_engine_cs In the upcoming patches we plan to break the correlation between engine command streamers (a.k.a. rings) and ringbuffers, so it makes sense to refactor the code and make the change obvious. No functional changes. Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
80715b2f |
|
15-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix gen2 and hsw+ scanline counter On gen2 the scanline counter behaves a bit differently from the later generations. Instead of adding one to the raw scanline counter value, we must subtract one. On HSW/BDW the scanline counter requires a +2 adjustment on HDMI outputs. DP outputs on the on the other require the typical +1 adjustment. As the fixup we must apply to the hardware scanline counter depends on several factors, compute the desired offset at modeset time and tuck it away for when it's needed. v2: Clarify HSW+ situation Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: "Akash Goel <akash.goels@gmail.com>" Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78997 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f75f3746 |
|
15-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Draw a picture about video timings The docs are a bit lacking when it comes to describing when certain timing related events occur in the hardware. Draw a picture which tries to capture the most important ones. v2: Clarify a few details (Imre) v3: Add HSW+ HDMI scanline counter numbers Acked-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>" Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0b2a8e09 |
|
29-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Improve gen3/4 frame counter Currently the logic to fix up the frame counter on gen3/4 assumes that start of vblank occurs at vblank_start*htotal pixels, when in fact it occurs htotal-hsync_start pixels earlier. Apply the appropriate adjustment to make the frame counter more accurate. Also fix the vblank start position for interlaced display modes. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: "Akash Goel <akash.goels@gmail.com>" Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>" Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7e78f1cb |
|
29-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add a small adjustment to the pixel counter on interlaced modes In interlaced modes, the pixel counter counts all pixels, so one field will have htotal more pixels. In order to avoid the reported position from jumping backwards when the pixel counter is beyond the length of the shorter field, just clamp the position the length of the shorter field. This matches how the scanline counter based position works since the scanline counter doesn't count the two half lines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: "Akash Goel <akash.goels@gmail.com>" Reviewed-by: "Sourab Gupta <sourabgupta@gmail.com>" Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
29c6b0c5 |
|
16-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify the uncleared FIFO underrun detection Checking whether the error interrupt was enabled or not isn't really necessary when we check for uncleared FIFO underruns. If it was enabled we'll race with the interrupt handler a bit, but that seems OK as we still claim the interrupt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
56b80e1f |
|
16-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Check for FIFO underruns at the end of modeset on gmch FIFO underruns don't generate interrupts on gmch platforms, so if we want to know whether a modeset triggered FIFO underruns we need to explicitly check for them. As a modeset on one pipe could cause underruns on other pipes, check for underruns on all pipes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> [danvet: Fix up merge error, kudos to Ville for noticing it.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e69abff0 |
|
16-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Check for FIFO underuns when disabling reporting on gmch platforms FIFO underruns don't generate an interrupt on gmch platforms, so we should check whether there were any that we failed to notice when we're disabling FIFO underrun reporting. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Wood <thomas.wood@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c5ab3bc0 |
|
14-May-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Accurately initialize fifo underrun state on gmch platforms We don't have hardware based disable bits on gmch platforms, so need to block spurious underrun reports in software. Which means that we _must_ start out with fifo underrun reporting disabled everywhere. This is in big contrast to ilk/hsw/cpt where there's only _one_ disable bit for all platforms and hence we must allow underrun reporting on disabled pipes. Otherwise nothing really works, especially the CRC support since that's key'ed off the same irq disable bit. This allows us to ditch the fifo underrun reporting hack from the vlv runtime pm code and unexport the internal function from i915_irq.c again. Yay! v2: Keep the display irq disabling, spotted by Imre. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8e5fd599 |
|
09-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3278f67f |
|
09-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drrm/i915/chv: Use valleyview_pipestat_irq_handler() for CHV Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
724a6905 |
|
09-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/chv: Clarify VLV/CHV PIPESTAT bits a bit more Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
823c6909 |
|
16-May-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Convert uncleared FIFO underrun message to errors Some platforms have a shared error interrupt, so if FIFO underrun reporting gets disabled for one pipe/transcoder it gets disabled for all pipes/transcoders. When we disable FIFO underrun reporting we check whether the interrupt was enabled or not. If it wasn't we might have missed an underrun and we perform one last check right there. Currently we print a debug message when an underrun is detect using this mechanism. Promote the message to DRM_ERROR() to match the other underrun error messages. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0961021a |
|
15-May-2014 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915/bdw: Implement a basic PM interrupt handler Almost all of it is reusable from the existing code. The primary difference is we need to do even less in the interrupt handler, since interrupts are not shared in the same way. The patch is mostly a copy-paste of the existing snb+ code, with updates to the relevant parts requiring changes to the interrupt handling. As such it /should/ be relatively trivial. It's highly likely that I missed some places where I need a gen8 version of the PM interrupts, but it has become invisible to me by now. This patch could probably be split into adding the new functions, followed by actually handling the interrupts. Since the code is currently disabled (and broken) I think the patch stands better by itself. v2: Move the commit about not touching the ringbuffer interrupt to the snb_* function where it belongs (Rodrigo) v3: Rebased on Paulo's runtime PM changes v4: Not well validated, but rebase on commit 730488b2eddded4497f63f70867b1256cd9e117c Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Mar 7 20:12:32 2014 -0300 drm/i915: kill dev_priv->pm.regsave v5: Rebased on latest code base. (Deepak) v6: Remove conflict markers, Unnecessary empty line and use right IIR interrupt (Ville) v7: mask modified without rmw (Ville Syrjälä) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
45a83f84 |
|
12-May-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Drop unecessary casts in i915_irq.c Inspired by a review bikeshed from Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
43f328d7 |
|
09-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/chv: Preliminary interrupt support for Cherryview CHV has the Gen8 master interrupt register, as well as Gen8 GT/PCU interrupt registers. The display block is based on VLV, with the main difference of adding pipe C. v2: Rewrite the order of operations to make more sense Don't bail out if MASTER_CTL register doesn't show an interrupt, as display interrupts aren't reported there. v3: Rebase on top of Egbert Eich's hpd irq handling rework by using the relevant port hotplug logic like for vlv. v4: Rebase on top of Ben's gt irq #define refactoring. v5: Squash in gen8_gt_irq_handler refactoring from Zhao Yakui <yakui.zhao@intel.com> v6: Adapt to upstream changes, dev_priv->irq_received is gone. v7: Enable 3 the commented-out 3 pipe support. v8: Rebase on top of Paulo's irq setup rework, use the renamed macros from upstream. v9: Grab irq_lock around i915_enable_pipestat() FIXME: There's probably some potential for more shared code between bdw and chv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Drop the unnecessary cast Jani spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8d7849db |
|
29-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make sprite updates atomic Add a mechanism by which we can evade the leading edge of vblank. This guarantees that no two sprite register writes will straddle on either side of the vblank start, and that means all the writes will be latched together in one atomic operation. We do the vblank evade by checking the scanline counter, and if it's too close to the start of vblank (too close has been hardcoded to 100usec for now), we will wait for the vblank start to pass. In order to eliminate random delayes from the rest of the system, we operate with interrupts disabled, except when waiting for the vblank obviously. Note that we now go digging through pipe_to_crtc_mapping[] in the vblank interrupt handler, which is a bit dangerous since we set up interrupts before the crtcs. However in this case since it's the vblank interrupt, we don't actually unmask it until some piece of code requests it. v2: preempt_check_resched() calls after local_irq_enable() (Jesse) Hook up the vblank irq stuff on BDW as well v3: Pass intel_crtc instead of drm_crtc (Daniel) Warn if crtc.mutex isn't locked (Daniel) Add an explicit compiler barrier and document the barriers (Daniel) Note the irq vs. modeset setup madness in the commit message (Daniel) v4: Use prepare_to_wait() & co. directly and eliminate vbl_received v5: Refactor intel_pipe_handle_vblank() vs. drm_handle_vblank() (Chris) Check for min/max scanline <= 0 (Chris) Don't call intel_pipe_update_end() if start failed totally (Chris) Check that the vblank counters match on both sides of the critical section (Chris) v6: Fix atomic update for interlaced modes v7: Reorder code for better readability (Chris) v8: Drop preempt_check_resched(). It's not available to modules anymore and isn't even needed unless we ourselves cause a wakeup needing reschedule while interrupts are off Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ebc348b2 |
|
29-Apr-2014 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Move semaphore specific ring members to struct This will be helpful in abstracting some of the code in preparation for gen8 semaphores. v2: Move mbox stuff to a separate struct v3: Rebased over VCS2 work Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a225f079 |
|
29-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add intel_get_crtc_scanline() Add a new function intel_get_crtc_scanline() that returns the current scanline counter for the crtc. v2: Rebase after vblank timestamp changes. Use intel_ prefix instead of i915_ as is more customary for display related functions. Include DRM_SCANOUTPOS_INVBL in the return value even w/o adjustments, for a bit of extra consistency. v3: Change the implementation to be based on DSL on all gens, since that's enough for the needs of atomic updates, and it will avoid complicating the scanout position calculations for the vblank timestamps v4: Don't break scanline wraparound for interlaced modes Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
78e8fc6b |
|
29-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix scanout position for real Seems I've been a bit dense with regards to the start of vblank vs. the scanline counter / pixel counter. After staring at the pixel counter on gen4 I came to the conclusion that the start of vblank interrupt and scanline counter increment happen at the same time. The scanline counter increment is documented to occur at start of hsync, which means that the start of vblank interrupt must also trigger there. Looking at the pixel counter value when the scanline wraps from vtotal-1 to 0 confirms that, as the pixel counter at that point reads hsync_start. This also clarifies why we see need the +1 adjustment to the scaline counter. The counter actually starts counting from vtotal-1 on the first active line. I also confirmed that the frame start interrupt happens ~1 line after the start of vblank, but the frame start occurs at hblank_start instead. We only use the frame start interrupt on gen2 where the start of vblank interrupt isn't available. The only important thing to note here is that frame start occurs after vblank start, so we don't have to play any additional tricks to fix up the scanline counter. The other thing to note is the fact that the pixel counter on gen3-4 starts counting from the start of horizontal active on the first active line. That means that when we get the start of vblank interrupt, the pixel counter reads (htotal*(vblank_start-1)+hsync_start). Since we consider vblank to start at (htotal*vblank_start) we need to add a constant (htotal-hsync_start) offset to the pixel counter, or else we risk misdetecting whether we're in vblank or not. I talked a bit with Art Runyan about these topics, and he confirmed my findings. And that the same rules should hold for platforms which don't have the pixel counter. That's good since without the pixel counter it's rather difficult to verify the timings to this accuracy. So the conclusion is that we can throw away all the ISR tricks I added, and just increment the scanline counter by one always. Reviewed-by: Sourab Gupta <sourabgupta@gmail.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f454c694 |
|
22-Apr-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: get a runtime PM ref for the deferred GPU reset work Atm we can end up in the GPU reset deferred work in D3 state if the last runtime PM reference is dropped between detecting a hang/scheduling the work and executing the work. At least one such case I could trigger is the simulated reset via the i915_wedged debugfs entry. Fix this by getting an RPM reference around accessing the HW in the reset work. v2: - Instead of getting/putting the RPM reference in the reset work itself, get it already before scheduling the work. By this we also prevent going to D3 before the work gets to run, in addition to making sure that we run the work itself in D0. (Ville, Daniel) v3: - fix inverted logic fail when putting the RPM ref on behalf of a cancelled GPU reset work (Ville) v4: - Taking the RPM ref in the interrupt handler isn't really needed b/c it's already guaranteed that we hold an RPM ref until the end of the reset work in all cases we care about. So take the ref in the reset work (for cases like i915_wedged_set). (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
843d0e7d |
|
14-Apr-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: clear master interrupt flag when disabling interrupts Not clearing this flag causes spurious interrupts at least in D3 state, so before enabling RPM we need to fix this. We were already setting this flag when enabling interrupts, only clearing it was missing. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
85f9b5f9 |
|
16-Apr-2014 |
Zhao Yakui <yakui.zhao@intel.com> |
drm/i915:Handle the irq interrupt for the second BSD ring Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3ff04a16 |
|
23-Apr-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Don't WARN nor handle unexpected hpd interrupts on gmch platforms The status bits are unconditionally set, the control bits only enable the actual interrupt generation. Which means if we get some random other interrupts we'll bogusly complain about them. So restrict the WARN to platforms with a sane hotplug interrupt handling scheme. And even more important also don't attempt to process the hpd bit since we've detected a storm already. Instead just clear the bit silently. This WARN has been introduced in commit b8f102e8bf71cacf33326360fdf9dcfd1a63925b Author: Egbert Eich <eich@suse.de> Date: Fri Jul 26 14:14:24 2013 +0200 drm/i915: Add messages useful for HPD storm detection debugging (v2) before that we silently handled the hpd event and so partially defeated the storm detection. v2: Pimp commit message (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Egbert Eich <eich@suse.de> Cc: bitlord <bitlord0xff@gmail.com> Reported-by: bitlord <bitlord0xff@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
4e857c58 |
|
17-Mar-2014 |
Peter Zijlstra <peterz@infradead.org> |
arch: Mass conversion of smp_mb__*() Mostly scripted conversion of the smp_mb__* barriers. Signed-off-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-arch@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
#
d0e1f1cb |
|
07-Apr-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Rename GEN8_PIPE_FLIP_DONE to PRIMARY_FLIP_DONE It is now clear that this interrupt is for the primary plane and not something global to the pipe. It also matches what the spec calls it. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
04feced9 |
|
03-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Provide a bit more info when pipestat bits are wrong Print the enable_mask and status_mask from __i915_{enable,disable}_pipestat() when the caller has messed them up somehow. v2: Use pipe_name() (Damien) Fix a typo in the commit message Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f4510a27 |
|
01-Apr-2014 |
Matt Roper <matthew.d.roper@intel.com> |
drm: Replace crtc fb with primary plane fb (v3) Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. This patch was generated by the Coccinelle semantic patching tool using the following rules: @@ struct drm_crtc C; @@ - (C).fb + C.primary->fb @@ struct drm_crtc *C; @@ - (C)->fb + C->primary->fb v3: Generate patch via coccinelle. Actual removal of crtc->fb has been moved to a subsequent patch. v2: Fixup several lingering crtc->fb instances that were missed in the first patch iteration. [Rob Clark] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
|
#
730488b2 |
|
07-Mar-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: kill dev_priv->pm.regsave Now that we don't keep the hotplug interrupts enabled anymore, we can kill the regsave struct and just cal the normal IRQ preinstall, postinstall and uninstall functions. This makes it easier to add runtime PM support to non-HSW platforms. The only downside is in case we get a request to update interrupts while they are disabled, won't be able to update the regsave struct. But this should never happen anyway, so we're not losing too much. v2: - Rebase. v3: - Rebase. v4: - Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0c841212 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: only enable HWSTAM interrupts on postinstall on ILK+ We should only enable interrupts at postinstall. And now on ILK/SNB/IVB/HSW the irq_preinstall and irq_postinstall functions leave the hardware in the same state. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix compile fail due to drm_i915_private_t typedef removal.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
823f6b38 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add gen8_irq_reset So we can merge all the common code from postinstall and uninstall. v2: - Rebase. - While at it, remove useless { and }. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
be30b29f |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add ironlake_irq_reset To merge the common code of ironlake_irq_preinstall and ironlake_irq_uninstall. We should also probably do something about that HSWSTAM write on a later commit. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix compile fail due to drm_i915_private_t typedef removal.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d4eb6b10 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add missing intel_hpd_irq_uninstall Missing from gen8_irq_uninstall. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1c69eb42 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: remove ibx_irq_uninstall After the latest changes, ibx_irq_preinstall and ibx_irq_uninstall are the same, so remove one of the copies and rename the other to ibx_irq_reset (since we're using the "reset" name for things which are called both at preinstall and uninstall). v2: - Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
622364b6 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: enable SDEIER later On the preinstall stage we should just disable all the interrupts, but we currently enable all the south display interrupts due to the way we touch SDEIER at the IRQ handlers (note: they are still masked and our IRQ handler is disabled). Instead of doing that, let's make the preinstall stage just disable all the south interrupts, and do the proper interrupt dance/ordering at the postinstall stage, including an assert to check if everything is behaving as expected. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8f6ff03d |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: call ibx_irq_uninstall from gen8_irq_uninstall After all, we call ibx_irq_preinstall from gen8_irq_preinstall. v2: - Rebase. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
efbd3fc3 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: extract ibx_irq_uninstall Just like ibx_irq_preinstall. We'll call this from somewhere else in the next patch. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7c4d664e |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix open coded gen5_gt_irq_preinstall The duplicate was at an _uninstall function, so rename it to gen5_gt_irq_reset. v2: - Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c6d954c1 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix GEN7_ERR_INT init/reset code Same as SERR_INT and the other IIR registers: reset on preinstall/uninstall and WARN for non-zero values at postinstall. This one also doesn't need double-clear. v2: - Remove the is_zero assertion (Ben). Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
105b122e |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix SERR_INT init/reset code The SERR_INT register is very similar to the other IIR registers, so let's zero it at preinstall/uninstall and WARN for a non-zero value at postinstall, just like we do with the other IIR registers. For this one, there's no need to double-clear since it can't store more than one interrupt. v2: - Remove the is_zero assertion (Ben). Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
337ba017 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: check if IIR is still zero at postinstall on Gen5+ It should already be masked and disabled and zeroed at the preinstall and uninstall stages. Also, the current code just writes to IIR once, and this is not a guarantee that it will be cleared, so it's wrong anyway. The whole reason for the paranoia is that we're going to start calling the IRQ preinstall/postinstall/uninstall from the runtime PM callbacks, so we need to make sure everything is behaving as expected. v2: - Change the original DRM_ERROR to WARN and clear IIR in case it's not zero (Ben). - Improve commit message (Daniel). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
35079899 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add GEN5_IRQ_INIT And the equivalent GEN8_IRQ_INIT_NDX macro. These macros are for the postinstall functions. The next patch will improve this macro. v2: - Adjust to the new POSTING_READ scheme (Ben). Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f86f3fb0 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: properly clear IIR at irq_uninstall on Gen5+ The IRQ_INIT and IRQ_FINI macros are basically the same thing, with the exception that IRQ_FINI doesn't properly clear IIR twice and doesn't have as many POSTING_READs as IRQ_INIT. So rename the INIT macro to IRQ_RESET and use it everywhere. v2: - Fix error in the commit message (Chris). - Adjust to the new POSTING_READ scheme (Ben). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c71ae014 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't forget to uninstall the PM IRQs It's the only thing missing, apparently. v2: - Fix typo (Ben). Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c955483f |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add GEN5_IRQ_FINI Same as the _INIT macro: the goal is to reuse the GEN8 macros, but there are still some slight differences. v2: - Rebase. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5c502442 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: use GEN8_IRQ_INIT on GEN5 And rename it to GEN5_IRQ_INIT. We have discussed doing equivalent changes on July 2013, and I even sent a patch series for this: "[PATCH 00/15] Unify interrupt register init/reset". Now that the BDW code was merged, I have one more argument in favor of these changes. Here's what really changes with the Gen 5 IRQ init code: - We now clear the IIR registers at preinstall (they are also cleared at postinstall, but we will change that later). - We have an additional POSTING_READ at the IMR register. v2: - Fix typo in commit message. - Add POSTING_READ calls to the macros (Ben, Daniel, Jani). Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0bda1cf7 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: also use GEN5_IRQ_INIT with south display interrupts This interrupt gets initialized with a different IER value, so it was not using the macro. The problem is that we plan to modify the macro to make it do additional things, and we want the SDE interrupts updated too. So let's make sure we call the macro, then, after it, we do the necessary SDE-specific changes. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a9d356a6 |
|
01-Apr-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add GEN5_IRQ_INIT macro The goal is to reuse the GEN8 macros, but a few changes are needed, so let's make things easier to review. I could also use these macros on older code, but since I plan to change how the interrupts are initialized, we'll risk breaking the older code in the next commits, so I'll leave this out for now. v2: - Rebase. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
16c6c56b |
|
01-Apr-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Refactor gmch hpd irq handling Pull all the gmch platform hotplug interrupt handling into one function. v2: Move the IIR check to the caller s/drm_i915_private_t/struct drm_i915_private/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add posting read comment suggested by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
921d42ea |
|
18-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: make semaphore signaller detection more robust Extract all this logic into a new helper function semaphore_wait_to_signaller_ring because: - The current code has way too much magic. - The current code doesn't look at bi16, which encodes VECS signallers on HSW. Those are just added after the fact, so can't be encoded in a neat formula. - The current logic can't blow up since it limits its value range sufficiently, but that's a bit too tricky to rely on in my opinion. Especially when we start to add bdw support. - I'm not a big fan of the explicit ring->semaphore_register list, but I think it's more robust to use the same mapping both when constructing the semaphore commands and when decoding them. - Finally add a FIXME comment about lack of broadwell support here, like in the earlier ipehr semaphore cmd detection function. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Actually drop the untrue claim in the commit message Chris pointed out.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a028c4b0 |
|
14-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Add FIXME for bdw semaphore detection in hancheck Currently not an issue since we don't emit sempahores, but better not forget about those. As a little prep work extract the ipehr decoding for cleaner control flow. And apply a bit of polish. Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2d1013dd |
|
31-Mar-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t Also drop any unnecessary casts. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
037bde19 |
|
27-Mar-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq." This reverts commit 2754436913b94626a5414d82f0996489628c513d. Conflicts: drivers/gpu/drm/i915/i915_irq.c The partial application of interrupt masking without regard to other pathways for adjusting the RPS frequency results in completely disabling the PM interrupts. This leads to excessive power consumption as the GPU is kept at max clocks (until the failsafe mechanism fires of explicitly downclocking the GPU when all requests are idle). Or equally as bad for the UX, the GPU is kept at minimum clocks and prevented from upclocking in response to a requirement for more power. Testcase: pm_rps/blocking Cc: Deepak S <deepak.s@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
50877445 |
|
20-Mar-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Broadwell expands ACTHD to 64bit As Broadwell has an increased virtual address size, it requires more than 32 bits to store offsets into its address space. This includes the debug registers to track the current HEAD of the individual rings, which may be anywhere within the per-process address spaces. In order to find the full location, we need to read the high bits from a second register. We then also need to expand our storage to keep track of the larger address. v2: Carefully read the two registers to catch wraparound between the reads. v3: Use a WARN_ON rather than loop indefinitely on an unstable register read. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Drop spurious hunk which conflicted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a6706b45 |
|
15-Mar-2014 |
Deepak S <deepak.s@linux.intel.com> |
drm/i915: Track the enabled PM interrupts in dev_priv. When we use different rps events for different platforms or due to wa, we might end up needing this logic in a lot of places. Instead of this let's use a variable in dev_priv to track the enabled PM interrupts. v2: Initialize pm_rps_events in intel_irq_init() (Ville). Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Frob the commit message a bit since the English was a bit too garbled ;-) ] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
88fe429d |
|
14-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix up semaphore_waits_for There's an entire pile of issues in here: - Use the main RING_HEAD register, not ACTHD. ACTHD points at the gtt offset of the batch buffer when a batch is executed. Semaphores are always emitted to the main ring, so we always want to look at that. - Mask the obtained HEAD pointer with the actual ring size, which is much smaller. Together with the above issue this resulted us in trying to dereference a pointer way outside of the ring mmio mapping. The resulting invalid access in interrupt context (hangcheck is executed from timers) lead to a full blown kernel panic. The fbcon panic handler then tried to frob our driver harder, resulting in a full machine hang at least on my snb here where I've stumbled over this. - Handle ring wrapping correctly and be a bit more explicit about how many dwords we're scanning. We probably should also scan more than just 4 ... - Space out some of teh computations for readability. This reduces hard-hangs on my snb here. Mika and QA both say that it doesn't completel remove them, but at least for me it's a clear improvement in stability. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=74100 Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b39fb297 |
|
19-Mar-2014 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Rename and comment all the RPS *stuff* The names of the struct members for RPS are stupid. Every time I need to do anything in this code I have to spend a significant amount of time to remember what it all means. By renaming the variables (and adding the comments) I hope to clear up the situation. Indeed doing this make some upcoming patches more readable. I've avoided ILK because it's possible that the naming used for Ironlake matches what is in the docs. I believe the ILK power docs were never published, and I am too lazy to dig them up. v2: leave rp0, and rp1 in the names. It is useful to have these limits available at times. min_freq and max_freq (which may be equal to rp0, or rp1 depending on the platform) represent the actual HW min and max. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5d584b2e |
|
07-Mar-2014 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: move pc8.irqs_disabled to pm.irqs_disabled When other platforms add runtime PM support they will also need to disable interrupts, so move the variable to the runtime PM struct. Also notice that the longer-term goal is to completely kill the regsave struct, and I even have patches for that. v2: - Rebase. v3: - Rebase. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5c673b60 |
|
07-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Don't enable display error interrupts from the start We need to enable interrupt processing before all the modeset state is set up. But that means we can fall over when we get a pipe underrun. This shouldn't happen as long as the bios works correctly but as usual this turns out to be wishful thinking. So disable error interrupts at irq install time and rely on the re-enabling code in the modeset functions to take care of this. Note that due to the SDE interrupt handling race we must uncondtionally enable all interrupt sources in SDEIER, hence no need to enable the SERR bit specifically. On gmch platforms we don't have an explicit enable/mask bit for fifo underruns. Fixing this up would require a bit of software tracking, hence is material for a separate patch. To make this possible we need to switch all gmch platforms to the new pipestat interrupt handling scheme Imre implemented for vlv, and then also add a safe form of sw state checking to __cpu_fifo_underrun_reporting_enabled a bit. v2: Also handle the ilk/snb cpu fifo underrun bits accordingly. Spotted by Ville. v3: Also handle the south interrupt underrun bits on ibx. Again spotted by Ville. Reported-by: Rob Clark <robdclark@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
24302624 |
|
10-Mar-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix scanline counter fixup on BDW The display interrupts changed on BDW, so the current ILK-HSW specific code in ilk_pipe_in_vblank_locked() doesn't work there. Add the required bits for BDW, and while at it, change the existing code to use nicer looking vblank status bit macros. Also remove the now stale __raw_i915_read16() definition which was left over from the failed gen2 ISR experiment. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73962 Tested-by: Lu Hua <huax.lu@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
fcb81823 |
|
10-Mar-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add a workaround for HSW scanline counter weirdness On HSW the scanline counter seems to behave differently depending on the output type. eDP on port A does what you would expect an the normal +1 fixup is sufficient to cover it. But on HDMI outputs we seem to need a +2 fixup. Just assume we always need the +2 fixup and accept the slight inaccuracy on eDP. This fixes a regression introduced in: commit 8072bfa6045a264d3913102a35fab125b06603a2 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Oct 28 21:22:52 2013 +0200 drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos() That commit removed the heuristic that tried to fix up the timestamps for vblank interrupts that fire a bit too early. Since then the vblank timestamp code would treat some vblank interrupts as spurious since the scanline counter would indicate that vblank_start wasn't reached yet. That in turn lead to incorrect vblank event sequence numbers being reported to userspace, which lead to unsteady framerate in applications such as XBMC which uses them for timing purposes. v2: Remember to call ilk_pipe_in_vblank_locked() on HSW too (Mika) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75725 Tested-by: bugzilla1@gmx.com Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
6c7fba04 |
|
10-Mar-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: fix typo in display IRQ mask when disabling IRQs Introduced in commit e0e33f8ff6f0b6d286afc314802be4993341bd47 Author: Imre Deak <imre.deak@intel.com> Date: Tue Mar 4 19:23:07 2014 +0200 The impact was luckily minimal, due to the extra check we do against a software pipestat IRQ mask. Caught by Fengguang's 0-day tester. Cc: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
77961eb9 |
|
05-Mar-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: power domains: add vlv power wells Based on an early draft from Jesse. Add support for powering on/off the dynamic power wells on VLV by registering its display and dpio dynamic power wells with the power domain framework. For now power on all PHY TX lanes regardless of the actual lane configuration. Later this can be optimized when the PHY side setup enables only the required lanes. Atm, it enables all lanes in all cases. v2: - undef function local COND macro after its last use (Ville) - Take dev_priv->irq_lock around the whole sequence of intel_set_cpu_fifo_underrun_reporting_nolock() and valleyview_disable_display_irqs(). They are short and releasing the lock in between only makes proving correctness more difficult. - sanitize local var names in vlv_power_well_enabled() v3: - rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict due to my changes in the previous patch. Also throw in an assert_spin_locked for safety. And finally appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f88d42f1 |
|
04-Mar-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: factor out intel_set_cpu_fifo_underrun_reporting_nolock Needed by the next patch, wanting to set the underrun reporting as part of a bigger dev_priv->irq_lock'ed sequence. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Use more customary __ prefix instead of _nolock postfix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f8b79e58 |
|
04-Mar-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: factor out valleyview_display_irq_install We'll need to disable/re-enable the display-side IRQs when turning off/on the VLV display power well. Factor out the helper functions for this. For now keep the display IRQs enabled by default, so the functionality doesn't change. This will be changed to enable/disable the IRQs on-demand when adding support for VLV power wells in an upcoming patch. v2: - take the irq spin lock for the whole enable/disable sequence as these can be called with interrupts enabled Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7f9e192f |
|
04-Mar-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: keep first level vblank IRQs masked This is a left-over from commit b7e634cc8dcd320123199a18bae0937b40dc28b8 Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 4 21:35:45 2014 +0200 drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt where we stopped unmasking the vblank IRQs, but left them enabled in the IER register. Disable them in IER too. v2: - remove comment becoming stale after this change (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
07d27e20 |
|
03-Mar-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Replace a few for_each_pipe(i) by for_each_pipe(pipe) Consistency throughout the code base is good and remove some room for mistakes (as explained in the "drm/i915: Use a pipe variable to cycle through the pipes" commit) So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe) when it's reasonable and practical to do so (eg. when there isn't another pipe variable already). Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
58174462 |
|
25-Feb-2014 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Add reason for capture in error state We capture error state not only when the GPU hangs but also on other situations as in interrupt errors and in situations where we can kick things forward without GPU reset. There will be log entry on most of these cases. But as error state capture might be only thing we have, if dmesg was not captured. Or as in GEN4 case, interrupt error can trigger error state capture without log entry, the exact reason why capture was made is hard to decipher. v2: Split out the the error code stuff to separate patch (Ben) References: https://bugs.freedesktop.org/show_bug.cgi?id=74193 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b5ea642a |
|
02-Mar-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: sprinkle static Apparently we've missed a few more than what Fengguang's 0-day tester recently reported in i915_irq.c ... Makes sparse happy again (ignore some spurious stuff about ksyms of exported functions). Cc: kbuild test robot <fengguang.wu@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bbb5eebf |
|
12-Feb-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Some polish for the new pipestat_irq_handler Just a bit of polish which I hope will help me with massaging some internal patches to use Imre's reworked pipestat handling: - Don't check for underrun reporting or enable pipestat interrupts twice. - Frob the comments a bit. - Do the iir PIPE_EVENT to pipe mapping explicitly with a switch. We only have one place which does this, so better to make it explicit. v2: Ville noticed that I've broken the logic a bit with trying to avoid checking whether we're interested in a given pipe twice. push the PIPESTAT read down after we've computed the mask of interesting bits first to avoid that duplication properly. v3: Squash in fixups from Imre on irc. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
91d181dd |
|
10-Feb-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: handle only enabled pipestat interrupt events Atm we call the handlers for pending pipestat interrupt events even if they aren't explicitly enabled by i915_enable_pipestat(). This isn't an issue for events other than the vblank start event, since those are always enabled anyways. Otoh, we enable the vblank start event on-demand, so we'll end up calling the vblank handler at times when they are disabled. I haven't checked if this causes any real problem, but for consistency and to remove some overhead we should still fix this by clearing / handling only the enabled interrupt events. Also this is a dependency for the upcoming VLV power domain patchset where we need to disable all the pipestat interrupts whenever the display power well is off. v2: - inline the status->enable mask mapping (Ville) - don't check for invalid PSR bit on platforms other than VLV (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Frob conflict due to different merge order.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
10c59c51 |
|
10-Feb-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: fix mapping of pipestat enable to status bits At least on VLV we can't get at the pipestat status bits by simply right shifting the corresponding enable bits. The mapping between enable and status bits for the sprite0,1 flip done and the PSR events don't follow this rule, so we need to map them separately. The PSR enable for pipe A is DPFLIPSTAT[22], but I haven't added support for this, since there is no user of it atm. Until support is added WARN if someone tries to enable PSR interrupts, or tries to enable the same (1 << 6) bit on pipe B, which MBZ. v2: - inline the status->enable mask mapping (Ville) - fix bogus use of status bits in enable mask (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
755e9019 |
|
10-Feb-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: pass status instead of enable flags to i915_enable_pipestat There isn't any PSR interrupt enable bit for pipe A, so we couldn't enable it through the current API. Passing the corresponding status bits solves this and also makes the mapping between enable and status bits simpler on VLV (addressed in an upcoming patch). Except of checking for invalid status bit arguments, no functional change. v2: split out the low level parts of i915_enable_pipestat accepting separate enabled and status masks, to make the non-standard mapping between those masks stand out more (added in the next patch) (Jesse,Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3d13ef2e |
|
07-Feb-2014 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Always use INTEL_INFO() to access the device_info structure If we make sure that all the dev_priv->info usages are wrapped by INTEL_INFO(), we can easily modify the ->info field to be structure and not a pointer while keeping the const protection in the INTEL_INFO() macro. v2: Rebased onto latest drm-nightly Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a2d213dd |
|
07-Feb-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fix intel_pipe_to_cpu_transcoder for UMS We don't have all the drm_crtc&co hanging around in that case. This regression has been introduced in commit 391f75e2bf13f105d9e4a120736ccdd8e3bc638b Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Sep 25 19:55:26 2013 +0300 drm/i915: Fix pre-CTG vblank counter Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=69521 Cc: stable@vger.kernel.org (for 3.13 only) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
579a9b0e |
|
04-Feb-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: unify FLIP_DONE macro names s/FLIPDONE/FLIP_DONE/ to make all FLIP_DONE macro names consistent. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
58ead0d7 |
|
04-Feb-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: s/spin_lock_irqsave/spin_lock/ in irq handler Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c1874ed7 |
|
04-Feb-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: factor out valleyview_pipestat_irq_handler This will be used by other platforms too, so factor it out. The only functional change is the reordeing of gmbus_irq_handler() wrt. the hotplug handling, but since it only schedules a work, it isn't an issue. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Don't keep on using the private_t typedef.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b7e634cc |
|
04-Feb-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt Bspec and the code suggests that the interrupt signaled by IIR[7,5] (DISPLAY_PIPE_A/B_VBLANK) is a first level IRQ flag for the second level PIPEA/BSTAT[2] (Start of Vertical Blank) interrupt. Measuring the relative timings of when IIR[7] and PIPEASTAT[1,2] get set and checking the effect of unmasking different pipestat and IIR events shows that this isn't so: First, ISR/IIR[7] gets set independently of PIPEASTAT[18] (Start of Vertical Blank Enable) or any other pipestat enable bit, so it isn't a first level IRQ bit showing the state of PIPEASTAT[2], but is connected directly to the timing generator. Second, setting only PIPEASTAT[18] and leaving all other pipestat events disabled, IIR[6] (DISPLAY_PIPE_A_EVENT) gets set close to the moment when PIPEASTAT[2] gets set, so the former is a first level interrupt flag for the latter. The bspec is rather unclear about this, but I also assume that IIR[6] signals all pipestat A events, except PIPEASTAT[31] (FIFO Under-run Status). Third, IIR[7] is set close to the moment when PIPEASTAT[1] (Framestart Interrupt) gets set, in the mode I used about 12usec after PIPEASTAT[2] and IIR[6] gets set. This means the IIR[7] isn't marking the start of vblank, but rather signals the framestart event. Based on the above, we don't need to unmask IIR[7] when waiting for start of vblank events, but we can rely on IIR[6] being always unmasked, which will signal when PIPEASTAT[2] gets set. Doing this will also get rid of the overhead of getting an interrupt and servicing IIR[7], which is atm raised always some time after IIR[6]/PIPEASTAT[2] is raised. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
76c3552f |
|
30-Jan-2014 |
Deepak S <deepak.s@intel.com> |
drm/i915/vlv: WA to fix Voltage not getting dropped to Vmin when Gfx is power gated. When we enter RC6 and GFX Clocks are off, the voltage remains higher than Vmin. When we try to set the freq to RPn, it might fail since the Gfx clocks are down. So to fix this in Gfx idle, Bring the GFX clock up and set the freq to RPn then move GFx down. v2: remove vlv_update_rps_cur_delay function. Update commit message (Daniel) v3: Fix the timeout during wait for gfx clock (Jesse) v4: addressed comments on set freq and punit wait (Ville) v5: use wait_for while waiting for GFX clk to be up. (Daniel) update cur_delay before requesting min_delay. (Ville) v6: use wait_for while waiting for punit. (Ville) Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b6b0fac0 |
|
30-Jan-2014 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: Use hangcheck score to find guilty context With full ppgtt using acthd is not enough to find guilty batch buffer. We get multiple false positives as acthd is per vm. Instead of scanning which vm was running on a ring, to find corressponding context, use a different, simpler, strategy of finding batches that caused gpu hang: If hangcheck has declared ring to be hung, find first non complete request on that ring and claim it was guilty. v2: Rebase Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73652 Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
27544369 |
|
27-Jan-2014 |
Deepak S <deepak.s@intel.com> |
drm/i915: Disable/Enable PM Intrrupts based on the current freq. When current delay is already at max delay, Let's disable the PM UP THRESHOLD INTRRUPTS, so that we will not get further interrupts until current delay is less than max delay, Also request for the PM DOWN THRESHOLD INTRRUPTS to indicate the decrease in clock freq. and viceversa for PM DOWN THRESHOLD INTRRUPTS. v2: Use bool variables (Daniel) v3: Fix Interrupt masking bit (Deepak) v4: Use existing symbolic constants in i915_reg.h (Daniel) v5: Add pm interrupt mask after new_delay calculation (Ville) Signed-off-by: Deepak S <deepak.s@intel.com> [danvet: Pass new_delay by value as suggested by Ville. Also appease checkpatch.] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d330a953 |
|
21-Jan-2014 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move module parameters into a struct, in a new file With 20+ module parameters, I think referring to them via a struct improves clarity over just having a bunch of globals. While at it, move the parameter initialization and definitions into a new file i915_params.c to reduce clutter in i915_drv.c. Apart from the ill-named i915_enable_rc6, i915_enable_fbc and i915_enable_ppgtt parameters, for which we lose the "i915_" prefix internally, the module parameters now look the same both on the kernel command line and in code. For example, "i915.modeset". The downsides of the change are losing static on a couple of variables and not having the initialization and module_param_named() right next to each other. On the other hand, all module parameters are now defined in one place at i915_params.c. Plus you can do this to find all module parameter references: $ git grep "i915\." -- drivers/gpu/drm/i915 v2: - move the definitions into a new file - s/i915_params/i915/ - make i915_try_reset i915.reset, for consistency Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fc2c807b |
|
17-Jan-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make underruns DRM_ERROR I want to see these without having full debugs enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: fix the gen8 irq handler as spotted by Paulo in his review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2d9d2b0b |
|
17-Jan-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Limit FIFO underrun reports on GMCH platforms Currently we print all pipe underruns on GMCH platforms. Hook up the same logic we use on PCH platforms where we disable the underrun reporting after the first underrun. Underruns don't actually generate interrupts themselves on GMCH platforms, we just can detect them whenever we service other interrupts. So we don't have any enable bits to worry about. We just need to remember to clear the underrun status when enabling underrun reporting. Note that the underrun handling needs to be moved to the non-locked pipe_stats[] loop in the interrupt handlers to avoid having to rework the locking in intel_set_cpu_fifo_underrun_reporting(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
41c54e51 |
|
17-Jan-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill dev_priv->irq_received Not sure anyone cares about this information. I suppose most people would just look at /proc/interrupts instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
501e01d7 |
|
17-Jan-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make irq_received bool irq_received is used as a boolean in i965_irq_handler(), so make it bool. This also makes i965_irq_handler() closer to i915_irq_handler(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewd-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3ca1cced |
|
17-Jan-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add intel_hpd_irq_uninstall() Add intel_hpd_irq_uninstall() which will cancel the hotplug re-enable timer. Also s/i915_reenable_hotplug_timer_func/intel_hpd_irq_reenable/ Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> 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>
|
#
cc9bd499 |
|
16-Jan-2014 |
Imre Deak <imre.deak@intel.com> |
drm/i915: clean up HPD IRQ debug printing Atm, we don't print these events for all platforms and for VLV/G4X we also print them for DP AUX completion events which is unnecessary spam. Fix both issues. Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
095163ba |
|
28-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Add a kludge for DSL incrementing too late and ISR not working On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as far as display interrupts are concerned. Instead it sort of looks like some ISR bits just directly reflect the corresponding bit from PIPESTAT. The bit appears in the ISR only if the PIPESTAT interrupt is enabled. So in that sense it sort of looks a bit like the south interrupt scheme on PCH platforms. So it goes something a bit like this: PIPESTAT.status & PIPESTAT.enable -> ISR -> IMR -> IIR -> IER -> actual interrupt In any case that means the intel_pipe_in_vblank_locked() doesn't actually work for pre-PCH platforms. As a last resort, add a similar kludge as radeon has that fixes things up if we got called from the vblank interrupt, but the scanline counter value indicates that we're not quite there yet. We know that the scanline counter increments at hsync but is otherwise accurate, so we can limit the kludge to the line just prior to vblank start, instead of the relative distance that radeon uses. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
abca9e45 |
|
28-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Pass 'flags' from the caller to .get_scanout_position() Preparation for moving the early vblank IRQ logic into radeon_get_crtc_scanoutpos(). v2: Fix radeon_drv.c compile warning (Mario) Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
d31faf65 |
|
28-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix scanoutpos calculations for interlaced modes The scanline counter counts lines in the current field, not the entire frame. But the crtc_ timings are the values for the entire frame. Divide the vertical timings by 2 to make them match the scanline counter. The rounding was carefully chosen to make it do the right thing wrt. the observed scanline counter and ISR vblank bit behaviour. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
7da903ef |
|
26-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos() Rather than using crtc->hwmode, just pass the relevant mode to drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode usage from core drm. Reviewed-by: mario.kleiner.de@gmail.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
|
#
09f2344d |
|
10-Jan-2014 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915/bdw: make sure south port interrupts are enabled properly v2 We were apparently relying on the defaults on BDW, which resulted in no hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to enable all interrupts. v2: use preinstall instead of redundant SDIER write References: https://bugs.freedesktop.org/show_bug.cgi?id=72834 References: https://bugs.freedesktop.org/show_bug.cgi?id=72833 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cba1c073 |
|
10-Jan-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Include more information in disabled hotplug interrupt warning Daniel thought that this was an opportune moment to include which pins and bits ended up being stuck in the WARN. Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8b5565b8 |
|
10-Jan-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only complain about a rogue hotplug IRQ after disabling Disabling the hotplug IRQ is a two-step process. First, inside the IRQ handler we mark the rogue hotplug pin for disabling. Then later in the hotplug worker, we actually disable the hotplug pin. So we should not WARN about the rogue hotplug IRQ being sent until after we have completed disabling the pin. References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3432087e |
|
10-Jan-2014 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only WARN about a stuck hotplug irq ONCE It seems that hardware that is broken enough to emit a hotplug IRQ even though the pin is surposedly disable, will do so indefinitely. Note: There's a good chance the underlying issue has been fixed with commit 0ce99f749b3834edeb500e17d6ad17e86b60ff83 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 26 11:27:49 2013 +0200 drm/i915: fix gen4 digital port hotplug definitions References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170 Link: https://bugzilla.redhat.com/attachment.cgi?id=847786 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add note about the potential fix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
704cfb87 |
|
18-Dec-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: s/hotplugt_status_gen4/hotplug_status_g4x/ We specifically exclude original gen4 (i.e. i965g/gm), so update the naming for consistency. Spotted while reviewing related code due to a report from Jesse about byt needing again different values. v2: g4x, not gm45 since this also applies to the desktop version. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3a77c4c4 |
|
10-Jan-2014 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Drop I915_ prefix from HAS_FBC My OCD just couldn't let this slide. Spotted while reviewing Ville's patch to only flip planes when we have FBC. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
38af6096 |
|
07-Jan-2014 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't swap planes on 830M Looks like 830M doesn't quite like it when you try to move a plane from one pipe to another. It seems that the plane's old pipe has to be active even if the plane is already disabled, otherwise the relevant register just won't accept new values. The following commit: commit 1f1c2e2468f937cefd6bcb645c959c7b5d9821df Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Nov 28 17:30:01 2013 +0200 drm/i915: Swap primary planes on gen2 for FBC caused a regression on 830M. It will attempt to swap the planes when the driver is loaded, but at that time only pipe A might be active, so plane A gets disabled, but plane B won't get enabled since pipe B is not active when we try to move the plane over to pipe A. There's no reason to swap planes on 830M since it doesn't support FBC. Change the logic a bit to limit the plane swapping to platforms which actually support FBC. This should avoid getting a black screen on 830M. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1f2d4531 |
|
21-Nov-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: disable interrupts when enabling PC8 The plan is to merge PC8 and D3 into a single feature, and when we're in D3 we won't get any hotplug interrupt anyway, so leaving them enable doesn't make sense, and it also brings us a problem. The problem is that we get a hotplug interrupt right when we we wake up from D3, when we're still waking up everything. If we fully disable interrupts we won't get this hotplug interrupt, so we won't have problems. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1f1c2e24 |
|
28-Nov-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Swap primary planes on gen2 for FBC Only plane A is FBC capable on gen2 (like gen3), but the panel fitter is hooked up to pipe B, so we want to prefer pipe B + plane A. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add the code comment Chris requested in his review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4aeebd74 |
|
31-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: dp aux irq support for g4x/vlv Now we have this everywhere. Next up would be to wire up the DP hotplug pin to speed up panel power sequencing for eDP panels ... I've decided to leave the has_aux_irq logic in the code, it should come handy for hw bringup. For testing/fail-safety the dp aux code already has a timeout when waiting for interrupts to signal completion and screams rather loud if they don't arrive in time. Given that we need a real piece of hw to talk to anyway this is probably as good as it gets. v2: Don't check the dp aux channel bits on i965 machines, they have a different meaning there. Yay for reusing bits at will! Spotted by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2ac0f450 |
|
12-Nov-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: add i915_reset_count reset_counter will be incremented twice per successful reset. Odd values mean reset is in progress and even values mean that reset has completed. Reset status ioctl introduced in following commit needs to deliver global reset count to userspace so use reset_counter to derive the actual reset count for the gpu Note that reset in progress is enough to increment the counter. v2: wedged equals reset in progress (Daniel Vetter) v3: Fixed stale comments (Damien Lespiau) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
13b3a0a7 |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Mask the vblank interrupt on bdw by default Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
38d83c96 |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Wire up cpu fifo underrun reporting support for bdw HW engineers have listened and given us again a real interrupt with masking and status regs. Yay! For consistency with other platforms call the #define FIFO_UNDERRUN. Eventually we also might need to have some enable/disable functions for bdw display interrupts, but for now open-coding seems to be good enough. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7167d7c6 |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Optimize gen8_enable|disable_vblank functions Let's cache the IMR value like on other platforms. This is needed to implement the underrun reporting since then we'll have two places that change the same register at runtime. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0fbe7870 |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Wire up pipe CRC support for bdw The layout of the CRC registers is the same as on hsw, only the interrupt handling has changed a bit. So trivial to wire up, yay! Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
92d03a80 |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Wire up PCH interrupts for bdw Gives us hotplug, gmbus, dp aux and south errors (underrun reporting!). Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6d766f02 |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Wire up port A aux channel Useful for dp aux to work better. Also stop enabling the port A hotplug event - eDP panels are expected to fire that interupt and we're not really ready to deal with them. This is consistent with how we handle port A on ilk-hsw. The more important bit is that we must delay the enabling of hotplug interrupts until all the encoders are fully set up. But we need irq support earlier than that, hence hotplug interrupts can only be enabled in the ->hpd_irq_setup callback. v2: Drop the _HOTPLUG, it isn't (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
30100f2b |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fix up the bdw pipe interrupt enable lists - Pipe underrun can't just be enabled, we need some support code like on ilk-hsw to make this happen. So drop it for now. - CRC error is a special mode of the CRC hardware that we don't use, so again drop it. Real CRC support for bdw will be added later. - All the other error bits are about faults, so rename the #define and adjust the output. v2: Use pipe_name as pointed out by Ville. Ville's comment was on a previous patch, but it was easier to squash in here. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c42664cc |
|
07-Nov-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Optimize pipe irq handling on bdw We have a per-pipe bit in the master irq control register, so use it. This allows us to drop the masks for aggregate interrupt bits and be a bit more explicit in the code. It also removes one indentation level. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
abd58f01 |
|
02-Nov-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915/bdw: Implement interrupt changes The interrupt handling implementation remains the same as previous generations with the 4 types of registers, status, identity, mask, and enable. However the layout of where the bits go have changed entirely. To address these changes, all of the interrupt vfuncs needed special gen8 code. The way it works is there is a top level status register now which informs the interrupt service routine which unit caused the interrupt, and therefore which interrupt registers to read to process the interrupt. For display the division is quite logical, a set of interrupt registers for each pipe, and in addition to those, a set each for "misc" and port. For GT the things get a bit hairy, as seen by the code. Each of the GT units has it's own bits defined. They all look *very similar* and resides in 16 bits of a GT register. As an example, RCS and BCS share register 0. To compact the code a bit, at a slight expense to complexity, this is exactly how the code works as well. 2 structures are added to the ring buffer so that our ring buffer interrupt handling code knows which ring shares the interrupt registers, and a shift value (ie. the top or bottom 16 bits of the register). The above allows us to kept the interrupt register caching scheme, the per interrupt enables, and the code to mask and unmask interrupts relatively clean (again at the cost of some more complexity). Most of the GT units mentioned above are command streamers, and so the symmetry should work quite well for even the yet to be implemented rings which Broadwell adds. v2: Fixes up a couple of bugs, and is more verbose about errors in the Broadwell interrupt handler. v3: fix DE_MISC IER offset v4: Simplify interrupts: I totally misread the docs the first time I implemented interrupts, and so this should greatly simplify the mess. Unlike GEN6, we never touch the regular mask registers in irq_get/put. v5: Rebased on to of recent pch hotplug setup changes. v6: Fixup on top of moving num_pipes to intel_info. v7: Rebased on top of Egbert Eich's hpd irq handling rework. Also wired up ibx_hpd_irq_setup for gen8. v8: Rebase on top of Jani's asle handling rework. v9: Rebase on top of Ben's VECS enabling for Haswell, where he unfortunately went OCD on the gt irq #defines. Not that they're still not yet fully consistent: - Used the GT_RENDER_ #defines + bdw shifts. - Dropped the shift from the L3_PARITY stuff, seemed clearer. - s/irq_refcount/irq_refcount.gt/ v10: Squash in VECS enabling patches and the gen8_gt_irq_handler refactoring from Zhao Yakui <yakui.zhao@intel.com> v11: Rebase on top of the interrupt cleanups in upstream. v12: Rebase on top of Ben's DPF changes in upstream. v13: Drop bdw from the HAS_L3_DPF feature flag for now, it's unclear what exactly needs to be done. Requested by Ben. v14: Fix the patch. - Drop the mask of reserved bits and assorted logic, it doesn't match the spec. - Do the posting read inconditionally instead of commenting it out. - Add a GEN8_MASTER_IRQ_CONTROL definition and use it. - Fix up the GEN8_PIPE interrupt defines and give the GEN8_ prefixes - we actually will need to use them. - Enclose macros in do {} while (0) (checkpatch). - Clear DE_MISC interrupt bits only after having processed them. - Fix whitespace fail (checkpatch). - Fix overtly long lines where appropriate (checkpatch). - Don't use typedef'ed private_t (maintainer-scripts). - Align the function parameter list correctly. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v4) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> bikeshed
|
#
1272e7b8 |
|
07-Nov-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use clamp_t() when limiting cur_delay Make the cur_delay limiting code a bit less prone to typo errors by using clamp_t(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
edc08d0a |
|
06-Nov-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix gen3/4 vblank counter wraparound When the hardware frame counter reads 0xffffff and we're already past vblank start, we'd return 0x1000000 as the vblank counter value. Once we'd cross into the next frame's active portion, the vblank counter would wrap to 0. So we're reporting two different vblank counter values for the same frame. Fix the problem by masking the cooked value by 0xffffff to make sure the counter wraps already after vblank start. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7b5562d4 |
|
05-Nov-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV This fixes a mismatch between our vblank enable code and our IRQ handler. Also, since vblank start events come in before page flips reliably, it also fixes the kms_flip plain-flip test on my BYT system. Spotted-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ad3543ed |
|
29-Oct-2013 |
Mario Kleiner <mario.kleiner.de@gmail.com> |
drm/intel: Push get_scanout_position() timestamping into kms driver. Move the ktime_get() clock readouts and potential preempt_disable() calls from drm core into kms driver to make it compatible with the api changes in the drm core. The intel-kms driver needs to take the uncore.lock inside i915_get_crtc_scanoutpos() and intel_pipe_in_vblank(). This is incompatible with the preempt_disable() on a PREEMPT_RT patched kernel, as regular spin locks must not be taken within a preempt_disable'd section. Lock contention on the uncore.lock also introduced too much uncertainty in vblank timestamps. Push the ktime_get() timestamping for scanoutpos queries and potential preempt_disable_rt() into i915_get_crtc_scanoutpos(), so these problems can be avoided: 1. First lock the uncore.lock (might sleep on a PREEMPT_RT kernel). 2. preempt_disable_rt() (will be added by the rt-linux folks). 3. ktime_get() a timestamp before scanout pos query. 4. Do all mmio reads as fast as possible without grabbing any new locks! 5. ktime_get() a post-query timestamp. 6. preempt_enable_rt() 7. Unlock the uncore.lock. This reduces timestamp uncertainty on a low-end HP Atom Mini netbook with Intel GMA-950 nicely: Before: 3-8 usecs with spikes > 20 usecs, triggering query retries. After : Typically 1 usec (98% of all samples), occassionally 2 usecs (2% of all samples), with maximum of 3 usecs (a handful). v2: Fix formatting of new multi-line code comments. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
40da17c2 |
|
21-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: refactor ilk display interrupt handling - Use a for_each_loop and add the corresponding #defines. - Drop the _ILK postfix on the existing DE_PIPE_VBLANK macro for consistency with everything else. - Also use macros (and add the missing one for plane flips) for the ivb display interrupt handler. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Drop the useless parens that Ville spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3b6c42e8 |
|
21-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: use enum pipe consistently in i915_irq.c Request by Ville in his review of the CRC stuff. This converts everything but ilk_display_irq_handler since that needs a bit more than a simple search&replace to look nice. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f4adcd24 |
|
28-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: handle faked missed interrupts as simulated hangs, too Otherwise QA will report this as a real hang when running igt ZZ_missed_irq. v2: Actually test the right stuff and really shut up the DRM_ERROR output ... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70747 Tested-by: lu hua <huax.lu@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5bdebb18 |
|
10-Oct-2013 |
Dave Airlie <airlied@redhat.com> |
drm/sysfs: sort out minor and connector device object lifetimes. So drm was abusing device lifetimes, by having embedded device structures in the minor and connector it meant that the lifetime of the internal drm objects (drm_minor and drm_connector) were tied to the lifetime of the device files in sysfs, so if something kept those files opened the current code would kfree the objects and things would go downhill from there. Now in reality there is no need for these lifetimes to be so intertwined, especailly with hotplugging of devices where we wish to remove the sysfs and userspace facing pieces before we can unwind the internal objects due to open userspace files or mmaps, so split the objects out so the struct device is no longer embedded and do what fbdev does and just allocate and remove the sysfs inodes separately. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
d538bbdf |
|
21-Oct-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Use a spin lock to protect the pipe crc struct Daniel pointed out that it was hard to get anything lockless to work correctly, so don't even try for this non critical piece of code and just use a spin lock. v2: Make intel_pipe_crc->opened a bool v3: Use assert_spin_locked() instead of a comment (Daniel Vetter) v4: Use spin_lock_irq() in the debugfs functions (they can only be called from process context), Use spin_lock() in the pipe_crc_update() function that can only be called from an interrupt handler, Use wait_event_interruptible_lock_irq() when waiting for data in the cicular buffer to ensure proper locking around the condition we are waiting for. (Daniel Vetter) Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
277de95e |
|
18-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: bikeshed the pipe CRC irq functions a bit - Give them an _irq_handler postfix, like all the other irq stuff. - Shuffle the DEBUG_FS=n dummy functions around a bit. This is prep work to extract all the crc debug stuff into intel_display_testing.c Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
379ef82d |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Enable CRC interrupts on pre-gen5/vlv Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4356d586 |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Wire up CRC interrupts for pre-gen5/vlv And throw in a tiny for_each_pipe refactoring for gen2. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0b5c5ed0 |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Adjust CRC capture for pre-gen5/vlv Should work down to gen2. The #defines for the interrupt sources are already there in PIPESTAT and are the same on all gmch platforms for gen2 up to vlv. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5a69b89f |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: crc support for hsw hw designers decided to change the CRC registers and coalesce them all into one. Otherwise nothing changed. I've opted for a new hsw_ version to grab the crc sample since hsw+1 will have the same crc registers, but different interrupt source registers. So this little helper function will come handy there. Also refactor the display error handler with a neat pipe loop. v2: Use for_each_pipe. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8bc5e955 |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: use ->get_vblank_counter for the crc frame counter Suggested by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5b3a856b |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: wire up CRC interrupt for ilk/snb We enable the interrupt unconditionally and only control it through the enable bit in the CRC control register. v2: Extract per-platform helpers to compute the register values. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
eba94eb9 |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: extract display_pipe_crc_update The ringbuffer update logic should always be the same, but different platforms have different amounts of CRC registers. Hence extract it. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f8c168fa |
|
16-Oct-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: static inline for dummy crc functions Also use #ifdef to keep consistent with all other such cases. Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
07144428 |
|
15-Oct-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Implement blocking read for pipe CRC files seq_file is not quite the right interface for these ones. We have a circular buffer with a new entry per vblank on one side and a process wanting to dequeue the CRC with a read(). It's quite racy to wait for vblank in user land and then try to read a pipe_crc file, sometimes the CRC interrupt hasn't been fired and we end up with an EOF. So, let's have the read on the pipe_crc file block until the interrupt gives us a new entry. At that point we can wake the reading process. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0c912c79 |
|
15-Oct-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Warn if we receive an interrupt after freeing the buffer This shouldn't happen as the buffer is freed after disable pipe CRCs, but better be safe than sorry. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ac2300d4 |
|
15-Oct-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Sample the frame counter instead of a timestamp for CRCs Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b2c88f5b |
|
15-Oct-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Keep the CRC values into a circular buffer There are a few good properties to a circular buffer, for instance it has a number of entries (before we were always dumping the full buffer). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8bf1e9f1 |
|
15-Oct-2013 |
Shuang He <shuang.he@intel.com> |
drm/i915: Expose latest 200 CRC value for pipe through debugfs There are several points in the display pipeline where CRCs can be computed on the bits flowing there. For instance, it's usually possible to compute the CRCs of the primary plane, the sprite plane or the CRCs of the bits after the panel fitter (collectively called pipe CRCs). v2: Quite a bit of rework here and there (Damien) Signed-off-by: Shuang He <shuang.he@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Fix intermediate compile file reported by Wu Fengguang's kernel builder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4cdb83ec |
|
11-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't pretend that gen2 has a hardware frame counter Gen2 doesn't have a hardware frame counter that can be read out. Just provide a stub .get_vblank_counter() that always returns 0 instead of trying to read non-existing registers. 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>
|
#
7c06b08a |
|
11-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix gen2 scanout position readout Gen2 doesn't have the pixelcount register that gen3 and gen4 have. Instead we must use the scanline counter like we do for ctg+. 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>
|
#
54ddcbd2 |
|
23-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Improve the accuracy of get_scanout_pos on CTG+ The DSL register increments at the start of horizontal sync, so it manages to miss the entire active portion of the current line. Improve the get_scanoutpos accuracy a bit when the scanout position is close to the start or end of vblank. We can do that by double checking the DSL value against the vblank status bit from ISR. Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: mario.kleiner.de@gmail.com Tested-by: mario.kleiner.de@gmail.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3aa18df8 |
|
11-Oct-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix scanoutpos calculations The reported scanout position must be relative to the end of vblank. Currently we manage to fumble that in a few ways. First we don't consider the case when vtotal != vbl_end. While that isn't very common (happens maybe only w/ old panel fitting hardware), we can fix it easily enough. The second issue is that on pre-CTG hardware we convert the pixel count to horizontal/vertical components at the very beginning, and then forget to adjust the horizontal component to be relative to vbl_end. So instead we should keep our numbers in the pixel count domain while we're adjusting the position to be relative to vbl_end. Then when we do the conversion in the end, both vertical _and_ horizontal components will come out correct. v2: Change position to int from u32 to avoid sign issues Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: mario.kleiner.de@gmail.com Tested-by: mario.kleiner.de@gmail.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c2baf4b7 |
|
23-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Skip register reads in i915_get_crtc_scanoutpos() We have all the information we need in the mode structure, so going and reading it from the hardware is pointless, and slower. We never populated ->get_vblank_timestamp() in the UMS case, and as that is the only way we'd ever call ->get_scanout_position(), we can completely ignore UMS in i915_get_crtc_scanoutpos(). Also reorganize intel_irq_init() a bit to clarify the KMS vs. UMS situation. v2: Drop UMS code Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: mario.kleiner.de@gmail.com Tested-by: mario.kleiner.de@gmail.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
391f75e2 |
|
25-Sep-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix pre-CTG vblank counter The old style frame counter increments at the start of active video. However for i915_get_vblank_counter() we want a counter that increments at the start of vblank. Fortunately the low frame counter register also contains the pixel counter for the current frame. We can can compare that against the vblank start pixel count to determine if we need to increment the frame counter by 1 to get the correct answer. Also reorganize the function pointer assignments in intel_irq_init() a bit to avoid confusing people. Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
09e14bf3 |
|
10-Oct-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Capture the initial error-state when kicking stuck rings We lost the ability to capture the first error for a stuck ring in the recent hangcheck robustification. Whilst both error states are interesting (why does the GPU not recover is also essential to debug), our primary goal is to fix the initial hang and so we need to capture the first error state upon taking hangcheck action. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
dd75fdc8 |
|
25-Sep-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Tweak RPS thresholds to more aggressively downclock After applying wait-boost we often find ourselves stuck at higher clocks than required. The current threshold value requires the GPU to be continuously and completely idle for 313ms before it is dropped by one bin. Conversely, we require the GPU to be busy for an average of 90% over a 84ms period before we upclock. So the current thresholds almost never downclock the GPU, and respond very slowly to sudden demands for more power. It is easy to observe that we currently lock into the wrong bin and both underperform in benchmarks and consume more power than optimal (just by repeating the task and measuring the different results). An alternative approach, as discussed in the bspec, is to use a continuous threshold for upclocking, and an average value for downclocking. This is good for quickly detecting and reacting to state changes within a frame, however it fails with the common throttling method of waiting upon the outstanding frame - at least it is difficult to choose a threshold that works well at 15,000fps and at 60fps. So continue to use average busy/idle loads to determine frequency change. v2: Use 3 power zones to keep frequencies low in steady-state mostly idle (e.g. scrolling, interactive 2D drawing), and frequencies high for demanding games. In between those end-states, we use a fast-reclocking algorithm to converge more quickly on the desired bin. v3: Bug fixes - make sure we reset adj after switching power zones. v4: Tune - drop the continuous busy thresholds as it prevents us from choosing the right frequency for glxgears style swap benchmarks. Instead the goal is to be able to find the right clocks irrespective of the wait-boost. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Stéphane Marchesin <stephane.marchesin@gmail.com> Cc: Owen Taylor <otaylor@redhat.com> Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com> Cc: "Zhuang, Lena" <lena.zhuang@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b29c19b6 |
|
25-Sep-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Boost RPS frequency for CPU stalls If we encounter a situation where the CPU blocks waiting for results from the GPU, give the GPU a kick to boost its the frequency. This should work to reduce user interface stalls and to quickly promote mesa to high frequencies - but the cost is that our requested frequency stalls high (as we do not idle for long enough before rc6 to start reducing frequencies, nor are we aggressive at down clocking an underused GPU). However, this should be mitigated by rc6 itself powering off the GPU when idle, and that energy use is dependent upon the workload of the GPU in addition to its frequency (e.g. the math or sampler functions only consume power when used). Still, this is likely to adversely affect light workloads. In particular, this nearly eliminates the highly noticeable wake-up lag in animations from idle. For example, expose or workspace transitions. (However, given the situation where we fail to downclock, our requested frequency is almost always the maximum, except for Baytrail where we manually downclock upon idling. This often masks the latency of upclocking after being idle, so animations are typically smooth - at the cost of increased power consumption.) Stéphane raised the concern that this will punish good applications and reward bad applications - but due to the nature of how mesa performs its client throttling, I believe all mesa applications will be roughly equally affected. To address this concern, and to prevent applications like compositors from permanently boosting the RPS state, we ratelimit the frequency of the wait-boosts each client recieves. Unfortunately, this techinique is ineffective with Ironlake - which also has dynamic render power states and suffers just as dramatically. For Ironlake, the thermal/power headroom is shared with the CPU through Intelligent Power Sharing and the intel-ips module. This leaves us with no GPU boost frequencies available when coming out of idle, and due to hardware limitations we cannot change the arbitration between the CPU and GPU quickly enough to be effective. v2: Limit each client to receiving a single boost for each active period. Tested by QA to only marginally increase power, and to demonstrably increase throughput in games. No latency measurements yet. v3: Cater for front-buffer rendering with manual throttling. v4: Tidy up. v5: Sadly the compositor needs frequent boosts as it may never idle, but due to its picking mechanism (using ReadPixels) may require frequent waits. Those waits, along with the waits for the vrefresh swap, conspire to keep the GPU at low frequencies despite the interactive latency. To overcome this we ditch the one-boost-per-active-period and just ratelimit the number of wait-boosts each client can receive. Reported-and-tested-by: Paul Neumann <paul104x@yahoo.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68716 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Stéphane Marchesin <stephane.marchesin@gmail.com> Cc: Owen Taylor <otaylor@redhat.com> Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com> Cc: "Zhuang, Lena" <lena.zhuang@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: No extern for function prototypes in headers.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
094f9a54 |
|
25-Sep-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Fix __wait_seqno to use true infinite timeouts When we switched to always using a timeout in conjunction with wait_seqno, we lost the ability to detect missed interrupts. Since, we have had issues with interrupts on a number of generations, and they are required to be delivered in a timely fashion for a smooth UX, it is important that we do log errors found in the wild and prevent the display stalling for upwards of 1s every time the seqno interrupt is missed. Rather than continue to fix up the timeouts to work around the interface impedence in wait_event_*(), open code the combination of wait_event[_interruptible][_timeout], and use the exposed timer to poll for seqno should we detect a lost interrupt. v2: In order to satisfy the debug requirement of logging missed interrupts with the real world requirments of making machines work even if interrupts are hosed, we revert to polling after detecting a missed interrupt. v3: Throw in a debugfs interface to simulate broken hw not reporting interrupts. v4: s/EGAIN/EAGAIN/ (Imre) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Don't use the struct typedef in new code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
814e9b57 |
|
23-Sep-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move the conditional seqno query into the tracepoint We only wish to know the value of seqno when emitting the tracepoint, so move the query from a parameter to the macro to inside the conditional macro body so that the query is only evaluated when required. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6ceeeec0 |
|
19-Sep-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't disable ERR_INT on the IRQ handler We currently disable the ERR_INT interrupts while running the IRQ handler because we fear that if we do an unclaimed register access from inside the IRQ handler we'll keep triggering the IRQ handler forever. The problem is that since we always disable the ERR_INT interrupts at the IRQ handler, when we get a FIFO underrun we'll always print both messages: - "uncleared fifo underrun on pipe A" - "Pipe A FIFO underrun" Because the "was_enabled" variable from ivybridge_set_fifo_underrun_reporting will always be false (since we disable ERR int at the IRQ handler!). Instead of actually fixing ivybridge_set_fifo_underrun_reporting, let's just remove the "disable ERR_INT during the IRQ handler" code. As far as we know we shouldn't really be triggering ERR_INT interrupts from the IRQ handler, so if we ever get stuck in the endless loop of interrupts we can git-bisect and revert (and we can even bisect and revert this patch in case I'm just wrong). As a bonus, our IRQ handler is now simpler and a few nanoseconds faster. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
040d2baa |
|
19-Sep-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF We'd only ever used this define to denote whether or not we have the dynamic parity feature (DPF) and never to determine whether or not L3 exists. Baytrail is a good example of where L3 exists, and not DPF. This patch provides clarify in the code for future use cases which might want to actually query whether or not L3 exists. v2: Add /* DPF == dynamic parity feature */ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
35a85ac6 |
|
19-Sep-2013 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Add second slice l3 remapping Certain HSW SKUs have a second bank of L3. This L3 remapping has a separate register set, and interrupt from the first "slice". A slice is simply a term to define some subset of the GPU's l3 cache. This patch implements both the interrupt handler, and ability to communicate with userspace about this second slice. v2: Remove redundant check about non-existent slice. Change warning about interrupts of unknown slices to WARN_ON_ONCE Handle the case where we get 2 slice interrupts concurrently, and switch the tracking of interrupts to be non-destructive (all Ville) Don't enable/mask the second slice parity interrupt for ivb/vlv (even though all docs I can find claim it's rsvd) (Ville + Bryan) Keep BYT excluded from L3 parity v3: Fix the slice = ffs to be decremented by one (found by Ville). When I initially did my testing on the series, I was using 1-based slice counting, so this code was correct. Not sure why my simpler tests that I've been running since then didn't pick it up sooner. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
67c347ff |
|
17-Sep-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: only report hpd connector status change when it actually changed This reduces dmesg noise when there's a glitch on the hpd line, or there are more than one connectors on the same hpd line and only one of them changes. While at it, switch to use the friendly status names instead of numbers. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
17e1df07 |
|
08-Sep-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix wait_for_pending_flips vs gpu hang deadlock My g33 here seems to be shockingly good at hitting them all. This time around kms_flip/flip-vs-panning-vs-hang blows up: intel_crtc_wait_for_pending_flips correctly checks for gpu hangs and if a gpu hang is pending aborts the wait for outstanding flips so that the setcrtc call will succeed and release the crtc mutex. And the gpu hang handler needs that lock in intel_display_handle_reset to be able to complete outstanding flips. The problem is that we can race in two ways: - Waiters on the dev_priv->pending_flip_queue aren't woken up after we've the reset as pending, but before we actually start the reset work. This means that the waiter doesn't notice the pending reset and hence will keep on hogging the locks. Like with dev->struct_mutex and the ring->irq_queue wait queues we there need to wake up everyone that potentially holds a lock which the reset handler needs. - intel_display_handle_reset was called _after_ we've already signalled the completion of the reset work. Which means a waiter could sneak in, grab the lock and never release it (since the pageflips won't ever get released). Similar to resetting the gem state all the reset work must complete before we update the reset counter. Contrary to the gem reset we don't need to have a second explicit wake up call since that will have happened already when completing the pageflips. We also don't have any issues that the completion happens while the reset state is still pending - wait_for_pending_flips is only there to ensure we display the right frame. After a gpu hang&reset events such guarantees are out the window anyway. This is in contrast to the gem code where too-early wake-up would result in unnecessary restarting of ioctls. Also, since we've gotten these various deadlocks and ordering constraints wrong so often throw copious amounts of comments at the code. This deadlock regression has been introduced in the commit which added the pageflip reset logic to the gpu hang work: commit 96a02917a0131e52efefde49c2784c0421d6c439 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Feb 18 19:08:49 2013 +0200 drm/i915: Finish page flips and update primary planes after a GPU reset v2: - Add comments to explain how the wake_up serves as memory barriers for the atomic_t reset counter. - Improve the comments a bit as suggested by Chris Wilson. - Extract the wake_up calls before/after the reset into a little i915_error_wake_up and unconditionally wake up the pending_flip_queue waiters, again as suggested by Chris Wilson. v3: Throw copious amounts of comments at i915_error_wake_up as suggested by Chris Wilson. Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
da661464 |
|
06-Sep-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: include hangcheck action and score in error_state Score and action reveals what all the rings were doing and why hang was declared. Add idle state so that we can distinguish between waiting and idle ring. v2: - add idle as a hangcheck action - consensed hangcheck status to single line (Chris) - mark active explicitly when we are making progress (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
122f46ba |
|
04-Sep-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix gpu hang vs. flip stall deadlocks Since we've started to clean up pending flips when the gpu hangs in commit 96a02917a0131e52efefde49c2784c0421d6c439 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Feb 18 19:08:49 2013 +0200 drm/i915: Finish page flips and update primary planes after a GPU reset the gpu reset work now also grabs modeset locks. But since work items on our private work queue are not allowed to do that due to the flush_workqueue from the pageflip code this results in a neat deadlock: INFO: task kms_flip:14676 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kms_flip D ffff88019283a5c0 0 14676 13344 0x00000004 ffff88018e62dbf8 0000000000000046 ffff88013bdb12e0 ffff88018e62dfd8 ffff88018e62dfd8 00000000001d3b00 ffff88019283a5c0 ffff88018ec21000 ffff88018f693f00 ffff88018eece000 ffff88018e62dd60 ffff88018eece898 Call Trace: [<ffffffff8138ee7b>] schedule+0x60/0x62 [<ffffffffa046c0dd>] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915] [<ffffffff81050ff4>] ? finish_wait+0x60/0x60 [<ffffffffa0478041>] intel_crtc_set_config+0x7f3/0x81e [i915] [<ffffffffa031780a>] drm_mode_set_config_internal+0x4f/0xc6 [drm] [<ffffffffa0319cf3>] drm_mode_setcrtc+0x44d/0x4f9 [drm] [<ffffffff810e44da>] ? might_fault+0x38/0x86 [<ffffffffa030d51f>] drm_ioctl+0x2f9/0x447 [drm] [<ffffffff8107a722>] ? trace_hardirqs_off+0xd/0xf [<ffffffffa03198a6>] ? drm_mode_setplane+0x343/0x343 [drm] [<ffffffff8112222f>] ? mntput_no_expire+0x3e/0x13d [<ffffffff81117f33>] vfs_ioctl+0x18/0x34 [<ffffffff81118776>] do_vfs_ioctl+0x396/0x454 [<ffffffff81396b37>] ? sysret_check+0x1b/0x56 [<ffffffff81118886>] SyS_ioctl+0x52/0x7d [<ffffffff81396b12>] system_call_fastpath+0x16/0x1b 2 locks held by kms_flip/14676: #0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa0316545>] drm_modeset_lock_all+0x22/0x59 [drm] #1: (&crtc->mutex){+.+.+.}, at: [<ffffffffa031656b>] drm_modeset_lock_all+0x48/0x59 [drm] INFO: task kworker/u8:4:175 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u8:4 D ffff88018de9a5c0 0 175 2 0x00000000 Workqueue: i915 i915_error_work_func [i915] ffff88018e37dc30 0000000000000046 ffff8801938ab8a0 ffff88018e37dfd8 ffff88018e37dfd8 00000000001d3b00 ffff88018de9a5c0 ffff88018ec21018 0000000000000246 ffff88018e37dca0 000000005a865a86 ffff88018de9a5c0 Call Trace: [<ffffffff8138ee7b>] schedule+0x60/0x62 [<ffffffff8138f23d>] schedule_preempt_disabled+0x9/0xb [<ffffffff8138d0cd>] mutex_lock_nested+0x205/0x3b1 [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa0477094>] ? intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915] [<ffffffffa044e0a2>] i915_error_work_func+0x128/0x147 [i915] [<ffffffff8104a89a>] process_one_work+0x1d4/0x35a [<ffffffff8104a821>] ? process_one_work+0x15b/0x35a [<ffffffff8104b4a5>] worker_thread+0x144/0x1f0 [<ffffffff8104b361>] ? rescuer_thread+0x275/0x275 [<ffffffff8105076d>] kthread+0xac/0xb4 [<ffffffff81059d30>] ? finish_task_switch+0x3b/0xc0 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60 [<ffffffff81396a6c>] ret_from_fork+0x7c/0xb0 [<ffffffff810506c1>] ? __kthread_parkme+0x60/0x60 3 locks held by kworker/u8:4/175: #0: (i915){.+.+.+}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a #1: ((&dev_priv->gpu_error.work)){+.+.+.}, at: [<ffffffff8104a821>] process_one_work+0x15b/0x35a #2: (&crtc->mutex){+.+.+.}, at: [<ffffffffa0477094>] intel_display_handle_reset+0x7e/0xbd [i915] This blew up while running kms_flip/flip-vs-panning-vs-hang-interruptible on one of my older machines. Unfortunately (despite the proper lockdep annotations for flush_workqueue) lockdep still doesn't detect this correctly, so we need to rely on chance to discover these bugs. Apply the usual bugfix and schedule the reset work on the system workqueue to keep our own driver workqueue free of any modeset lock grabbing. Note that this is not a terribly serious regression since before the offending commit we'd simply have stalled userspace forever due to failing to abort all outstanding pageflips. v2: Add a comment as requested by Chris. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
645416f5 |
|
02-Sep-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix hpd work vs. flush_work in the pageflip code deadlock Historically we've run our own driver hotplug handling in our own work-queue, which then launched the drm core hotplug handling in the system workqueue. This is important since we flush our own driver workqueue in the pageflip code while hodling modeset locks, and only the drm hotplug code grabbed these locks. But with commit 69787f7da6b2adc4054357a661aaa1701a9ca76f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Oct 23 18:23:34 2012 +0000 drm: run the hpd irq event code directly this was changed and now we could deadlock in our flip handler if there's a hotplug work blocking the progress of the crucial unpin works. So this broke the careful deadlock avoidance implemented in commit b4a98e57fc27854b5938fc8b08b68e5e68b91e1f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Nov 1 09:26:26 2012 +0000 drm/i915: Flush outstanding unpin tasks before pageflipping Since the rule thus far has been that work items on our own workqueue may never grab modeset locks simply restore that rule again. v2: Add a comment to the declaration of dev_priv->wq to warn readers about the tricky implications of using it. Suggested by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Stuart Abercrombie <sabercrombie@chromium.org> Reported-by: Stuart Abercrombie <sabercrombie@chromium.org> References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/26239 Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Squash in a comment at the place where we schedule the work. Requested after-the-fact by Chris on irc since the hpd work isn't the only place we botch this.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b8d88d1d |
|
28-Aug-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: tune down hangcheck noise We already have a big splashing *ERROR* for all the relevant cases of hangs, so this one here is redudant. And it results in an unclean dmesg when running with simulated hangs. Regression has been introduced in commit 05407ff889ceebe383aa5907219f86582ef96b72 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu May 30 09:04:29 2013 +0300 drm/i915: detect hang using per ring hangcheck_score Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68641 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c67a470b |
|
19-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: allow package C8+ states on Haswell (disabled) This patch allows PC8+ states on Haswell. These states can only be reached when all the display outputs are disabled, and they allow some more power savings. The fact that the graphics device is allowing PC8+ doesn't mean that the machine will actually enter PC8+: all the other devices also need to allow PC8+. For now this option is disabled by default. You need i915.allow_pc8=1 if you want it. This patch adds a big comment inside i915_drv.h explaining how it works and how it tracks things. Read it. v2: (this is not really v2, many previous versions were already sent, but they had different names) - Use the new functions to enable/disable GTIMR and GEN6_PMIMR - Rename almost all variables and functions to names suggested by Chris - More WARNs on the IRQ handling code - Also disable PC8 when there's GPU work to do (thanks to Ben for the help on this), so apps can run caster - Enable PC8 on a delayed work function that is delayed for 5 seconds. This makes sure we only enable PC8+ if we're really idle - Make sure we're not in PC8+ when suspending v3: - WARN if IRQs are disabled on __wait_seqno - Replace some DRM_ERRORs with WARNs - Fix calls to restore GT and PM interrupts - Use intel_mark_busy instead of intel_ring_advance to disable PC8 v4: - Use the force_wake, Luke! v5: - Remove the "IIR is not zero" WARNs - Move the force_wake chunk to its own patch - Only restore what's missing from RC6, not everything Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1403c0d4 |
|
15-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: merge HSW and SNB PM irq handlers Because hsw_pm_irq_handler does exactly what gen6_rps_irq_handler does and also processes the 2 additional VEBOX bits. So merge those functions and wrap the VEBOX bits on a HAS_VEBOX check. This check isn't really necessary since the bits are reserved on SNB/IVB/VLV, but it's a good documentation on who uses them. v2: - Change IS_HASWELL check to HAS_VEBOX Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4d3b3d5f |
|
09-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: fix how we mask PMIMR when adding work to the queue It seems we've been doing this ever since we started processing the RPS events on a work queue, on commit "drm/i915: move gen6 rps handling to workqueue", 4912d04193733a825216b926ffd290fada88ab07. The problem is: when we add work to the queue, instead of just masking the bits we queued and leaving all the others on their current state, we mask the bits we queued and unmask all the others. This basically means we'll be unmasking a bunch of interrupts we're not going to process. And if you look at gen6_pm_rps_work, we unmask back only GEN6_PM_RPS_EVENTS, which means the bits we unmasked when adding work to the queue will remain unmasked after we process the queue. Notice that even though we unmask those unrelated interrupts, we never enable them on IER, so they don't fire our interrupt handler, they just stay there on IIR waiting to be cleared when something else triggers the interrupt handler. So this patch does what seems to make more sense: mask only the bits we add to the queue, without unmasking anything else, and so we'll unmask them after we process the queue. As a side effect we also have to remove that WARN, because it is not only making sure we don't mask useful interrupts, it is also making sure we do unmask useless interrupts! That piece of code should not be responsible for knowing which bits should be unmasked, so just don't assert anything, and trust that snb_disable_pm_irq should be doing the right thing. With i915.enable_pc8=1 I was getting ocasional "GEN6_PMIIR is not 0" error messages due to the fact that we unmask those unrelated interrupts but don't enable them. Note: if bugs start bisecting to this patch, then it probably means someone was relying on the fact that we unmask everything by accident, then we should fix gen5_gt_irq_postinstall or whoever needs the accidentally unmasked interrupts. Or maybe I was just wrong and we need to revert this patch :) Note: This started to be a more real issue with the addition of the VEBOX support since now we do enable more than just the minimal set of RPS interrupts in the IER register. Which means after the first rps interrupt has happened we will never mask the VEBOX user interrupts again and so will blow through cpu time needlessly when running video workloads. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add note that this started to matter with VEBOX much more.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
60611c13 |
|
15-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't queue PM events we won't process On SNB/IVB/VLV we only call gen6_rps_irq_handler if one of the IIR bits set is part of GEN6_PM_RPS_EVENTS, but at gen6_rps_irq_handler we add all the enabled IIR bits to the work queue, not only the ones that are part of GEN6_PM_RPS_EVENTS. But then gen6_pm_rps_work only processes GEN6_PM_RPS_EVENTS, so it's useless to add anything that's not GEN6_PM_RPS_EVENTS to the work queue. As a bonus, gen6_rps_irq_handler looks more similar to hsw_pm_irq_handler, so we may be able to merge them in the future. v2: - Add a WARN in case we queued something we're not going to process. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
333a8204 |
|
06-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't disable/reenable IVB error interrupts when not needed If the error interrupts are already disabled, don't disable and reenable them. This is going to be needed when we're in PC8+, where all the interrupts are disabled so we won't risk re-enabling DE_ERR_INT_IVB. v2: Use dev_priv->irq_mask (Chris) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
605cd25b |
|
06-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add dev_priv->pm_irq_mask Just like irq_mask and gt_irq_mask, use it to track the status of GEN6_PMIMR so we don't need to read it again every time we call snb_update_pm_irq. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f52ecbcf |
|
06-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't update GEN6_PMIMR when it's not needed I did some brief tests and the "new_val = pmimr" condition usually happens a few times after exiting games. Note: This is also prep work to track the GEN6_PMIMR register state in dev_priv->pm_imr. This happens in the next patch. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add note to explain why we want this, as per the discussion between Chris and Paulo.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
edbfdb45 |
|
06-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: wrap GEN6_PMIMR changes Just like we're doing with the other IMR changes. One of the functional changes is that not every caller was doing the POSTING_READ. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
43eaea13 |
|
06-Aug-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: wrap GTIMR changes Just like the functions that touch DEIMR and SDEIMR, but for GTIMR. The new functions contain a POSTING_READ(GTIMR) which was not present at the 2 callers inside i915_irq.c. The implementation is based on ibx_display_interrupt_update. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ea04cb31 |
|
10-Aug-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: drop unnecessary local variable to suppress build warning Although I could not reproduce this (different compiler version, perhaps), reportedly we get: drivers/gpu/drm/i915/i915_irq.c:1943:27: warning: ‘score’ may be used uninitialized in this function [-Wuninitialized] Drop the 'score' variable altogether as it's not really needed. Reported-by: Kees Cook <keescook@chromium.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f2f4d82f |
|
10-Aug-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: give more distinctive names to ring hangcheck action enums The short lowercase names are bound to collide. The default warnings don't even warn about shadowing. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c8b5018b |
|
10-Aug-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: remove unused leftover variable irq_received It's been there since i8xx_irq_handler() was added in commit c2798b19bac2538393fc932bfbe59807a4734b3e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Apr 22 21:13:57 2012 +0100 drm/i915: i8xx interrupt handler Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a658b5d2 |
|
08-Aug-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Make i915_hangcheck_elapsed() static Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b8f102e8 |
|
26-Jul-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Add messages useful for HPD storm detection debugging (v2) For HPD storm detection we now mask out individual interrupt source bits. We have already seen a case where HPD interrupt enable bits were assigned to the wrong pins. To track these conditions more easily add some debugging messages. v2: Spelling fixes as suggested by Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
907b28c5 |
|
19-Jul-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Colocate all GT access routines in the same file Currently, the register access code is split between i915_drv.c and intel_pm.c. It only bares a superficial resemblance to the reset of the powermanagement code, so move it all into its own file. This is to ease further patches to enforce serialised register access. v2: Scan for random abuse of I915_WRITE_NOTRACE v3: Take the opportunity to rename the GT functions as uncore. Uncore is the term used by the hardware design (and bspec) for all functions outside of the GPU (and CPU) cores in what is also known as the System Agent. v4: Rebase onto SNB rc6 fixes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Wrestle patch into applying and inline intel_uncore_early_sanitize (plus move the old comment to the new function). Also keep the _santize postfix for intel_uncore_sanitize.] [danvet: Squash in fixup spotted by Chris on irc: We need to call intel_pm_init before intel_uncore_sanitize since the later will call cancel_work on the delayed rps setup work the former initializes.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d8fc8a47 |
|
19-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: invert {ilk, snb}_gt_irq_handler check Requested by Chris Wilson on IRC. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cce723ed |
|
19-Jul-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Make i915 events part of uapi Make the uevent strings part of the user API for people who wish to write their own listeners. v2: Make a space in the string concatenation. (Chad) Use the "UEVENT" suffix intead of "EVENT" (Chad) Make kernel-doc parseable Docbook comments (Daniel) v3: Undid reset change introduced in last submission (Daniel) Fixed up comments to address removal changes. Thanks to Daniel Vetter for a majority of the parity error comments. CC: Chad Versace <chad.versace@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8e76f8dc |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: kill ivybridge_irq_postinstall It was very similar to ironlake_irq_postinstall, so IMHO merging both functions results in a code that is easier to maintain. With this change, all the irq handler vfuncs between ironlake and ivybridge are now unified. v2: Add "(" and ")" to make at least one vim user much happier (Chris) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b518421f |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: kill Ivybridge vblank irq vfuncs The IVB funtions are exactly the same as the ILK ones, with the exception of the bit register. So add IVB/HSW support to ironlake_enable_vblank and ironlake_disable_vblank, then kill the ivybridge functions. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f1af8fc1 |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add ILK/SNB support to ivybridge_irq_handler And then rename it to ironlake_irq_handler. Also move ilk_gt_irq_handler up to avoid forward declarations. In the previous patches I did small modifications to both ironlake_irq_handler an ivybridge_irq_handler so they became very similar functions. Now it should be very easy to verify that all we need to add ILK/SNB support is to call ilk_gt_irq_handler, call ilk_display_irq_handler and avoid reading pm_iir on gen 5. v2: - Rebase due to changes on the previous patches - Move pm_iir to a tighter scope (Chris) - Change some Gen checks for readability Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
23a78516 |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: POSTING_READ(DEIER) on ivybridge_irq_handler We have this POSTING_READ inside ironlake_irq_handler. I suppose we also want it on IVB because we want to stop the IRQ handler as soon as possible at this point. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
27b9188e |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: reorganize ironlake_irq_handler The ironlake_irq_handler and ivybridge_irq_handler functions do basically the same thing, but they have different implementation styles. With this patch we reorganize ironlake_irq_handler in a way that makes it look very similar to ivybridge_irq_handler. One of the advantages of this new function style is that we don't write 0 to the IIR registers anymore. v2: - Rebase due to changes on previous patches - Move pm_iir to a tighter scope (Chris) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
221ab43e |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: don't read or write GEN6_PMIIR on Gen 5 The register doesn't exist on Gen 5. v2: Simplify checks since pm_iir is always 0 on Gen 5 (Chris) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9719fb98 |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: extract ivb_display_irq_handler Just like we did with ilk_display_irq_handler. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c008bc6e |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: extract ilk_display_irq_handler It's the code that deals with de_iir. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
31694658 |
|
12-Jul-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: kill ivybridge_irq_preinstall After Daniel's latest changes it's now equal to ironlake_irq_preinstall. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
10cd45b6 |
|
03-Jul-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: introduce i915_queue_hangcheck To run hangcheck in near future. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0a9a8c91 |
|
12-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: unify GT/PM irq postinstall code Again extract a common helper. For the postinstall hook things are a bit more complicated since we have more cases on ilk-hsw/vlv here. But since vlv was clearly broken by failing to initialize dev_priv->gt_irq_mask correctly the shared code is clearly justified. Also kill the PMIER setting in the async rps enable work. I should have been save, but also clearly looked rather fragile. PMIER setup is now all down in the irq pre/postinstall hooks. With this we now have the usual interrupt register sequence for GT/PM irq registers: - IER is setup once with all the interrupts we ever need in the postinstall hook and never touched again. Exceptions are SDEIER, which is touched in the preinstall hook (when the irq handler isn't enabled) and then only from the irq handler. And DEIER/VLV_IER with is used in the irq handler but also written to once in the postinstall hook. But since that write is essentially what enables the interrupt and we should always have MSI interrupts we should be save. In case we ever have non-MSI interrupts we'd be screwed. - IIR is cleared in the postinstall hook before we enable/unmask the respective interrupt sources. Hence we can't steal an interrupt event an accidentally trigger the spurious interrupt logic in the core kernel. Note that after some discussion with Ben Widawsky we think that we actually should clear the IIR registers in the preinstall hook. But doing that is a much larger patch series. - IMR regs are (usually) all masked off. Those are the only regs changed at runtime, which is all protected by dev_priv->irq_lock. This unification also kills the cargo-culted read-modify-write PM register setup for VECS. Interrupt setup is done without userspace being able to interfere, so we better know what values we want to put into those registers. RMW cycles otoh are really good at papering over races, until stuff magically blows up and no one has a clue why. v2: Touch the gen6+ PM interrupt registers only on gen6+. v3: Improve the commit message to more clearly spell out why we want to unify the code and what exactly changes. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add a comment to explain why the l3 parity interrupt is special.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d18ea1b5 |
|
12-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: unify PM interrupt preinstall sequence Since the addition of VECS we have a slightly different enable sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that will end up in hard to track down surprises. Hence unifiy things and since we have copies of this code in 3 places now, extract it into its own little helper. Note that this changes the irq preinstall sequence a bit for snb and vlv: We now also clear the PM registers in the preinstall hook, in addition to the PM register clearing/setup already done when actually enabling rps. So this doesn't fix a bug but simply unifies the code across all platforms. After the postinstall hook is similarly unified we can rip out the then redundant PM interrupt setup from the rps code. v3: Rebase on top of the retained double-GTIIR clearing. Also resurrect the masking/disabling of the gen6+ PM interrupts as spotted by Ben Widaswky. v4: Move the DE interrupt reset code out of gen5_gt_irq_preinstall back to ironlake_irq_preinstall where it really belongs. Spotted by Paulo. v3: Improve the commit message to more clearly spell out why we want to unify the code and what exactly changes. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: s/GT/PM/ to fix up a comment which Ben spotted while reviewing.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
84734a04 |
|
12-Jul-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: move error state to own compilation unit Move error state generation and stringification to it's own compilation unit. Sysfs also uses this so it can't be under CONFIG_DEBUG_FS This fixes a regression introduced in commit ef86ddced720fddc3835558447a7f594d3609c73 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu Jun 6 17:38:54 2013 +0300 drm/i915: add error_state sysfs entry Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66814 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reported-by: kbuild test robot <fengguang.wu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c0d6a3dd |
|
04-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: don't enable PM_VEBOX_CS_ERROR_INTERRUPT The code to handle it is broken - there's simply no code to clear CS parser errors on gen5+. And behold, for all the other rings we also don't enable it! Leave the handling code itself in place just to be consistent with the existing mess though. And in case someone feels like fixing it all up. This has been errornously enabled in commit 12638c57f31952127c734c26315e1348fa1334c2 Author: Ben Widawsky <ben@bwidawsk.net> Date: Tue May 28 19:22:31 2013 -0700 drm/i915: Enable vebox interrupts Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
59cdb63d |
|
04-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: kill dev_priv->rps.lock Now that the rps interrupt locking isn't clearly separated (at elast conceptually) from all the other interrupt locking having a different lock stopped making sense: It protects much more than just the rps workqueue it started out with. But with the addition of VECS the separation started to blurr and resulted in some more complex locking for the ring interrupt refcount. With this we can (again) unifiy the ringbuffer irq refcounts without causing a massive confusion, but that's for the next patch. v2: Explain better why the rps.lock once made sense and why no longer, requested by Ben. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2adbee62 |
|
04-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: queue work outside spinlock in hsw_pm_irq_handler And kill the comment about it. Queueing work is a barrier type event, no amount of locking will help in ordering things (as long as we queue the work after having updated all relevant data structures). Also, the queue_work works itself as a sufficient memory barrier. Again on the surface this is just a tiny micro-optimization to reduce the hold-time of dev_priv->irq_lock. But the better reason is that it reduces superficial locking and so makes it clearer what we actually need for correctness. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
41a05a3a |
|
04-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: streamline hsw_pm_irq_handler The if (pm_iir & ~GEN6_PM_RPS_EVENTS) check was redunandant. Otoh adding a check for rps events allows us to avoid the spinlock grabbing for VECS interrupts. v2: Drop misplaced hunk which now moved to the right patch. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d0ecd7e2 |
|
04-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: irq handlers don't need interrupt-safe spinlocks Since we only have one interrupt handler and interrupt handlers are non-reentrant. To drive the point really home give them all an _irq_handler suffix. This is a tiny micro-optimization but even more important it makes it clearer what locking we actually need. And in case someone screws this up: lockdep will catch hardirq vs. other context deadlocks. v2: Fix up compile fail. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
de28075d |
|
04-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: kill lpt pch transcoder->crtc mapping code for fifo underruns It's racy: There's no guarantee that we won't walk this code (due to a pch fifo underrun interrupt) while someone is changing the pointers around. The only reason we do this is to use the righ crtc for the pch fifo underrun accounting. But we never expose this to userspace, so essentially no one really cares if we use the "wrong" crtc. So let's just rip it out. With this patch fifo underrun code will always use crtc A for tracking underruns on the (only) pch transcoder on LPT. v2: Add a big comment explaining what's going on. Requested by Paulo. v3: Fixup spelling in comment as spotted by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7336df65 |
|
09-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: improve GEN7_ERR_INT clearing for fifo underrun reporting Same treatment as for SERR_INT: If we clear only the bit for the pipe we're enabling (but unconditionally) then we can always check for possible underruns after having disabled the interrupt. That way pipe underruns won't be lost, but at worst only get reported in a delayed fashion. v2: The same logic bug as in the SERR handling change also existed here. The same bugfix of only reporting missed underruns when the error interrupt was masked applies, too. v3: Do the same fixes as for the SERR handling that Paulo suggested in his review: - s/%i/%c/ fix in the debug output - move the DE_ERR_INT_IVB read into the respective if block Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix up the checkpatch bikeshed Paulo noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1dd246fb |
|
10-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: improve SERR_INT clearing for fifo underrun reporting The current code won't report any fifo underruns on cpt if just one pipe has fifo underrun reporting disabled. We can't enable the interrupts, but we can still check the per-transcoder bits and so report the underrun delayed if: - We always clear the transcoder's bit (and none of the other bits) when enabling. - We check the transcoder's bit after disabling (to avoid racing with the interrupt handler). v2: I've forgotten to actually remove the old SERR_INT clearing. v3: Use transcoder_name as suggested by Paulo Zanoni. Paulo also noticed a logic bug: When an underrun interrupt fires we report it both in the interrupt handler and when checking for underruns when disabling it in cpt_set_fifo_underrun_reporting. But that second check is only required if the interrupt is disabled and we're switching of underrun reporting (e.g. because we're disabling the crtc). Hence check for that condition. At first I wanted to rework the code to pass that bit of information from the uppper functions down to cpt_set_fifo_underrun_reporting. But that turned out too messy. Hence the quick&dirty check whether the south error interrupt source is masked off or not. v4: Streamline the control flow a bit. v5: s/pipe/pch transcoder/ in the dmesg output, suggested by Paulo. v6: Review from Paulo: - Reorder the was_enabled assignment to only read the register when we need it. Also add a comment that we need to do that before updating the register. - s/%i/%c/ fix for the debug output. - Fix the checkpath complaint in the SERR_INT_TRANS_FIFO_UNDERRUN #define. v7: Hopefully put that elusive SERR hunk back into this patch, spotted by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fee884ed |
|
04-Jul-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: extract ibx_display_interrupt_update This way all changes to SDEIMR all go through the same function, with the exception of the (single-threaded) setup/teardown code. For paranoia again add an assert_spin_locked. v2: For even more paranoia also sprinkle a spinlock assert over cpt_can_enable_serr_int since we need to have that one there, too. v3: Fix the logic of interrupt enabling, add enable/disable macros for the simple cases in the fifo code and add a comment. All requested by Paulo. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f343c5f6 |
|
05-Jul-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Getter/setter for object attributes Soon we want to gut a lot of our existing assumptions how many address spaces an object can live in, and in doing so, embed the drm_mm_node in the object (and later the VMA). It's possible in the future we'll want to add more getter/setter methods, but for now this is enough to enable the VMAs. v2: Reworked commit message (Ben) Added comments to the main functions (Ben) sed -i "s/i915_gem_obj_set_color/i915_gem_obj_ggtt_set_color/" drivers/gpu/drm/i915/*.[ch] sed -i "s/i915_gem_obj_bound/i915_gem_obj_ggtt_bound/" drivers/gpu/drm/i915/*.[ch] sed -i "s/i915_gem_obj_size/i915_gem_obj_ggtt_size/" drivers/gpu/drm/i915/*.[ch] sed -i "s/i915_gem_obj_offset/i915_gem_obj_ggtt_offset/" drivers/gpu/drm/i915/*.[ch] (Daniel) v3: Rebased on new reserve_node patch Changed DRM_DEBUG_KMS to actually work (will need fixing later) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b79480ba |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: assert_spin_locked for pipestat interrupt enable/disable Just to keep the paranoia equal also sprinkle locking asserts over the pipestat interrupt enable/disable functions. Again this results in false positives in the interrupt setup. Add bogo-locking for these and a big comment explaining why it's there and that it's indeed unnecessary. v2: Fix up the spelling fail Paulo spotted in comments. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ef86ddce |
|
06-Jun-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: add error_state sysfs entry As getting error state doesn't anymore require big kmallocs, make error state accessible also from sysfs. v2: - error state clearing (Chris Wilson) - user hint, proper access mode bits and name (Daniel Vetter) v3: release resources in proper order (Chris Wilson) Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Apply Chris' s/error_state/error/ bikeshed on the sysfs name. Also update the dmesg message, spotted by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
26b7c224 |
|
27-Jun-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Extract error buffer capture This helps when we have per VM buffer capturing. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5476f850 |
|
27-Jun-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Remove extra error state NULL Not only was there an extra, but since we now kzalloc the error state, we don't need either. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3ef8fb5a |
|
24-Jun-2013 |
Damien Lespiau <damien.lespiau@intel.com> |
drm/i915: Bail out once we've found the context object Once we've found the the context object programmed in CCID, there's no need to look the other objects in the list. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b5ea2d56 |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix hpd interrupt register locking Our interrupt handler (in hardirq context) could race with the timer (in softirq context), hence we need to hold the spinlock around the call to ->hdp_irq_setup in intel_hpd_irq_handler, too. But as an optimization (and more so to clarify things) we don't need to do the irqsave/restore dance in the hardirq context. Note also that on ilk+ the race isn't just against the hotplug reenable timer, but also against the fifo underrun reporting. That one also modifies the SDEIMR register (again protected by the same dev_priv->irq_lock). To lock things down again sprinkle a assert_spin_locked. But exclude the functions touching SDEIMR for now, I want to extract them all into a new helper function (like we do already for pipestate, display interrupts and all the various gt interrupts). v2: Add the missing 't' Egbert spotted in a comment. v3: Actually fix the right misspelled comment (Paulo). Cc: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
91d131d2 |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fold the no-irq check into intel_hpd_irq_handler The usual pattern for our sub-function irq_handlers is that they check for the no-irq case themselves. This results in more streamlined code in the upper irq handlers. v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <eich@suse.de> Reviewed-by: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5876fa0d |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fold the queue_work into intel_hpd_irq_handler Everywhere the same. Note that this patch leaves unnecessary braces behind, but the next patch will kill those all anyway (including the if itself) so I've figured I can keep the diff a bit smaller. v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <eich@suse.de> Reviewed-by: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
10a504de |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fold the hpd_irq_setup call into intel_hpd_irq_handler We already have a vfunc for this (and other parts of the hpd storm handling code already use it). v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <eich@suse.de> Reviewed-by: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
22062dba |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: s/hotplug_irq_storm_detect/intel_hpd_irq_handler/ The combination of Paulo's fifo underrun detection code and Egbert's hpd storm handling code unfortunately made the hpd storm handling code racy. To avoid duplicating tricky interrupt locking code over all platforms start with a bit of refactoring. This patch is the very first step since in the end the irq storm handling code will handle all hotplug logic (and so also encapsulate the locking nicely). v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <eich@suse.de> Reviewed-by: Egbert Eich <eich@suse.de> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6005ce42 |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: close tiny race in the ilk pcu even interrupt setup By the time we write DEIER in the postinstall hook the interrupt handler could run any time. And it does modify DEIER to handle interrupts. Hence the DEIER read-modify-write cycle for enabling the PCU event source is racy. Close this races the same way we handle vblank interrupts: Unconditionally enable the interrupt in the IER register, but conditionally mask it in IMR. The later poses no such race since the interrupt handler does not touch DEIMR. Also update the comment, the clearing has already happened unconditionally above. v2: Actually shove the updated comment into the right train^W commit, as spotted by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4bc9d430 |
|
27-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix locking around ironlake_enable|disable_display_irq The haswell unclaimed register handling code forgot to take the spinlock. Since this is in the context of the non-rentrant interupt handler and we only have one interrupt handler it is sufficient to just grab the spinlock - we do not need to exclude any other interrupts from running on the same cpu. To prevent such gaffles in the future sprinkle assert_spin_locked over these functions. Unfornately this requires us to hold the spinlock in the ironlake postinstall hook where it is not strictly required: Currently that is run in single-threaded context and with userspace exlcuded from running concurrent ioctls. Add a comment explaining this. v2: ivb_can_enable_err_int also needs to be protected by the spinlock. To ensure this won't happen in the future again also sprinkle a spinlock assert in there. v3: Kill the 2nd call to ivb_can_enable_err_int I've accidentally left behind, spotted by Paulo. Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <przanoni@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7425034a |
|
25-Jun-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Jump to at least RPe on VLV when increasing the GPU frequency If the current GPU frquency is below RPe, and we're asked to increase it, just go directly to RPe. This should provide better performance faster than letting the frequency trickle up in response to the up threshold interrupts. For now just do it for VLV, since that matches quite closely how VLV used to operate when the rps delayed timer kept things at RPe always. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d8289c9e |
|
25-Jun-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Make the rps new_delay comparison more readable Eliminate the weird inverted logic from the rps new_delay comparison. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4f7fd709 |
|
24-Jun-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fix up sdvo hpd pins for i965g/gm Bspec seems to be full of lies, at least it disagress with reality: Two systems corrobated that SDVO hpd bits are the same as on gen3. v2: Update comment a bit. Cc: Arthur Ranyan <arthur.j.runyan@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reported-and-tested-by: Alex Fiestas <afiestas@kde.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
acd78c11 |
|
13-Jun-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Remove extra "ring" from error message The ring names already have "ring" in it. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ad8beaea |
|
11-Jun-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: store ring hangcheck action For guilty batchbuffer analysis later on when rings are reset, store what state the ring was on when hang was declared. This helps to weed out the waiting rings from the active ones. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a43adf07 |
|
10-Jun-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Eliminate the addr/seqno from the hangcheck warning This is of no value to the developer reading the report, let alone the bamboozled user. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6274f212 |
|
10-Jun-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Don't count semaphore waits towards a stuck ring If we detect a ring is in a valid wait for another, just let it be. Eventually it will either begin to progress again, or the entire system will come grinding to a halt and then hangcheck will fire as soon as the deadlock is detected. This error was foretold by Ben in commit 05407ff889ceebe383aa5907219f86582ef96b72 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu May 30 09:04:29 2013 +0300 drm/i915: detect hang using per ring hangcheck_score "If ring B is waiting on ring A via semaphore, and ring A is making progress, albeit slowly - the hangcheck will fire. The check will determine that A is moving, however ring B will appear hung because the ACTHD doesn't move. I honestly can't say if that's actually a realistic problem to hit it probably implies the timeout value is too low." v2: Make sure we don't even incur the KICK cost whilst waiting. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65394 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9107e9d2 |
|
10-Jun-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only slightly increment hangcheck score if we succesfully kick a ring After kicking a ring, it should be free to make progress again and so should not be accused of being stuck until hangcheck fires once more. In order to catch a denial-of-service within a batch or across multiple batches, we still do increment the hangcheck score - just not as severely so that it takes multiple kicks to fail. This should address part of Ben's justified criticism of commit 05407ff889ceebe383aa5907219f86582ef96b72 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu May 30 09:04:29 2013 +0300 drm/i915: detect hang using per ring hangcheck_score "There's also another corner case on the kick. If the seqno = 2 (though not stuck), and on the 3rd hangcheck, the ring is stuck, and we try to kick it... we don't actually try to find out if the kick helped." v2: Make sure we catch DoS attempts with batches full of invalid WAITs. v3: Preserve the ability to detect loops by always charging the ring if it is busy on the same request. v4: Make sure we queue another check if on a new batch References: https://bugs.freedesktop.org/show_bug.cgi?id=65394 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
91738a95 |
|
05-Jun-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add ibx_irq_preinstall So we can remove some duplicate code. All the PCHs are very similar and right now the code is the same. I plan to add more code, so we would have more duplicated code. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
96a764d9 |
|
13-May-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: remove i915_hangcheck_hung Rework of per ring hangcheck made this obsolete. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
05407ff8 |
|
30-May-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: detect hang using per ring hangcheck_score Keep track of ring seqno progress and if there are no progress detected, declare hang. Use actual head (acthd) to distinguish between ring stuck and batchbuffer looping situation. Stuck ring will be kicked to trigger progress. This commit adds a hard limit for batchbuffer completion time. If batchbuffer completion time is more than 4.5 seconds, the gpu will be declared hung. Review comment from Ben which nicely clarifies the semantic change: "Maybe I'm just stating the functional changes of the patch, but in case they were unintended here is what I see as potential issues: 1. "If ring B is waiting on ring A via semaphore, and ring A is making progress, albeit slowly - the hangcheck will fire. The check will determine that A is moving, however ring B will appear hung because the ACTHD doesn't move. I honestly can't say if that's actually a realistic problem to hit it probably implies the timeout value is too low. 2. "There's also another corner case on the kick. If the seqno = 2 (though not stuck), and on the 3rd hangcheck, the ring is stuck, and we try to kick it... we don't actually try to find out if the kick helped" v2: use atchd to detect stuck ring from loop (Ben Widawsky) v3: Use acthd to check when ring needs kicking. Declare hang on third time in order to give time for kick_ring to take effect. v4: Update commit msg Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Paste in Ben's review comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
35c20a60 |
|
31-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Rename the gtt_list to global_list Since it will be used for the global bound/unbound list with full PPGTT, this helps clarify things for upcoming code rework. Recommended-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
12638c57 |
|
28-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Enable vebox interrupts Similar to a patch originally written by: v2: Reversed the meanings of masked and enabled (Haihao) Made non-destructive writes in case enable/disabler rps runs first (Haihao) v3: Reword error message (Damien) Modify postinstall to do the right thing based on previous fixup. (Ben) CC: Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cc609d5d |
|
28-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: consolidate interrupt naming scheme The motivation here is we're going to add some new interrupt definitions and handling outside of the GT interrupts which is all we've managed so far (with some RPS exceptions). By consolidating the names in the future we can make thing a bit cleaner as we don't need to define register names twice, and we can leverage pretty decent overlap in HW registers since ILK. To explain briefly what is in the comments: there are two sets of interrupt masking/enabling registers. At least so far, the definitions of the two sets overlap. The old code setup distinct names for interrupts in each set, ie. one for global, and one for ring. This made things confusing when using the wrong defines in the wrong places. rebase: Modified VLV bits v2: Renamed GT_RENDER_MASTER to GT_RENDER_CS_MASTER (Damien) Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4848405c |
|
28-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: make PM interrupt writes non-destructive PM interrupts have an expanded role on HSW. It helps route the EBOX interrupts. This patch is necessary to make the existing code which touches the mask, and enable registers more friendly to other code paths that also will need these registers. To be more explicit: At preinstall all interrupts are masked and disabled. This implies that preinstall should always happen before any enabling/disabling of RPS or other interrupts. The PMIMR is touched by the workqueue, so enable/disable touch IER and IIR. Similarly, the code currently expects IMR has no use outside of the RPS related interrupts so they unconditionally set 0, or ~0. We could use IER in the workqueue, and IMR elsewhere, but since the workqueue use-case is more transient the existing usage makes sense. Disable RPS events: IER := IER & ~GEN6_PM_RPS_EVENTS // Disable RPS related interrupts IIR := GEN6_PM_RPS_EVENTS // Disable any outstanding interrupts Enable RPS events: IER := IER | GEN6_PM_RPS_EVENTS // Enable the RPS related interrupts IIR := GEN6_PM_RPS_EVENTS // Make sure there were no leftover events (really shouldn't happen) v2: Shouldn't destroy PMIIR or PMIMR VEBOX interrupt state in enable/disable rps functions (Haihao) v3: Bug found by Chris where we were clearing the wrong bits at rps disable. expanded commit message v4: v3 was based off the wrong branch v5: Added the setting of PMIMR because of previous patch update CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
eda63ffb |
|
28-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Add PM regs to pre/post install At the moment, these values are wiped out anyway by the rps enable/disable. That will be changed in the next patch though. v2: Add post install setup to address issue found by Damien in the next patch. replaced WARN_ON(dev_priv->rps.pm_iir != 0); with rps.pm_iir = 0; With the v2 of this patch and the deferred pm enabling (which changed since the original patches) we're now able to get PM interrupts before we've brought up enabled rps. At this point in boot, we don't want to do anything about it, so we simply ignore it. Since writing the original assertion, the code has changed quite a bit, and I believe removing this assertion is perfectly safe. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: I don't agree with the justification to drop the WARN and added a FIXME to that effect.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7d99163d |
|
28-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Create an ivybridge_irq_preinstall Just duplicates ironlake_irq_preinstall for now. v2: Add new PCH_NOP check (Damien) Add SDEIMR comment (Damien) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Update now outdated comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
baf02a1f |
|
28-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Create a more generic pm handler for hsw+ HSW has some special requirements for the VEBOX. Splitting out the interrupt handler will make the code a bit nicer and less error prone when we begin to handle those. The slight functional change in this patch (queueing work while holding the spinlock) is intentional as it makes a subsequent patch a bit nicer. The change should also only effect HSW platforms. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
692a04cf |
|
29-May-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix pch_nop support This was accidentally broken in the south error interrupt handling work: commit 8664281b64c457705db72fc60143d03827e75ca9 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Apr 12 17:57:57 2013 -0300 drm/i915: report Gen5+ CPU and PCH FIFO underruns Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a01025af |
|
21-May-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fixup i915_pipe_enabled check in i915_irq.c Well, as well as we can without completely revamping the drm vblank code. The issue are that - The vblank code needs to work on both ums and kms. - It deals always deals with pipes. - It doesn't take any of the kms locks. The last part is not really fixable without revamping the drm vblank code, since the drm core <-> driver interactions is a veritable pile of spaghettis. But the other pieces can be fixed by switching on the MODESET driver flag and either checking the hw state directly (ums case) or just querying our sw tracking (with broken locking, but that's not worse than what we've had). Note that this essentially reverts commit 702e7a56af3780d8b3a717f698209bef44187bb0 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Tue Oct 23 18:29:59 2012 -0200 drm/i915: convert PIPECONF to use transcoder instead of pipe for the ums case, which will fix a NULL deref (since we really don't have any crtcs set up). But the real reason to do this is to drop our reliance on the cpu_transcoder: By only checking intel_crtc->active we don't need to make sure that the pipe_config (or at least the cpu_transcoder) contain safe values even when the pipe is off. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7ed73da0 |
|
25-May-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Fix error state memory leaks Found with kmemleak. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ed5cbb03 |
|
13-May-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: introduce i915_hangcheck_ring_hung In preparation to track per ring progress in hangcheck, add i915_hangcheck_ring_hung. v2: omit dev parameter (Ben Widawsky) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
92cab734 |
|
24-May-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: track ring progression using seqnos Instead of relying in acthd, track ring seqno progression to detect if ring has hung. v2: put hangcheck stuff inside struct (Chris Wilson) v3: initialize hangcheck.seqno (Ben Widawsky) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
79ee20dc |
|
13-May-2013 |
Mika Kuoppala <mika.kuoppala@linux.intel.com> |
drm/i915: pass seqno to i915_hangcheck_ring_idle In preparation for next commit, pass seqno as a parameter to i915_hangcheck_ring_idle as it will be used inside i915_hangcheck_elapsed. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bc5ead8c |
|
07-May-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: fix hotplug event bit tracking commit 142e239849c800f9dc23f828762873073f612d3f Author: Egbert Eich <eich@suse.de> Date: Thu Apr 11 15:57:57 2013 +0200 drm/i915: Add bit field to record which pins have received HPD events (v3) added a bit field for hotplug event tracking. There ended up being three different v3 of the patch: [1], [2], and [3]. Apparently [1] was the correct one, but some frankenstein combination of the three got committed, which reversed the logic for setting the hotplug bits and misplaced a continue statement, skipping the hotplug irq storm handling altogether. This lead to broken hotplug detection, bisected to commit 321a1b3026ea194dd084cf3bda1e235b2986b0af Author: Egbert Eich <eich@suse.de> Date: Thu Apr 11 16:00:26 2013 +0200 drm/i915: Only reprobe display on encoder which has received an HPD event (v2) which uses the incorrectly set hotplug event bits. Fix the mess. [1] http://mid.gmane.org/1366112220-7638-6-git-send-email-eich@suse.de [2] http://mid.gmane.org/1365688677-13682-1-git-send-email-eich@suse.de [3] http://mid.gmane.org/1365688996-13874-1-git-send-email-eich@suse.de Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
71f8ba6b |
|
02-May-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: check the power well on i915_pipe_enabled This fixes "unclaimed register" messages when the power well is disabled and there's a GPU hang. v2: Use the new intel_display_power_enabled(). v3: Use the new domains for intel_display_power_enabled(). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f49e38dd |
|
29-Apr-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: cleanup opregion asle pipestat enable Both intel_opregion_enable_asle() and intel_enable_asle() have shrunk considerably. Merge them together into a static function in i915_irq.c, and rename to better reflect the purpose and the related platforms. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f898780b |
|
29-Apr-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: cleanup redundant checks from intel_enable_asle Realize that intel_enable_asle() is never called on PCH-split platforms or on VLV. Rip out the GSE irq enable for PCH-split platforms, which also happens to be incorrect for IVB+. This should not cause any functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2ce12e3d |
|
01-Mar-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: remove VLV MSI IRQ hack Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
81a07809 |
|
24-Apr-2013 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: drop code duplication in favor of asle interrupt handler With the previous work asle and gse interrupt handlers should now be functionally the same. Drop the duplicated code. v2: Drop intel_opregion_gse_intr() also in the !CONFIG_ACPI path. (Damien) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
52ceb908 |
|
23-Apr-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: make sure GPU freq drops to minimum after entering RC6 v4 On VLV, the Punit doesn't automatically drop the GPU to it's minimum voltage level when entering RC6, so we arm a timer to do it for us from the RPS interrupt handler. It'll generally only fire when we go idle (or if for some reason there's a long delay between RPS interrupts), but won't be re-armed again until the next RPS event, so shouldn't affect power consumption after we go idle and it triggers. v2: use delayed work instead of timer + work queue combo (Ville) v3: fix up delayed work cancel (must be outside lock) (Daniel) fix up delayed work handling func for delayed work (Jesse) v4: cancel delayed work before RPS shutdown (Jani) pass delay not absolute time to mod_delayed_work (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
321a1b30 |
|
11-Apr-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Only reprobe display on encoder which has received an HPD event (v2) Instead of calling into the DRM helper layer to poll all connectors for changes in connected displays probe only those connectors which have received a hotplug event. v2: Resolved conflicts with changes in previous commits. Renamed function and and added a WARN_ON() to warn of intel_hpd_irq_event() from being called without mode_config.mutex held - suggested by Jani Nikula. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
142e2398 |
|
11-Apr-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Add bit field to record which pins have received HPD events (v3) This way it is possible to limit 're'-detect() of displays to connectors which have received an HPD event. v2: Reordered drm_i915_private: Move hpd_event_bits to hpd state tracking. v3: Fixed merge conflicts with previous patches. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
de032bf4 |
|
12-Apr-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: print Gen5+ CPU/PCH poison interrupts This is bad news and shouldn't be happening. V2: Rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8664281b |
|
12-Apr-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: report Gen5+ CPU and PCH FIFO underruns In this commit we enable both CPU and PCH FIFO underrun reporting and start reporting them. We follow a few rules: - after we receive one of these errors, we mask the interrupt, so we won't get an "interrupt storm" and we also won't flood dmesg; - at each mode set we enable the interrupts again, so we'll see each message at most once per mode set; - in the specific places where we need to ignore the errors, we completely mask the interrupts. The downside of this patch is that since we're completely disabling (masking) the interrupts instead of just not printing error messages, we will mask more than just what we want on IVB/HSW CPU interrupts (due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll also be masking PCH FIFO underruns for pipe B, because both are reported by SERR_INT, which has to be either completely enabled or completely disabled (in othe words, there's no way to disable/enable specific bits of GEN7_ERR_INT and SERR_INT). V2: Rename some functions and variables, downgrade messages to DRM_DEBUG_DRIVER and rebase. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0a073b84 |
|
17-Apr-2013 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: turbo & RC6 support for VLV v7 Uses slightly different interfaces than other platforms. v2: track actual set freq, not requested (Rohit) fix debug prints in init code (Jesse) v3: don't write sleep reg (Jesse) re-add RC6 wake limit write (Ben) fixup thresholds to match other platforms (Ben) clean up mem freq calculation (Ben) clean up debug prints (Ben) v4: move defines from punit patch (Ville) v5: remove writes to nonexistent regs (Jesse) put RP and RC regs together (Jesse) fix RC6 enable (Jesse) v6: use correct fuse reads from NC (Jesse) split out min/max funcs for use in sysfs (Jesse) add debugfs & sysfs freq controls (Jesse) v7: update with Ben's hw_max changes (Jesse) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6) [danvet: Follow checkpatch sugggestion to use min_t to avoid casting fun.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cfc33bf7 |
|
17-Apr-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use port_name() in PCH port audio power change message Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ac4c16c5 |
|
16-Apr-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4) We disable hoptplug detection when we encounter a hotplug event storm. Still hotplug detection is required on some outputs (like Display Port). The interrupt storm may be only temporary (on certain Dell Laptops for instance it happens at certain charging states of the system). Thus we enable it after a certain grace period (2 minutes). Should the interrupt storm persist it will be detected immediately and it will be disabled again. v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker. v3: Clarified loop start value, Removed superfluous test for Ivybridge and Haswell, Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä) v4: Fixed two bugs pointed out by Jani Nikula. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cd569aed |
|
16-Apr-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3) This patch disables hotplug interrupts if an 'interrupt storm' has been detected. Noise on the interrupt line renders the hotplug interrupt useless: each hotplug event causes the devices to be rescanned which will will only increase the system load. Thus disable the hotplug interrupts and fall back to periodic device polling. v2: Fixed cleanup typo. v3: Fixed format issues, clarified a variable name, changed pr_warn() to DRM_INFO() as suggested by Jani Nikula <jani.nikula@linux.intel.com>. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
995e6b3d |
|
16-Apr-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Mask out the HPD irq bits before setting them individually. To disable previously enabled HPD IRQs we need to reset them and set the enabled ones individually. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
821450c6 |
|
16-Apr-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: (re)init HPD interrupt storm statistics When an encoder is shared on several connectors there is only one hotplug line, thus this line needs to be shared among these connectors. If HPD detect only works reliably on a subset of those connectors, we want to poll the others. Thus we need to make sure that storm detection doesn't mess up the settings for those connectors. Therefore we store the settings in the intel_connector struct and restore them from there. If nothing is set but the encoder has a hpd_pin set we assume this connector is hotplug capable. On init/reset we make sure the polled state of the connectors is (re)set to the default value, the HPD interrupts are marked enabled. Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b543fb04 |
|
16-Apr-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Add HPD IRQ storm detection (v5) Add a hotplug IRQ storm detection (triggered when a hotplug interrupt fires more than 5 times / sec). Rationale: Despite of the many attempts to fix the problem with noisy hotplug interrupt lines we are still seeing systems which have issues: Once cause of noise seems to be bad routing of the hotplug line on the board: cross talk from other signals seems to cause erronous hotplug interrupts. This has been documented as an erratum for the the i945GM chipset and thus hotplug support was disabled for this chipset model but others seem to have this problem, too. We have seen this issue on a G35 motherboard for example: Even different motherboards of the same model seem to behave differently: while some only see only around 10-100 interrupts/s others seem to see 5k or more. We've also observed a dependency on the selected video mode. Also on certain laptops interrupt noise seems to occur duing battery charging when the battery is at a certain charge levels. Thus we add a simple algorithm here that detects an 'interrupt storm' condition. v2: Fixed comment. v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff. v4: Followed by Jesse Barnes to use a time_..() macro. v5: Fixed coding style as suggested by Jani Nikula. Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
42b5aeab |
|
09-Apr-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: IVB/HSW have 32 fence register Increase the number of fence registers to 32 on IVB/HSW. VLV however only has 16 fence registers according to the docs. Increasing the number of fences was attempted before [1], but there was some uncertainty about the maximum CPU fence number for FBC. Since then BSpec has been updated to state that there are in fact 32 fence registers, and the CPU fence number field in the SNB_DPFC_CTL_SA register is 5 bits, and the CPU fence number field in the ILK_DPFC_CONTROL register must be zero. So now it all makes sense. [1] http://lists.freedesktop.org/archives/intel-gfx/2011-October/012865.html v2: Include some background information based on the previous attempt Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ab5c608b |
|
05-Apr-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Don't touch South Display when PCH_NOP Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will be bad for CPU" range when we have PCH_NOP. There is a bit of a hack in init clock gating. We want to do most of the clock gating, but the part we skip will hang the system. It could probably be abstracted a bit better, but I don't feel it's too unsightly. v2: Use inverse HAS_PCH_NOP check (Jani) v3: Actually do what I claimed in v2 (spotted by Daniel) Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel) Move LVDS bail into this patch (Ben) v4: logical rebase conflict resolution with SDEIIR (Ben) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Brush up patch a bit and resolve conflicts: - Adjust PCH_NOP checks due to Egbert's hpd handling rework. - Addd a PCH_NOP check in the irq uninstall code. - Resolve conflicts with Paulo's SDE irq handling race fix. v5: Drop the added hunks in the ilk irq handler again, they're bogus. OOps. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0ff9800a |
|
22-Feb-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: remove "inline" keyword from ironlake_disable_display_irq - It's a static function - I just added a few more users to it - Its sister ironlake_enable_display_irq is not marked as inline - The compiler will still inline if it thinks it should do Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
73c352a2 |
|
26-Mar-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: wire up SDVO hpd support on cpt/ppt Now with Egbert Eich's hpd infrastructure rework merged this is dead simple. And we need this to make output detection work on SDVO - with the cleaned-up drm polling helpers outputs which claim to have hpd support are no longer polled. Now SDVO claims to do that, but it's not actually wired up. So just do it. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
85fc95ba |
|
27-Mar-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: clear crt hotplug compare voltage field before setting Noticed while reviewing the hotplug irq setup code. Just looks better. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bac56d5b |
|
24-Feb-2013 |
Egbert Eich <eich@suse.de> |
DRM/i915: Remove i965_hpd_irq_setup. After "Convert HPD interrupts to make use of HPD pin assignment in encoders." This function is now basically the same as i915_hpd_irq_setup(). Consolidating both functions in one requires one more check for I915_HAS_HOTPLUG(dev) in the i965 code path and one more check for IS_G4X(dev) in the i915 code path. These are considered harmless. Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup patch conflict and make it compile.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
82a28bcf |
|
27-Mar-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: implement ibx_hpd_irq_setup This fixes a regression introduced in commit e5868a318d1ae28f760f77bb91ce5deb751733fd Author: Egbert Eich <eich@suse.de> Date: Thu Feb 28 04:17:12 2013 -0500 DRM/i915: Convert HPD interrupts to make use of HPD pin assignment in encode Due to the irq setup rework in 3.9, see commit 20afbda209d708be66944907966486d0c1331cb8 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Dec 11 14:05:07 2012 +0100 drm/i915: Fixup hpd irq register setup ordering Egbert Eich's hpd rework blows up on pch-split platforms - it walks the encoder list before that has been set up completely. The new init sequence is: 1. irq enabling 2. modeset init 3. hpd setup We need to move around the ibx setup a bit to fix this. Ville Syrjälä pointed out in his review that we can't touch SDEIER after the interrupt handler is set up, since that'll race with Paulo Zanoni's PCH interrupt race fix: commit 44498aea293b37af1d463acd9658cdce1ecdf427 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 22 17:05:28 2013 -0300 drm/i915: also disable south interrupts when handling them We fix that by unconditionally enabling all interrupts in SDEIER, but masking them as-needed in SDEIMR. Since only the single-threaded setup/teardown (or suspend/resume) code touches that, no further locking is required. While at it also simplify the mask handling - we start out with all interrupts cleared in the postinstall hook, and never enable a hpd interrupt before hpd_irq_setup is called. And finally, for consistency rename the ibx hpd setup function to ibx_hpd_irq_setup. v2: Fix race around SDEIER writes (Ville). v3: Remove the superflous posting read for SDEIER, spotted by Ville. Ville also wondered whether we shouldn't clear SDEIIR, since now SDE interrupts are enabled before we have an irq handler installed. But the master interrupt control bit in DEIER is still cleared, so we should be fine. Cc: Egbert Eich <eich@suse.de> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62798 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e5868a31 |
|
28-Feb-2013 |
Egbert Eich <eich@suse.de> |
DRM/i915: Convert HPD interrupts to make use of HPD pin assignment in encoders (v2) This allows to enable HPD interrupts for individual pins to only receive hotplug events from lines which are connected and working. v2: Restructured initailization of const arrays following a suggstion by Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fa00abe0 |
|
24-Feb-2013 |
Egbert Eich <eich@suse.de> |
DRM/i915: Remove valleyview_hpd_irq_setup. It's basically identical to i915_hpd_irq_setup(). Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4f3308b9 |
|
22-Mar-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: there's no PIPESTAT on HAS_PCH_SPLIT platforms So don't read it when capturing the error state. This solves "unclaimed register" messages on Haswell when we have a GPU hang. V2: Check for HAS_PCH_SPLIT instead of Gen5+ because VLV still has this register. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7eb552ae |
|
13-Mar-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Move num_pipes to intel info Requested by Daniel. v2: Fix incorrect num_pipe settings. (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a24a11e6 |
|
14-Mar-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Resurrect ring kicking for semaphores, selectively Once we thought we got semaphores working, we disabled kicking the ring if hangcheck fired whilst waiting upon a ring as it was doing more harm than good: commit 4e0e90dcb8a7df1229c69e30abebb59b0b3c2a1f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Dec 14 13:56:58 2011 +0100 drm/i915: kicking rings stuck on semaphores considered harmful However, life is never that easy and semaphores are still causing problems whereby the value written by one ring (bcs) is not being propagated to the waiter (rcs). Thus the waiter never wakes up and we declare the GPU hung, which often has unfortunate consequences, even if we successfully reset the GPU. But the GPU is idle as it has completed the work, just didn't notify its clients. So we can detect the incomplete wait during hang check and probe the target ring to see if has indeed emitted the breadcrumb seqno following the work and then and only then kick the waiter. Based on a suggestion by Ben Widawsky. v2: cross-check wait with iphdr. fix signaller calculation. References: https://bugs.freedesktop.org/show_bug.cgi?id=54226 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Widawsky <ben@bwidawsk.net> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5d83d294 |
|
06-Mar-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add missing space in error message To avoid this: [ 256.798060] [drm] capturing error event; look for more information in/sys/kernel/debug/dri/0/i915_error_state Ben Widawsky identified that this regression has been introduced in commit 2f86f1916504525a6fdd6b412374b4ebf1102cbe Author: Ben Widawsky <ben@bwidawsk.net> Date: Mon Jan 28 15:32:15 2013 -0800 drm/i915: Error state should print /sys/kernel/debug ... [danvet: split up long line.] <----- he did it Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Pimp commit message with the regression note. Also, order more brown paper bags, I've run out.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
44498aea |
|
22-Feb-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: also disable south interrupts when handling them From the docs: "IIR can queue up to two interrupt events. When the IIR is cleared, it will set itself again after one clock if a second event was stored." "Only the rising edge of the PCH Display interrupt will cause the North Display IIR (DEIIR) PCH Display Interrupt even bit to be set, so all PCH Display Interrupts, including back to back interrupts, must be cleared before a new PCH Display interrupt can cause DEIIR to be set". The current code works fine because we don't get many interrupts, but if we enable the PCH FIFO underrun interrupts we'll start getting so many interrupts that at some point new PCH interrupts won't cause DEIIR to be set. The initial implementation I tried was to turn the code that checks SDEIIR into a loop, but we can still get interrupts even after the loop is done (and before the irq handler finishes), so we have to either disable the interrupts or mask them. In the end I concluded that just disabling the PCH interrupts is enough, you don't even need the loop, so this is what this patch implements. I've tested it and it passes the 2 "PCH FIFO underrun interrupt storms" I can reproduce: the "ironlake_crtc_disable" case and the "wrong watermarks" case. In other words, here's how to reproduce the problem fixed by this patch: 1 - Enable PCH FIFO underrun interrupts (SERR_INT on SNB+) 2 - Boot the machine 3 - While booting we'll get tons of PCH FIFO underrun interrupts 4 - Plug a new monitor 5 - Run xrandr, notice it won't detect the new monitor 6 - Read SDEIIR and notice it's not 0 while DEIIR is 0 Q: Can't we just clear DEIIR before SDEIIR? A: It doesn't work. SDEIIR has to be completely cleared (including the interrupts stored on its back queue) before it can flip DEIIR's bit to 1 again, and even while you're clearing it you'll be getting more and more interrupts. Q: Why does it work by just disabling+enabling the south interrupts? A: Because when we re-enable them, if there's something on the SDEIIR register (maybe an interrupt stored on the queue), the re-enabling will make DEIIR's bit flip to 1, and since we'll already have interrupts enabled we'll get another interrupt, then run our irq handler again to process the "back" interrupts. v2: Even bigger commit message, added code comments. Note that this fixes missed dp aux irqs which have been reported for 3.9-rc1. This regression has been introduced by switching to irq-driven dp aux transactions with commit 9ee32fea5fe810ec06af3a15e4c65478de56d4f5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 1 13:53:48 2012 +0100 drm/i915: irq-drive the dp aux communication References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18588.html References: https://lkml.org/lkml/2013/2/26/769 Tested-by: Imre Deak <imre.deak@intel.com> Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Pimp commit message with references for the dp aux irq timeout regression this fixes.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8c123e54 |
|
04-Mar-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Capture current context on error On error, this represents the state of the currently running context at the time it was loaded. Unfortunately, since we're hung and can't switch out the context this may not tell us too much about the most current state of the context, but does give clues about what has happened since loading. Thanks to recent doc updates, we have a little more confidence regarding what is actually in this memory, and perhaps it will help us gain more insight into certain bugs. AFAICT, the most interesting info is in the first page. To save space, we only capture the first page. In the future, we might want to dump more. Sample of the relevant part of error state: render ring --- HW Context = 0x01b20000 [0000] 00000000 1100105f 00002028 ffff0880 [0010] 0000209c feff4040 000020c0 efdf0080 [0020] 00002178 00000001 0000217c 00145855 [0030] 00002310 00000000 00002314 00000000 v2: Move error collection to the ring error code Change format of dump to not confuse intel_error_decode (Chris) Put the context error object with the others (Chris) Don't search bound_list instead of active_list (chris) v3: extract and flatten context recording (daniel) checkpatch related fixes for the copypasta in debugfs v4: bug in v3 (Daniel) - if ((ring->id == RCS) && error->ccid) + if ((ring->id != RCS) || !error->ccid) References: https://bugs.freedesktop.org/show_bug.cgi?id=55845 Reviewed-by (v2): Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Bikeshed away the redudant parenthese around ring->id != RCS] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
211816ec |
|
24-Feb-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: exclude CCID for platforms without it Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d0d045e8 |
|
24-Feb-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Created a sized object error dump v2: Actually use num_pages (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
46c06a30 |
|
20-Feb-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Kill pipestat[] cache Caching the PIPESTAT enable bits has been deemed pointless. Just read them from the register itself. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
90a72f87 |
|
19-Feb-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Refactor gen2 to gen4 vblank interrupt handling The indentation is getting way too deep. Pull the vblank interupt handling out to separate functions. v2: Keep flip_mask handling in the main irq handler and flatten {i8xx,i915}_handle_vblank() even further. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
21ad8330 |
|
19-Feb-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix races in gen4 page flip interrupt handling Use the gen3 logic for handling page flip interrupts on gen4. Unfortuantely this kills the stall_check since that looks like it can easily trigger too early. With the current logic the stall check would kick in on the first vblank after the flip has been submitted to the ring. If the CS takes longer than that to process the commands in the ring, the stall check will cause the page flip to be complete too early. That doesn't sound like a very good idea. Something better should be deviced if we still need the stall check. For now, mark i915_pageflip_stall_check() as unused. v2: Fix irq enable_mask and add __always_unused (Chris Wilson) References: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1116587 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5e2032d4 |
|
19-Feb-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Eliminate race from gen2/3 page flip interrupt handling If the interrupt handler were to process a previous vblank interrupt and the following flip pending interrupt at the same time, the page flip would be completed too soon. To eliminate this race, check the live pending flip status from the ISR register before finishing the page flip. v2: Added a comment explaining the logic (by Chris Wilson) v3: Fix a typo in the comment Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
96a02917 |
|
18-Feb-2013 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Finish page flips and update primary planes after a GPU reset GPU reset will drop all flips that are still in the ring. So after the reset, call update_plane() for all CRTCs to make sure the primary planes are scanning out from the correct buffer. Also finish all pending flips. That means user space will get its page flip events and won't get stuck waiting for them. v2: Explicitly finish page flips instead of relying on FLIP_DONE interrupt being generated by the base address update. v3: Make two loops over crtcs to avoid deadlocks with the crtc mutex Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup long line complaint from checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d46da437 |
|
08-Feb-2013 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: add ibx_irq_postinstall So we can remove duplicated code. Note that this function is used not only on IBX, but also CPT and LPT. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Also bikeshed s/ironlake_enable_pch_hotplug/ibx_enable_hotplug to keep consistent with our ibx for pch naming scheme.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
26739f12 |
|
06-Feb-2013 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: unify HDMI/DP hpd definitions They're physically the same pins and also the same bits, duplicating only confuses the reader. This also makes it a bit obvious that we have quite some code duplication going on here. Squashing that is for a larger rework in our hpd handling though. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2f86f191 |
|
28-Jan-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Error state should print /sys/kernel/debug /sys/kernel/debug has more or less been the standard location of debugfs for several years now. Other parts of DRM already use this location, so we should as well. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Carl Worth <cworth@cworth.org> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: split up long line.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7db0ba24 |
|
06-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: clarify concurrent hang detect/gpu reset consistency Damien Lespiau wondered how race the gpu reset/hang detection code is against concurrent gpu resets/hang detections or combinations thereof. Luckily the single work item is guranteed to never run concurrently, so reset handling is already single-threaded. Hence we only have to worry about concurrent hang detections, or a hang detection firing off while we're still processing an older gpu reset request. Due to the new mechanism of setting the reset in progress flag and the ordering guaranteed by the schedule_work function there's nothing to do but add a comment explaining why we're safe. The only thing I've noticed is that we still try to reset the gpu now, even when it is declared terminally wedged. Add a check for that to avoid continous warnings about failed resets, in case the hangcheck timer ever gets stuck. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
f69061be |
|
06-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: create a race-free reset detection With the previous patch the state transition handling of the reset code itself is now (hopefully) race free and solid. But that still leaves out everyone else - with the various lock-free wait paths we have there's the possibility that the reset happens between the point where we read the seqno we should wait on and the actual wait. And if __wait_seqno then never sees the RESET_IN_PROGRESS state, we'll happily wait for a seqno which will in all likelyhood never signal. In practice this is not a big problem since the X server gets constantly interrupted, and can then submit more work (hopefully) to unblock everyone else: As soon as a new seqno write lands, all waiters will unblock. But running the i-g-t reset testcase ZZ_hangman can expose this race, especially on slower hw with fewer cpu cores. Now looking forward to ARB_robustness and friends that's not the best possible behaviour, hence this patch adds a reset_counter to be able to detect any reset, even if a given thread never observed the in-progress state. The important part is to correctly order things: - The write side needs to increment the counter after any seqno gets reset. Hence we need to do that at the end of the reset work, and again wake everyone up. We also need to place a barrier in between any possible seqno changes and the counter increment, since any unlock operations only guarantee that nothing leaks out, but not that at later load operation gets moved ahead. - On the read side we need to ensure that no reset can sneak in and invalidate the seqno. In all cases we can use the one-sided barrier that unlock operations guarantee (of the lock protecting the respective seqno/ring pair) to ensure correct ordering. Hence it is sufficient to place the atomic read before the mutex/spin_unlock and no additional barriers are required. The end-result of all this is that we need to wake up everyone twice in a reset operation: - First, before the reset starts, to get any lockholders of the locks, so that the reset can proceed. - Second, after the reset is completed, to allow waiters to properly and reliably detect the reset condition and bail out. I admit that this entire reset_counter thing smells a bit like overkill, but I think it's justified since it makes it really explicit what the bail-out condition is. And we need a reset counter anyway to implement ARB_robustness, and imo with finer-grained locking on the horizont this is the most resilient scheme I could think of. v2: Drop spurious change in the wait_for_error EXIT_COND - we only need to wait until we leave the reset-in-progress wedged state. v3: Don't play tricks with barriers in the throttle ioctl, the spin_unlock is barrier enough. I've also considered using a little helper to grab the current reset_counter, but then decided that hiding the atomic_read isn't a great idea, since having it explicitly show up in the code is a nice remainder to reviews to check the memory barriers. v4: Add a comment to explain why we need to fall through in __wait_seqno in the end variable assignments. v5: Review from Damien: - s/smb/smp/ in a comment - don't increment the reset counter after we've set it to WEDGED. Now we (again) properly wedge the gpu when the reset fails. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1f83fee0 |
|
15-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: clear up wedged transitions We have two important transitions of the wedged state in the current code: - 0 -> 1: This means a hang has been detected, and signals to everyone that they please get of any locks, so that the reset work item can do its job. - 1 -> 0: The reset handler has completed. Now the last transition mixes up two states: "Reset completed and successful" and "Reset failed". To distinguish these two we do some tricks with the reset completion, but I simply could not convince myself that this doesn't race under odd circumstances. Hence split this up, and add a new terminal state indicating that the hw is gone for good. Also add explicit #defines for both states, update comments. v2: Split out the reset handling bugfix for the throttle ioctl. v3: s/tmp/wedged/ sugested by Chris Wilson. Also fixup up a rebase error which prevented this patch from actually compiling. v4: To unify the wedged state with the reset counter, keep the reset-in-progress state just as a flag. The terminally-wedged state is now denoted with a big number. v5: Add a comment to the reset_counter special values explaining that WEDGED & RESET_IN_PROGRESS needs to be true for the code to be correct. v6: Fixup logic errors introduced with the wedged+reset_counter unification. Since WEDGED implies reset-in-progress (in a way we're terminally stuck in the dead-but-reset-not-completed state), we need ensure that we check for this everywhere. The specific bug was in wait_for_error, which would simply have timed out. v7: Extract an inline i915_reset_in_progress helper to make the code more readable. Also annote the reset-in-progress case with an unlikely, to help the compiler optimize the fastpath. Do the same for the terminally wedged case with i915_terminally_wedged. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
33196ded |
|
14-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move wedged to the other gpu error handling stuff And to make Ben Widawsky happier, use the gpu_error instead of the entire device as the argument in some functions. Drop the outdated comment on ->wedged for now, a follow-up patch will change the semantics and add a proper comment again. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
99584db3 |
|
14-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: extract hangcheck/reset/error_state state into substruct This has been sprinkled all over the place in dev_priv. I think it'd be good to also move all the code into a separate file like i915_gem_error.c, but that's for another patch. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
5d4545ae |
|
17-Jan-2013 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Create a gtt structure The purpose of the gtt structure is to help isolate our gtt specific properties from the rest of the code (in doing so it help us finish the isolation from the AGP connection). The following members are pulled out (and renamed): gtt_start gtt_total gtt_mappable_end gtt_mappable gtt_base_addr gsm The gtt structure will serve as a nice place to put gen specific gtt routines in upcoming patches. As far as what else I feel belongs in this structure: it is meant to encapsulate the GTT's physical properties. This is why I've not added fields which track various drm_mm properties, or things like gtt_mtrr (which is itself a pretty transient field). Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [Ben modified commit messages] Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
af5163ac |
|
10-Jan-2013 |
Egbert Eich <eich@suse.de> |
drm/i915: Remove pch_rq_mask from struct drm_i915_private. This variable is only used locally in the irq postinstall functions for ivybridge and ironlake. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0f3b6849 |
|
14-Jan-2013 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record DERRMR, FORCEWAKE and RING_CTL in error-state These are useful for investigating hangs involving WAIT_FOR_EVENT. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Apply a droplet of Future-Proof in the if-ladder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7dbf9d6e |
|
18-Dec-2012 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: BUG() if fences are used on unsupported platform Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b45305fc |
|
17-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Implement workaround for broken CS tlb on i830/845 Now that Chris Wilson demonstrated that the key for stability on early gen 2 is to simple _never_ exchange the physical backing storage of batch buffers I've tried a stab at a kernel solution. Doesn't look too nefarious imho, now that I don't try to be too clever for my own good any more. v2: After discussing the various techniques, we've decided to always blit batches on the suspect devices, but allow userspace to opt out of the kernel workaround assume full responsibility for providing coherent batches. The principal reason is that avoiding the blit does improve performance in a few key microbenchmarks and also in cairo-trace replays. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: - Drop the hunk which uses HAS_BROKEN_CS_TLB to implement the ring wrap w/a. Suggested by Chris Wilson. - Also add the ACTHD check from Chris Wilson for the error state dumping, so that we still catch batches when userspace opts out of the w/a.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
20afbda2 |
|
11-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Fixup hpd irq register setup ordering For GMCH platforms we set up the hpd irq registers in the irq postinstall hook. But since we only enable the irq sources we actually need in PORT_HOTPLUG_EN/STATUS, taking dev_priv->hotplug_supported_mask into account, no hpd interrupt sources is enabled since commit 52d7ecedac3f96fb562cb482c139015372728638 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Dec 1 21:03:22 2012 +0100 drm/i915: reorder setup sequence to have irqs for output setup Wrongly set-up interrupts also lead to broken hw-based load-detection on at least GM45, resulting in ghost VGA/TV-out outputs. To fix this, delay the hotplug register setup until after all outputs are set up, by moving it into a new dev_priv->display.hpd_irq_callback. We might also move the PCH_SPLIT platforms to such a setup eventually. Another funny part is that we need to delay the fbdev initial config probing until after the hpd regs are setup, for otherwise it'll detect ghost outputs. But we can only enable the hpd interrupt handling itself (and the output polling) _after_ that initial scan, due to massive locking brain-damage in the fbdev setup code. Add a big comment to explain this cute little dragon lair. v2: Encapsulate all the fbdev handling by wrapping the move call into intel_fbdev_initial_config in intel_fb.c. Requested by Chris Wilson. v3: Applied bikeshed from Jesse Barnes. v4: Imre Deak noticed that we also need to call intel_hpd_init after the drm_irqinstall calls in the gpu reset and resume paths - otherwise hotplug will be broken. Also improve the comment a bit about why hpd_init needs to be called before we set up the initial fbdev config. Bugzilla: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54943 Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
97a19a24 |
|
08-Dec-2012 |
Tomas Janousek <tomi@nomi.cz> |
drm/i915: don't prevent CPU idle states Commit 9ee32fea5f unconditionally prevents the CPU from entering idle states until intel_dp_aux_ch completes for the first time, which never happens on my DisplayPort-less intel gfx, causing the CPU to get rather hot. Signed-off-by: Tomas Janousek <tomi@nomi.cz> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e7d841ca |
|
03-Dec-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Close race between processing unpin task and queueing the flip Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required references or even pinning it... Havoc. To close the race, we use the flip-pending atomic to indicate when the flip is finally setup and enqueued. So during the flip-done processing, we can check more accurately whether the flip was expected. v2: Add the appropriate mb() to ensure that the writes to the page-flip worker are complete prior to marking it active and emitting the MI_FLIP. On the read side, the mb should be enforced by the spinlocks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: Review the barriers a bit, we need a write barrier both before and after updating ->pending. Similarly we need a read barrier in the interrupt handler both before and after reading ->pending. With well-ordered irqs only one barrier in each place should be required, but since this patch explicitly sets out to combat spurious interrupts with is staged activation of the unpin work we need to go full-bore on the barriers, too. Discussed with Chris Wilson on irc and changes acked by him.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
36dacf5b |
|
06-Dec-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: be less verbose when handling gmbus/aux irqs Having 9500 lines repeated on dmesg does not help me at all. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9ee32fea |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: irq-drive the dp aux communication At least on the platforms that have a dp aux irq and also have it enabled - vlvhsw should have one, too. But I don't have a machine to test this on. Judging from docs there's no dp aux interrupt for gm45. Also, I only have an ivb cpu edp machine, so the dp aux A code for snb/ilk is untested. For dpcd probing when nothing is connected it slashes about 5ms of cpu time (cpu time is now negligible), which agrees with 3 * 5 400 usec timeouts. A previous version of this patch increases the time required to go through the dp_detect cycle (which includes reading the edid) from around 33 ms to around 40 ms. Experiments indicated that this is purely due to the irq latency - the hw doesn't allow us to queue up dp aux transactions and hence irq latency directly affects throughput. gmbus is much better, there we have a 8 byte buffer, and we get the irq once another 4 bytes can be queued up. But by using the pm_qos interface to request the lowest possible cpu wake-up latency this slowdown completely disappeared. Since all our output detection logic is single-threaded with the mode_config mutex right now anyway, I've decide not ot play fancy and to just reuse the gmbus wait queue. But this would definitely prep the way to run dp detection on different ports in parallel v2: Add a timeout for dp aux transfers when using interrupts - the hw _does_ prevent this with the hw-based 400 usec timeout, but if the irq somehow doesn't arrive we're screwed. Lesson learned while developing this ;-) v3: While at it also convert the busy-loop to wait_for_atomic, so that we don't run the risk of an infinite loop any more. v4: Ensure we have the smallest possible irq latency by using the pm_qos interface. v5: Add a comment to the code to explain why we frob pm_qos. Suggested by Chris Wilson. v6: Disable dp irq for vlv, that's easier than trying to get at docs and hw. v7: Squash in a fix for Haswell that Paulo Zanoni tracked down - the dp aux registers aren't at a fixed offset any more, but can be on the PCH while the DP port is on the cpu die. Reviewed-by: Imre Deak <imre.deak@intel.com> (v6) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ce99c256 |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: wire up do aux channel done interrupt Doesn't do anything yet than call dp_aux_irq_handler. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
28c70f16 |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: use the gmbus irq for waits We need two special things to properly wire this up: - Add another argument to gmbus_wait_hw_status to pass in the correct interrupt bit in gmbus4. - Since we can only get an irq for one of the two events we want, hand-roll the wait_event_timeout code so that we wake up every jiffie and can check for NAKs. This way we also subsume gmbus support for platforms without interrupts (or where those are not yet enabled). The important bit really is to only enable one gmbus interrupt source at the same time - with that piece of lore figured out, this seems to work flawlessly. Ben Widawsky rightfully complained the lack of measurements for the claimed benefits (especially since the first version was actually broken and fell back to bit-banging). Previously reading the 256 byte hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms. Given that transfering the 256 bytes over i2c at wire speed takes 20.5ms alone, the reduction in additional overhead is rather nice. v2: Chris Wilson wondered whether GMBUS4 might contain some set bits when booting up an hence result in some spurious interrupts. Since we clear GMBUS4 after every wait and we do gmbus transfer really early in the setup sequence to detect displays the window is small, but still be paranoid and clear it properly. v3: Clarify the comment that gmbus irq generation can only support one kind of event, why it bothers us and how we work around that limit. Cc: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
515ac2bb |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: wire up gmbus irq handler Only enables the interrupt and puts a irq handler into place, doesn't do anything yet. Unfortunately there's no gmbus interrupt support for gen2/3 (safe for pnv, but there the irq is marked as "Test mode"). v2: Wire up the irq handler for vlv and gen4 properly. v3: i915_enable_pipestat expects the mask bit, not the status bits ... and for added hilarity those are rather inconsistently named. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
52d7eced |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: reorder setup sequence to have irqs for output setup Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that well. Noticed since the dp aux code doesn't have an automatic fallback with a timeout (since the hw provides for that already). v2: Simple move drm_irq_install before intel_modeset_gem_init, as suggested by Ben Widawsky. v3: Now that interrupts are enabled before all connectors are fully set up, we might fall over serving a HPD interrupt while things are still being set up. Instead of jumping through massive hoops and complicating the code with a separate hpd irq enable step, simply block out the hotplug work item from doing anything until things are in place. v4: Actually, we can enable hotplug processing only after the fbdev is fully set up, since we call down into the fbdev from the hotplug work functions. So stick the hpd enabling right next to the poll helper initialization. v5: We need to enable irqs before intel_modeset_init, since that function sets up the outputs. v6: Fixup cleanup sequence, too. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
61bac78e |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: setup the hangcheck timer early ... together with all the other irq related resources in intel_irq_init. I've managed to oops in the notify_ring function on my ilk, presumably because of the powerctx setup call to i915_gpu_idle. Note that this is only a problem with the reorder irq setup sequence for irq-driver gmbus/dp aux. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d83779a9 |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: don't handle PIPE_LEGACY_BLC_EVENT_STATUS on vlv This is for legacy legacy stuff, and checking with the leftover pipe from the previous loop is propably not what we want. Since pipe == 2 after the loop ... Then we only assing a variable and do nothing with it. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4a06e201 |
|
01-Dec-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: haswell has the same irq handlers as ivb No need to have the exaxt same code twice. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1a240d4d |
|
29-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fixup sparse warnings - __iomem where there is none (I love how we mix these things up). - Use gfp_t instead of an other plain type. - Unconfuse one place about enum pipe vs enum transcoder - for the pch transcoder we actually use the pipe enum. Fixup the other cases where we assign the pipe to the cpu transcoder with explicit casts. - Declare the mch_lock properly in a header. There is still a decent mess in intel_bios.c about __iomem, but heck, this is x86 and we're allowed to do that. Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Use a space after the cast consistently and fix up the newly-added cast in i915_irq.c to properly use __iomem.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
960e3564 |
|
15-Nov-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Support readback of stolen objects upon error Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
acd15b6c |
|
30-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: optimize ilk/snb irq handler We only need to read/write the south interrupt register if the corresponding bit is set in the north master interrupt register. Noticed while reading our interrupt handling code. Same optimization has already been applied on ivb in commit 0e43406bcc1868a316eea6012a0a09d992c53521 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed May 9 21:45:44 2012 +0100 drm/i915: Simplify interrupt processing for IvyBridge We can take advantage that the PCH_IIR is a subordinate register to reduce one of the required IIR reads, and that we only need to clear interrupts handled to reduce the writes. And by simply tidying the code we can reduce the line count and hopefully make it more readable. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
df2b23d9 |
|
27-Nov-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Include the last semaphore sync point in the error-state Should be useful to know what the driver thought the other ring's seqno was when it last used a semaphore. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4fc688ce |
|
02-Nov-2012 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex This allows the power related code to run independently of the rest of the pipeline, extending the resume and init time improvements into userspace, which would otherwise have been blocked on the struct mutex if we were doing PCU communication. v2: Also convert the locking for the rps sysfs interface. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a4da4fa4 |
|
02-Nov-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: extract l3_parity substruct from dev_priv Pretty astonishing how far apart these two members landed ... Especially since I've already removed almost 200 lines in between. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fe2b8f9d |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: convert pipe timing definitions to transcoder Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
702e7a56 |
|
23-Oct-2012 |
Paulo Zanoni <paulo.r.zanoni@intel.com> |
drm/i915: convert PIPECONF to use transcoder instead of pipe Because the PIPECONF register is actually part of the CPU transcoder, not the CPU pipe. Ideally we would also rename PIPECONF to TRANSCONF to remind people that they should use the transcoder instead of the pipe, but let's keep it like this for now since most Gens still name it PIPECONF. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
76e43830 |
|
12-Oct-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move hpd handling to (ibx|cpt)_irq_handler Somehow this was left out in the refactoring that introduced the pch handlers. Avoids a hotplug_mask special case in the ilk_irq_handler. Noticed while hunting down the pch hotplug bits. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cecc21fe |
|
05-Oct-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Align the hangcheck wakeup to the nearest second round_jiffies() aligns the wakeup time to the nearest second in order to batch wakeups and reduce system load, which is useful for unimportant coarse timers like our hangcheck. v2: round_jiffies_relative() returns the relative jiffie value, whereas we need the absolute value for the timer. Suggested-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Arjan van de Ven <arjan@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
74d44445 |
|
02-Oct-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: call drm_handle_vblank before finish_page_flip ... since finish_page_flip needs the vblank timestamp generated in drm_handle_vblank. Somehow all the gmch platforms get it right, but all the pch platform irq handlers get is wrong. Hooray for copy& pasting! Currently this gets papered over by a gross hack in finish_page_flip. A second patch will remove that. Note that without this, the new timestamp sanity checks in flip_test occasionally get tripped up, hence the cc: stable tag. Cc: stable@vger.kernel.org Reviewed-by: mario.kleiner@tuebingen.mpg.de Tested-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
760285e7 |
|
02-Oct-2012 |
David Howells <dhowells@redhat.com> |
UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/ Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
|
#
4126d5d6 |
|
02-Oct-2012 |
David Howells <dhowells@redhat.com> |
UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding patch. Without this patch and the patch to make include the UAPI headers from the core headers, after the UAPI split, the DRM C sources cannot find these UAPI headers because the DRM code relies on specific -I flags to make #include "..." work on headers in include/drm/ - but that does not work after the UAPI split without adding more -I flags. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
|
#
ff1f525e |
|
02-Oct-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: s/DRM_IRQ_ARGS/int irq, void *arg I'm official fed up with the yelling and useless indirection. Let it burn! Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ae33cdcf |
|
27-Sep-2012 |
Vijay Purushothaman <vijay.a.purushothaman@intel.com> |
drm/i915: Fix SDVO IER and status bits for Valleyview Fixed SDVOB and SDVOC bit definitions for Valleyview. Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
3bcedbe5 |
|
19-Sep-2012 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: limit VLV IRQ enables to those we use To match IVB. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
79249636 |
|
07-Sep-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Error checks in gen6_set_rps With the new "standardized" sysfs interfaces we need to be a bit more careful about setting the RPS values. Because the sysfs code and the rps workqueue can run at the same time, if the sysfs setter wins the race to the mutex, the workqueue can come in and set a value which is out of range (ie. we're no longer protecting by RPINTLIM). I was not able to actually make this error occur in testing. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9da3da66 |
|
01-Jun-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace the array of pages with a scatterlist Rather than have multiple data structures for describing our page layout in conjunction with the array of pages, we can migrate all users over to a scatterlist. One major advantage, other than unifying the page tracking structures, this offers is that we replace the vmalloc'ed array (which can be up to a megabyte in size) with a chain of individual pages which helps reduce memory pressure. The disadvantage is that we then do not have a simple array to iterate, or to access randomly. The common case for this is in the relocation processing, which will typically fit within a single scatterlist page and so be almost the same cost as the simple array. For iterating over the array, the extra function call could be optimised away, but in reality is an insignificant cost of either binding the pages, or performing the pwrite/pread. v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the trivial compile error from rebasing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
974a3b0f |
|
09-Sep-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: set the right gen3 flip_done mode also at resume Currently we've only frobbed this bit at irq_init time, but did not restore it at resume time. Move it to the gen3 clock gating function to fix this. Notice while reading through code. Cc: stable@vger.kernel.org (for 3.5 only) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
20e4d407 |
|
08-Aug-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/ips: move drps/ips/ilk related variables into dev_priv->ips Like with the equivalent change for gen6+ rps state, this helps in clarifying the code (and in fixing a few places that have fallen through the cracks in the locking review). Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
85f9e50d |
|
31-Aug-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move i915_get_extra_insdone out of CONFIG_DEBUG_FS block Otherwise it just won't compile ... Reported-by: Fengguang Wu <fengguang.wu@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@gmail.com>
|
#
050ee91f |
|
22-Aug-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Use new INSTDONE registers (Gen7+) Using the extracted INSTDONE reading, and our new register definitions, update our hangcheck detection and error collection to use it. This primarily means changing == to memcmp, and changing = to memcpy. Hopefully this will give more info on error dump, and provide more accurate hangcheck detection (both are actually TBD). Also, remove the reading of instdone1 from the ring error collection function, and just crap everything in capture_error_state (that could be split into a separate patch if it wasn't so trivial). v2: Now assuming i915_get_extra_instdone does the memset we can clean up the code a bit (Jani) v3: use ARRAY_SIZE as requested earlier by Jani (didn't change sizeof) Updated commit msg Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bd9854f9 |
|
23-Aug-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Extract reading INSTDONE INSTDONE is used in many places, and it varies from generation to generation. This provides a good reason for us to extract the logic to read the relevant information. The patch has no functional change. It's prep for some new stuff. v2: move the memset inside of i915_get_extra_instdone (Jani) v3,4: bugs caught by (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
71e172e8 |
|
20-Aug-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Add ERR_INT to gen7 error state ERR_INT can generate interrupts. However since most of the conditions seem quite fatal the patch opts to simply report it in error state instead of adding more complexity to the interrupt handler for little gain (the bits are sticky anyway). Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Antti Koskipaa <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6c085a72 |
|
20-Aug-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Track unbound pages When dealing with a working set larger than the GATT, or even the mappable aperture when touching through the GTT, we end up with evicting objects only to rebind them at a new offset again later. Moving an object into and out of the GTT requires clflushing the pages, thus causing a double-clflush penalty for rebinding. To avoid having to clflush on rebinding, we can track the pages as they are evicted from the GTT and only relinquish those pages on memory pressure. As usual, if it were not for the handling of out-of-memory condition and having to manually shrink our own bo caches, it would be a net reduction of code. Alas. Note: The patch also contains a few changes to the last-hope evict_everything logic in i916_gem_execbuffer.c - we no longer try to only evict the purgeable stuff in a first try (since that's superflous and only helps in OOM corner-cases, not fragmented-gtt trashing situations). Also, the extraction of the get_pages retry loop from bind_to_gtt (and other callsites) to get_pages should imo have been a separate patch. v2: Ditch the newly added put_pages (for unbound objects only) in i915_gem_reset. A quick irc discussion hasn't revealed any important reason for this, so if we need this, I'd like to have a git blame'able explanation for it. v3: Undo the s/drm_malloc_ab/kmalloc/ in get_pages that Chris noticed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Split out code movements and rant a bit in the commit message with a few Notes. Done v2] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b2eadbc8 |
|
09-Aug-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Lazily apply the SNB+ seqno w/a Avoid the forcewake overhead when simply retiring requests, as often the last seen seqno is good enough to satisfy the retirment process and will be promptly re-run in any case. Only ensure that we force the coherent seqno read when we are explicitly waiting upon a completion event to be sure that none go missing, and also for when we are reporting seqno values in case of error or debugging. This greatly reduces the load for userspace using the busy-ioctl to track active buffers, for instance halving the CPU used by X in pushing the pixels from a software render (flash). The effect will be even more magnified with userptr and so providing a zero-copy upload path in that instance, or in similar instances where X is simply compositing DRI buffers. v2: Reverse the polarity of the tachyon stream. Daniel suggested that 'force' was too generic for the parameter name and that 'lazy_coherency' better encapsulated the semantics of it being an optimization and its purpose. Also notice that gen6_get_seqno() is only used by gen6/7 chipsets and so the test for IS_GEN6 || IS_GEN7 is redundant in that function. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9270388e |
|
09-Aug-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: fix up ilk drps/ips locking We change the drps/ips sw/hw state from different callers: Our own irq handler, the external intel-ips module and from process context. Most of these callers don't take any lock at all. Protect everything by making the mchdev_lock irqsave and grabbing it in all relevant callsites. Note that we have to convert a few sleeps in the drps enable/disable code to delays, but alas, I'm not volunteering to restructure the code around a few work items. For paranoia add a spin_locked assert to ironlake_set_drps, too. v2: Move one access inside the lock protection. Caught by the dev_priv->ips mass-rename ... v3: Resolve rebase conflict. Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
73edd18f |
|
08-Aug-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: DE_PCU_EVENT irq is ilk-only Like all the other drps/ips stuff. Hence add the corresponding check, give the function a preciser prefix and move the single reg clearing into the rps handling function, too. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c6a828d3 |
|
08-Aug-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move all rps state into dev_priv->rps This way it's easier so see what belongs together, and what is used by the ilk ips code. Also add some comments that explain the locking. Note that (cur|min|max)_delay need to be duplicated, because they're also used by the ips code. v2: Missed one place that the dev_priv->ips change caught ... Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e1ef7cc2 |
|
24-Jul-2012 |
Ben Widawsky <benjamin.widawsky@intel.com> |
drm/i915: Macro to determine DPF support Originally I had a macro specifically for DPF support, and Daniel, with good reason asked me to change it to this. It's not the way I would have gone (and indeed I didn't), but for now there is no distinction as all platforms with L3 also have DPF. Note: The good reasons are that dpf is a l3$ feature (at least on currrent hw), hence I don't expect one to go without the other. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: added note] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0201f1ec |
|
19-Jul-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace the pending_gpu_write flag with an explicit seqno As we always flush the GPU cache prior to emitting the breadcrumb, we no longer have to worry about the deferred flush causing the pending_gpu_write to be delayed. So we can instead utilize the known last_write_seqno to hopefully minimise the wait times. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
12f55818 |
|
05-Jul-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Add comments to explain the BSD tail write workaround Having had to dive into the bspec to understand what each stage of the workaround meant, and how that the ring broadcasting IDLE corresponded with the GT powering down the ring (i.e. rc6) add comments to aide the next reader. And since the register "is used to control all aspects of PSMI and power saving functions" that makes it quite interesting to inspect with regards to RC6 hangs, so add it to the error-state. v2: Rediscover the piece of magic, set the RNCID to 0 before waiting for the ring to wake up. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
58bf8062 |
|
21-Jun-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: rip out the PM_IIR WARN After banging my head against this for the past few months, I still don't see how this could possible race under the premise that once an irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again until we unmask it in PM_IMR. Still, we have reports of this being seen in the wild. Now Bspec has this little bit of lovely language in the PMIIR register: Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR": "For each bit, the IIR can store a second pending interrupt if two or more of the same interrupt conditions occur before the first condition is cleared. Upon clearing the interrupt, the IIR bit will momentarily go low, then return high to indicate there is another interrupt pending." Now if we presume that PMIMR only prevent new interrupts from being queued, we could easily end up masking an interrupt and clearing it, but the 2nd pending interrupt setting the bit in PMIIR right away again. Which leads, the next time the irq handler runs, to hitting the WARN. Also, no bad side effects of this have ever been reported. And we've tracked down our issues with the gpu turbo getting stuck to bogus interrupt generation limits in th RPLIMIT register. So let's just rip out this WARN as bogus and call it a day. The only shallow thing here is that this 2-deep irq queue in the hw makes you wonder how racy the windows irq handler is ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907 Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
31acc7f5 |
|
20-Jun-2012 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: support page flipping on ValleyView And restructure the IRQ handling a little. We can use pipestat for most things, and make sure we don't affect pipe events when enabling and disabling vblank interupts. We can leave vblank interrupts masked but enabled so we're not dependent on the first client to toggle the disable timer. We can also mask all render based interrupts, since the ring code will handle unmasking them for us. v2: roll in vblank masking, remove unneeded variable (Daniel) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b9a3906b |
|
04-Jun-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: add ccid to error state Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
|
#
23e81d69 |
|
06-Jun-2012 |
Adam Jackson <ajax@redhat.com> |
drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler Cougar/Panther Point redefine the bits in SDEIIR pretty completely. This function is just debugging, but if we're debugging we probably want to be told accurate things instead of lies. I'm told Lynx Point changes this yet more, but I have no idea how... Note from Eugeni's review: "For the record and for future enabling efforts, for LPT, bits 28-31 and 1-14 are gone since CPT/PPT (e.g., those must be zero). And there is the bit 15 as a new addition, but we are not using it yet and probably won't be using in foreseeable future." Signed-off-by: Adam Jackson <ajax@redhat.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35103 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
98fd81cd |
|
31-May-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: initialize the parity work only once This fixes an (albeit really hard to hit) race resulting in an oops: - The parity work get scheduled. - We re-init the irq state and call INIT_WORK again. - The workqueue code tries to run the work item and stumbles over a work item that should be on it's runlist. Also initiliaze the work item unconditionally like all the others, it's simpler. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d2ba8470 |
|
31-May-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: ivybridge_handle_parity_error should be static Notice by Fengguang Wu's automatic sparse checker. Reported-by: Fengguang Wu <wfg@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
15b9f80e |
|
25-May-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: enable parity error interrupts The previous patch put all the code, and handlers in place. It should now be safe to enable the parity error interrupt. The parity error must be unmasked in both the GTIMR, and the CS IMR. Unfortunately, the docs aren't clear about this; nevertheless it's the truth. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e3689190 |
|
25-May-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: Dynamic Parity Detection handling On IVB hardware we are given an interrupt whenever a L3 parity error occurs in the L3 cache. The L3 cache is used by internal GPU clients only. This is a very rare occurrence (in fact to test this I need to use specially instrumented silicon). When a row in the L3 cache detects a parity error the HW generates an interrupt. The interrupt is masked in GTIMR until we get a chance to read some registers and alert userspace via a uevent. With this information userspace can use a sysfs interface (follow-up patch) to remap those rows. Way above my level of understanding, but if a given row fails, it is statistically more likely to fail again than a row which has not failed. Therefore it is desirable for an operating system to maintain a lifelong list of failing rows and always remap any bad rows on driver load. Hardware limits the number of rows that are remappable per bank/subbank, and should more than that many rows detect parity errors, software should maintain a list of the most frequent errors, and remap those rows. V2: Drop WARN_ON(IS_GEN6) (Jesse) DRM_DEBUG row/bank/subbank on errror (Jesse) Comment updates (Jesse) Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7b9e0ae6 |
|
28-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Always update RPS interrupts thresholds along with frequency In order to avoid missed down-interrupts when coming out of RC6, it is advised that we always reset the down-threshold upon a PM event. This is due to that the PM unit goes through a little dance when coming out of RC6, it first brings the GPU up at the lowest frequency then a short time later it restores the thresholds. During that interval, the down-interval may expire and the interrupt be suppressed. Now aware of the dance taking place within the GPU when coming out of RC6, one wonders what other writes need to be queued in the fifo buffer in order to be properly sequenced; setting the RP state appears to be one. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44006 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
084b612e |
|
11-May-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x Note that gen3 is the only platform where we've got the bit definitions right, hence the workaround of disabling sdvo hotplug support on i945g/gm is not due to misdiagnosis of broken hotplug irq handling ... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: add some blurb about sdvo hotplug fail on i945g/gm I've wondered about while reviewing.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
adca4730 |
|
11-May-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq Also as we set the HOTPLUG_EN to 0 during pre-install, we can simply set it during post-install, and nor do we wish to enable unwanted hotplug events. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b4519513 |
|
11-May-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Introduce for_each_ring() macro In many places we wish to iterate over the rings associated with the GPU, so refactor them to use a common macro. Along the way, there are a few code removals that should be side-effect free and some rearrangement which should only have a cosmetic impact, such as error-state. Note that this slightly changes the semantics in the hangcheck code: We now always cycle through all enabled rings instead of short-circuiting the logic. v2: Pull in a couple of suggestions from Ben and Daniel for intel_ring_initialized() and not removing the warning (just moving them to a new home, closer to the error). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Added note to commit message about the small behaviour change, suggested by Ben Widawsky.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7d4e146f |
|
09-May-2012 |
Eugeni Dodonov <eugeni.dodonov@intel.com> |
drm/i915: reuse Ivy Bridge interrupts code for Haswell Haswell interrupts are mostly similar with Ivy Bridge, so we share same routines with it. This patch also simplifies the vblank counter handling for all the Gen5+ architectures. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0e43406b |
|
09-May-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Simplify interrupt processing for IvyBridge We can take advantage that the PCH_IIR is a subordinate register to reduce one of the required IIR reads, and that we only need to clear interrupts handled to reduce the writes. And by simply tidying the code we can reduce the line count and hopefully make it more readable. v2: Split out the bugfix from the refactoring. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9adab8b5 |
|
09-May-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid a double-read of PCH_IIR during interrupt handling Currently the code re-reads PCH_IIR during the hotplug interrupt processing. Not only is this a wasted read, but introduces a potential for handling a spurious interrupt as we then may not clear all the interrupts processed (since the re-read IIR may contains more interrupts asserted than we clear using the result of the original read). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
b615b57a |
|
02-May-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Support pageflipping interrupts for all 3-pipes on IVB Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d4b8bb2a |
|
27-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: kill flags parameter for reset functions Only half of them even cared, and it's always the same one. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
742cbee8 |
|
27-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: rework dev->first_error locking - reduce the irq disabled section, even for a debugfs file this was way too long. - always disable irqs when taking the lock. v2: Thou shalt not mistake locking for reference counting, so: - reference count the error_state to protect from concurent freeeing. This will be only really used in the next patch. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d05c617e |
|
26-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: extract dri1 breadcrumb update from irq handler ... and hide it in i915_dma.c. This way all the legacy stuff dealing with READ_BREADCRUMB and LP_RING and friends is in i915_dma.c. v2: Rebase on top of Chris Wilson's rework irq handling code. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9488867a |
|
26-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move dri1 irq ioctl code to i915_dma.c Let's just get this out of the way. v2: Rebase against ENODEV changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
647a3fb2 |
|
26-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: rip out dri1 breadcrumb updates from gen5+ irq handlers We never supported dri1 on gen5+. VLV never had that code, so no need to remove it. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d1c1edbc |
|
26-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: move dri1 vblank stubs to i915_dma.c i915_dma.c contains most of the old dri1 horror-show, so move the remaining bits there, too. The code has been removed and the only thing left are some stubs to ensure that userspace doesn't try to use this stuff. vblank_pipe_set only returns 0 without any side-effects, so we can even stub it out with the canonical drm_noop. v2: Rebase against ENODEV changes. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7001f22f |
|
30-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove unused dev_priv->vblank_pipe vblank_pipe was intended to be used for tracking DRI1 state. However, the vblank_pipe reported to DRI1 is fixed to umask both pipes, and the dev_priv->vblank_pipe unused and superfluous. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6d171cb4 |
|
28-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove unused ring->irq_seqno Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9574b3fe |
|
26-Apr-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: kill waiting_seqno The waiting_seqno is not terribly useful, and as such we can remove it so that we'll be able to extract lockless code. v2: Keep the information for error_state (Chris) Check if ring is initialized in hangcheck (Chris) Capture the waiting ring (Chris) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: add some bikeshed to clarify a comment.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
be998e2e |
|
26-Apr-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: move vbetool invoked ier stuff This extra bit of interrupt enabling code doesn't belong in the wait seqno function. If anything we should pull it out to a helper so the throttle code can also use it. The history is a bit vague, but I am going to attempt to just dump it, unless someone can argue otherwise. Removing this allows for a shared lock free wait seqno function. To keep tabs on this issue though, the IER value is stored on error capture (recommended by Chris Wilson) v2: fixed typo EIR->IER (Ben) Fix some white space (Ben) Move IER capture to globally instead of per ring (Ben) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: ier is a 16 bit reg on gen2!] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
624f8698 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove unused and unloved vblank macros Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bbba0a97 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Inline I915_INTERRUPT_ENABLE_FIX Since there is only one remaining user of I915_INTERRUPT_ENABLE_FIX, expand it at the callsite. Quoting Jesse Barnes: "I'd really like to get rid of these defines at the top of i915_irq.c. Some are unused and the others just make you check for the right bits everytime your read the code." Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Add bikeshed suggested by Jesse.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
38bde180 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Handle PendingFlip on gen3 robustly We appear to allow too many pending pageflips as evidenced by an apparent pin-leak. So borrow the pageflip completion logic from i8xx for handling PendingFlip in a robust manner. v2: Address Jesse's reminders about the nuances of gen3 IRQ handling. References: https://bugzilla.kernel.org/show_bug.cgi?id=41882 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
55b39755 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Cleanup gen3 irq uninstall Bring the for-each-pipe loops together so that the code is easier on the eyes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
00d98ebd |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: HWSTAM is only 16-bit on gen3 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8291ee90 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove gen4 irq code from gen3 irq routine A couple of miscellaneous cleanups as well to move per-loop condition variables within the scope of the loop and the update of the DRI1 breadcrumb to the tail of the function. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
2c8ba29f |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove gen3 irq code from gen4 irq routine And a couple of miscellaneous cleanups to the main body of the IRQ loop; move per-loop condition variables within the scope of the loop and move the old DRI1 breadcrumb to the tail of the function and so only execute it once. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
4f7d1e79 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Clear FlipDone semantics change for pageflipping on gen3 On later gen3, you are able to select the meaning of the FlipPending status bit in IIR and change it to FlipDone. This was sometimes done by the BIOS leading to confusion on just how pageflipping worked on gen3. Simplify the implementation by using the legacy meaning for all gen3 machines. Note: this makes all gen3 machines equally broken... Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a266c7d5 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Duplicate and split the gen3/4 irq handler In preparation for rewriting the gen3 irq handler. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e0f608d7 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: pending_flip_is_done is gen3, name it so And remove the cargo-culted copy from the valleyview irq handler. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fa883c62 |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove redundant initialisation of per-ring IRQ waitqueues The waitqueues are already initialised during ring initialisation so kill the redundant and duplicated code to do so in each generations IRQ installer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
8b2e326d |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Unconditionally initialise the interrupt workers Rather than duplicate similar code across the IRQ installers, perform the initialisation of the workers upfront. This will lead to simpler teardown and quiescent code as we can assume that the workers have been initialised. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
cd9d4e9f |
|
24-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: check for kms in dri1 ioctls Calling these when gem assumes full control of the hw won't end in anything else than tears. So be a bit more paranoid here. Just serves as documentation. v2: Bail out with ENODEV as suggested by Chris Wilson. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
1b50247a |
|
24-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove the list of pinned inactive objects Simplify object tracking by removing the inactive but pinned list. The only place where this was used is for counting the available memory, which is just as easy performed by checking all objects on the rare occasions it is required (application startup). For ease of debugging, we keep the reporting of pinned objects through the error-state and debugfs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6b26c86d |
|
24-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: create macros to handle masked bits ... and put them to so good use. Note that there's functional change in vlv clock gating code, we now no longer spuriously read back the current value of the bit. According to Bspec the high bits should always read zero, so ORing this in should have no effect. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c2798b19 |
|
22-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: i8xx interrupt handler gen2 hardware has some significant differences from the other interrupt routines that were glossed over and then forgotten about in the transition to KMS. Such as - 16bit IIR - PendingFlip status bit This patch reintroduces a handler specifically for gen2 for the purpose of handling pageflips correctly, simplifying code in the process. v2: Also fixup ring get/put irq to only access 16bit registers (Daniel) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24202 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41793 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: use posting_read16 in intel_ringbuffer.c and kill _driver from the function names.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
446f2545 |
|
30-Mar-2012 |
Armin Reese <armin.c.reese@intel.com> |
drm/i915: Mask reserved bits in display/sprite address registers The purpose of this patch is to avoid zeroing the lower 12 reserved bits of surface base address registers (framebuffer & sprite). There are bits in that range that may occasionally be set by BIOS or by other components. Signed-off-by: Armin Reese <armin.c.reese@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fc6826d1 |
|
15-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Refactor the deferred PM_IIR handling into a single function This function, along with the registers and deferred work hander, are all shared with SandyBridge, IvyBridge and their variants. So remove the duplicate code into a single function. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d1e61e7f |
|
10-Apr-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Trigger hangcheck if we detect more a repeating missed IRQ On the first instance we just wish to kick the waiters and see if that terminates the wait conditions. If it does not, then we do not want to keep retrying without ever making any forward progress and becoming stuck in a hangcheck loop. Reported-and-tested-by: Lukas Hejtmanek <xhejtman@fi.muni.cz> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48209 Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
9d2f41fa |
|
02-Apr-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: dump the DMA fetch addr register on pre-gen6 It exists way back to gen2, bug got moved around on gen4 a bit. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e7b4c6b1 |
|
30-Mar-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: extract gt interrupt handler vlv, ivb and snb all share the gen6+ gt irq handling. 3 copies of the same stuff is a bit much, so extract it into a little helper. Now ilk has a different gt irq handling than snb, but shares the same irq handler (due to the similar display block). So also extract the ilk gt irq handling to clearly separate these two things. Nice side effect of this is that we can complete Ben Widawsky's gen6+ irq bit #define cleanup and call the render irq also with the GEN6 alias. Beforehand that code was shared with ilk, and neither option really made much sense. As a bonus this enables the error interrupt handling lifted from the vlv code on snb and ivb, too. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Antagonized-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
fad2596a |
|
30-Mar-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: rip out old HWSTAM missed irq WA for vlv This got copy-pasted from an older version. The newer kinds of workarounds don't need this anymore. Shame on me for not noticing when picking up the vlv irq patch. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
e2a1e2f0 |
|
29-Mar-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: ring irq cleanups - gen6 put/get only need one argument rflags and gflags are always the same (see above explanation) - remove a couple redundantly defined IRQs - reordered some lines to make things go in descending order Every ring has its own interrupts, enables, masks, and status bits that are fed into the main interrupt enable/mask/status registers. At one point in time it seemed like a good idea to make our functions support the notion that each interrupt may have a different bit position in the corresponding register (blitter parser error may be bit n in IMR, but bit m in blitter IMR). It turned out though that the HW designers did us a solid on Gen6+ and this unfortunate situation has been avoided. This allows our interrupt code to be cleaned up a bit. I jammed this into one commit because there should be no functional change with this commit, and staging it into multiple commits was unnecessarily artificial IMO. CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: - fixed up merged conflict with vlv changes. - added GEN6 to GT blitter bit, we only use it on gen6+. - added a comment to both ring irq bits and GT irq bits that on gen6+ these alias. - added comment that GT_BSD_USER_INTERRUPT is ilk-only. - I've got confused a bit that we still use GT_USER_INTERRUPT on ivb for the render ring - but this goes back to ilk where we have only gt interrupt bits and so we be equally confusing if changed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7e231dbe |
|
28-Mar-2012 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: ValleyView IRQ support ValleyView has a new interrupt architecture; best to put it in a new set of functions. Also make sure the ring mask functions handle ValleyView. FIXME: fix flipping; need to enable interrupts and call prepare/finish Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
74898d7e |
|
15-Feb-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: bind objects to the global gtt only when needed And track the existence of such a binding similar to the aliasing ppgtt case. Speeds up binding/unbinding in the common case where we only need a ppgtt binding (which is accessed in a cpu coherent fashion by the gpu) and no gloabl gtt binding (which needs uc writes for the ptes). This patch just puts the required tracking in place. v2: Check that global gtt mappings exist in the error_state capture code (with Chris Wilson's llc reloc patches batchbuffers are no longer relocated as mappable in all situations, so this matters). Suggested by Chris Wilson. v3: Adapted to Chris' latest llc-reloc patches. v4: Fix a bug in the i915 error state capture code noticed by Chris Wilson. Reviewed-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
a70491cc |
|
18-Mar-2012 |
Joe Perches <joe@perches.com> |
i915: Add and use pr_fmt and pr_<level> Use a more current logging style. Ensure that appropriate logging messages are prefixed with "i915: ". Convert printks to pr_<level>. Align arguments. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
ee4f42b1 |
|
15-Feb-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record the position of the request upon error So that we can tally the request against the command sequence in the ringbuffer, or merely jump to the interesting locations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
52d39a21 |
|
15-Feb-2012 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record the in-flight requests at the time of a hang Being able to tally the list of outstanding requests with the sequence of commands in the ringbuffer is often useful evidence with respect to driver corruption. Note that since this is the umpteenth per-ring data structure to be added to the error state, I've coallesced the nearby loops (the ringbuffer and batchbuffer) into a single structure along with the list of requests. A later task would be to refactor the ring register state into the same structure. v2: Fix pretty printing of requests so that they are parsed correctly by intel_error_decode and use the 0x%08x format for seqno for consistency Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
99ffa162 |
|
25-Jan-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: enable forcewake voodoo also for gen6 We still have reports of missed irqs even on Sandybridge with the HWSTAM workaround in place. Testing by the bug reporter gets rid of them with the forcewake voodoo and no HWSTAM writes. Because I've slightly botched the rebasing I've left out the ACTHD readback which is also required to get IVB working. Seems to still work on the tester's machine, so I think we should go with the more minmal approach on SNB. Especially since I've only found weak evidence for holding forcewake while waiting for an interrupt to arrive, but none for the ACTHD readback. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45181 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45332 Tested-by: Nicolas Kalkhof nkalkhof()at()web.de Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7e3b8737 |
|
01-Feb-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: dump even more into the error_state Chris Wilson and me have again stared at funny error states and it's been pretty clear from the start that something was seriously amiss. The seqnos last seen by the cpu were a few hundred behind those that the gpu could have possibly emitted last before it died ... Chris now tracked it down (hopefully, definit verdict's still out), but in hindsight we'd have found the bug by simply dumping the cpu side tracking of the ring head and tail registers. Fix this and prevent an identical time-waster in the future. Because the hangs always involved semaphores in one way or another, we've tried to dump the mbox registers, but couldn't find any inconsistencies. Still, dump them too. Reviewed-and-wanted-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
172975aa |
|
14-Dec-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Handle unmappable buffers during error state capture As the buffer is not necessarily accessible through the GTT at the time of a GPU hang, and capturing some of its contents is far more valuable than skipping it, provide a clflushed fallback read path. We still prefer to read through the GTT as that is more consistent with the GPU access of the same buffer. So example it will demonstrate any errorneous tiling or swizzling of the command buffer as seen by the GPU. This becomes necessary with use of CPU relocations and lazy GTT binding, but could potentially happen anyway as a result of a pathological error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
33f3f518 |
|
14-Dec-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: add per-ring fault reg to error_state This was pretty handy when figuring out what exactly went wrong with ppgtt and it might also be useful when we stop filling the entire gart with scratch page entries. Also add the gen6+ DONE reg while at it. v2: Chris Wilson suggested to allocate the error_state with kzalloc for better paranoia. Also kill existing spurious clears of the error_state while at it. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
653d7bed |
|
14-Dec-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: capture error_state also for stuck rings Since quite a while we also the basic output configuration in the error_state, so it should contain enough information to diagnose these MI_WAIT hangs. Reviewed-and-tested-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
c1cd90ed |
|
14-Dec-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: collect more per ring error state Based on a patch by Ben Widawsky, but with different colors for the bikeshed. In contrast to Ben's patch this one doesn't add the fault regs. Afaics they're for the optional page fault support which - we're not enabling - and which seems to be unsupported by the hw team. Recent bspec lacks tons of information about this that the public docs released half a year back still contain. Also dump ring HEAD/TAIL registers - I've recently seen a few error_state where just guessing these is not good enough. v2: Also dump INSTPM for every ring. v3: Fix a few really silly goof-ups spotted by Chris Wilson. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
d27b1e0e |
|
14-Dec-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: refactor ring error state capture to use arrays The code already got unwieldy and we want to dump more per-ring registers. Only functional change is that we now also capture the video ring registers on ilk. v2: fixup a refactor fumble spotted by Chris Wilson. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
96154f2f |
|
14-Dec-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: switch ring->id to be a real id ... and add a helpr function for the places where we want a flag. This way we can use ring->id to index into arrays. v2: Resurrect the missing beautification-space Chris Wilson noted. I'm moving this space around because I'll reuse ring_str in the next patch. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
6dc0e816 |
|
23-Jan-2012 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: correct lock type in destroy This is only relevant when using module unloading, and really only helps get rid of a probably benign warning. I can't remember if I sent this out already, but it's not turning up in any of my searches. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
bdfcdb63 |
|
04-Jan-2012 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: rip out the HWSTAM missed irq workaround With the new ducttape of much finer quality, this seems to be no longer necessary. Tested on my ivb and snb machine with the usual suspects of testcases. (v2 by keithp -- limited change to IVB only for now) Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
4e0e90dc |
|
14-Dec-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: kicking rings stuck on semaphores considered harmful If our semaphore logic gets confused and we have a ring stuck waiting for one, there's a decent chance it'll just execute garbage when being kicked. Also, kicking the ring obscures the place where the error first occured, making error_state decoding much harder. So drop this an let gpu reset handle this mess in a clean fashion. In contrast, kicking rings stuck on MI_WAIT is rather harmless, at worst there'll be a bit of screen-flickering. There's also old broken userspace out there which needs this as a work-around. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
01f2c773 |
|
19-Dec-2011 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Replace pitch with pitches[] in drm_framebuffer Otherwise each driver would need to keep the information inside their own framebuffer object structure. Also add offsets[]. BOs on the other hand are driver specific, so those can be kept in driver specific structures. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
097354eb |
|
27-Nov-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: check ACTHD of all rings Otherwise hangcheck spuriously fires when running blitter/bsd-only workloads. Contrary to a similar patch by Ben Widawsky this does not check INSTDONE of the other rings. Chris Wilson implied that in a failure to detect a hang, most likely because INSTDONE was fluctuating. Thus only check ACTHD, which as far as I know is rather reliable. Also, blitter and bsd rings can't launch complex tasks from a single instruction (like 3D_PRIM on the render with complex or even infinite shaders). This fixes spurious gpu hang detection when running tests/gem_hangcheck_forcewake on snb/ivb. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
775d17b6 |
|
09-Oct-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: Ivybridge still has fences! So don't forget to restore them on resume and dump them into the error state. Cc: stable@kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
a9e2641d |
|
08-Sep-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: close PM interrupt masking races in the rps work func This patch closes the following race: We get a PM interrupt A, mask it, set dev_priv->iir = PM_A and kick of the work item. Scheduler isn't grumpy, so the work queue takes rps_lock, grabs pm_iir = dev_priv->pm_iir and pm_imr = READ(PMIMR). Note that pm_imr == pm_iir because we've just masked the interrupt we've got. Now hw sends out PM interrupt B (not masked), we process it and mask it. Later on the irq handler also clears PMIIR. Then the work item proceeds and at the end clears PMIMR. Because (local) pm_imr == pm_iir we have pm_imr & ~pm_iir == 0 so all interrupts are enabled. Hardware is still interrupt-happy, and sends out a new PM interrupt B. PMIMR doesn't mask B (it does not mask anything), PMIIR is cleared, so we get it and hit the WARN in the interrupt handler (because dev_priv->pm_iir == PM_B). That's why I've moved the WRITE(PMIMR, 0) up under the protection of the rps_lock. And write an uncoditional 0 to PMIMR, because that's what we'll do anyway. This races looks much more likely because we can arbitrarily extend the window by grabing dev->struct mutex right after the irq handler has processed the first PM_B interrupt. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
4fb066ab |
|
08-Sep-2011 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: close PM interrupt masking races in the irq handler Quoting Chris Wilson's more concise description: "Ah I think I see the problem. As you point out we only mask the current interrupt received, so that if we have a task pending (and so IMR != 0) we actually unmask the pending interrupt and so could receive it again before the tasklet is finally kicked off by the grumpy scheduler." We need the hw to issue PM interrupts A, B, A while the scheduler is hating us and refuses to run the rps work item. On receiving PM interrupt A we hit the WARN because dev_priv->pm_iir == PM_A | PM_B Also add a posting read as suggested by Chris to ensure proper ordering of the writes to PMIMR and PMIIR. Just in case somebody weakens write ordering. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
192aac1f |
|
20-Sep-2011 |
Keith Packard <keithp@keithp.com> |
drm/i915: Shut down PCH interrupts during irq_uninstall This masks out all interrupts and ack's any pending ones at IRQ uninstall time to make sure we don't receive any unexpected interrupts later on. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
7fe0b973 |
|
19-Sep-2011 |
Keith Packard <keithp@keithp.com> |
drm/i915: Enable digital port hotplug on PCH systems We were relying on the BIOS to set these bits, which doesn't always happen. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
#
0206e353 |
|
16-Aug-2011 |
Akshay Joshi <me@akshayjoshi.com> |
Drivers: i915: Fix all space related issues. Various issues involved with the space character were generating warnings in the checkpatch.pl file. This patch removes most of those warnings. Signed-off-by: Akshay Joshi <me@akshayjoshi.com> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
c3613de9 |
|
12-Aug-2011 |
Keith Packard <keithp@keithp.com> |
drm/i915: Can't do accurate vblank timestamps with UMS Disable this feature when KMS is not running by setting the driver->get_vblank_timestamp function pointer to NULL. Signed-off-by: Keith Packard <keithp@keithp.com> Tested-by: Justin P. Mattock <justinmattock@gmail.com>
|
#
40ee3381 |
|
28-Jul-2011 |
Keith Packard <keithp@keithp.com> |
drm/i915: Fixup for 'Hold mode_config->mutex during hotplug' drm_helper_hpd_irq_event queues another work proc to go and deliver the user-space event, and that function also wants to hold the config mutex, so we shouldn't hold the mutex across the drm_helper_hpd_irq_event call. Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
a65e34c7 |
|
25-Jul-2011 |
Keith Packard <keithp@keithp.com> |
drm/i915: Hold mode_config->mutex during hotplug processing Hotplug detection is a mode setting operation and must hold the struct_mutex or risk colliding with other mode setting operations. In particular, the display port hotplug function attempts to re-train the link if the monitor is supposed to be running when plugged back in. If that happens while mode setting is underway, the link will get scrambled, leaving it in an inconsistent state. This is a special case -- usually the driver mode setting entry points are covered by the upper level DRM code, but in this case the function is invoked as a work function not under the control of DRM. Signed-off-by: Keith Packard <keithp@keithp.com> Cc: stable@kernel.org Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
2b1ecb73 |
|
01-Jul-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: apply HWSTAM writes to Ivy Bridge as well In an attempt to fix 38862 and 38863. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
f71d4af4 |
|
28-Jun-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: move IRQ function table init to i915_irq.c This lets us make the various IRQ functions static and helps avoid problems like the one fixed in "drm/i915: Use chipset-specific irq installers" where one of the exported functions was called rather than the chipset specific version. This also fixes a UMS-mode bug -- the correct irq functions for IRL and later chips were only getting loaded in the KMS path. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
3e0dc6b0 |
|
29-Jun-2011 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: hangcheck disable parameter Provide a parameter to disable hanghcheck. This is useful mostly for developers trying to debug known problems, and probably should not be touched by normal users. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
ec6a890d |
|
21-Jun-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Apply HWSTAM workaround for BSD ring on SandyBridge ...we need to apply exactly the same workaround for missing interrupts from BSD as for the BLT ring, apparently. See also commit 498e720b96379d8ee9c294950a01534a73defcf3 (drm/i915: Fix gen6 (SNB) missed BLT ring interrupts). Reported-and-tested-by: nkalkhof@web.de Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38529 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
498e720b |
|
17-Jun-2011 |
Daniel J Blueman <daniel.blueman@gmail.com> |
drm/i915: Fix gen6 (SNB) missed BLT ring interrupts. The failure appeared in dmesg as: [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 35064155, at 35064155], missed IRQ? This works around that problem on by making the blitter command streamer write interrupt state to the Hardware Status Page when a MI_USER_INTERRUPT command is decoded, which appears to force the seqno out to memory before the interrupt happens. v1->v2: Moved to prior interrupt handler installation and RMW flags as per feedback. v2->v3: Removed RMW of flags (by anholt) Cc: stable@kernel.org Signed-off-by: Daniel J Blueman <daniel.blueman@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> [v1] Tested-by: Eric Anholt <eric@anholt.net> [v1,v3] (incidence of the bug with a testcase went from avg 2/1000 to 0/12651 in the latest test run (plus more for v1)) Tested-by: Kenneth Graunke <kenneth@whitecape.org> [v1] Tested-by: Robert Hooker <robert.hooker@canonical.com> [v1] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33394 Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
f6b07f45 |
|
24-May-2011 |
Dan Carpenter <error27@gmail.com> |
drm/i915: fix if statement in ivybridge irq handler The extra semicolon was not intended. Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
9e3c256d |
|
18-May-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: initialize gen6 rps work queue on Sandy Bridge and Ivy Bridge It's not used on Ironlake, but is used on later generations, so make sure it exists before we try to use it in the interrupt handlers. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
b1f14ad0 |
|
06-Apr-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: interrupt & vblank support for Ivy Bridge Add new interrupt handling functions for Ivy Bridge. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
f796cf8f |
|
07-Apr-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: split enable/disable vblank code into chipset specific functions This makes the Ironlake+ code trivial and generally simplifies things. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
4697995b |
|
07-Apr-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: split irq handling into per-chipset functions Set the IRQ handling functions in driver load so they'll just be used directly, rather than branching over most of the code in the chipset functions. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
4912d041 |
|
25-Apr-2011 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: move gen6 rps handling to workqueue The render P-state handling code requires reading from a GT register. This means that FORCEWAKE must be written to, a resource which is shared and should be protected by struct_mutex. Hence we can not manipulate that register from within the interrupt handling and so must delegate the task to a workqueue. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
fcca7926 |
|
25-Apr-2011 |
Ben Widawsky <ben@bwidawsk.net> |
drm/i915: reference counted forcewake Provide a reference count to track the forcewake state of the GPU and give a safe mechanism for userspace to wake the GT. This also potentially saves a UC read if the GT is known to be awake already. The reference count is atomic, but the register access and hardware wake sequence is protected by struct_mutex. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
93dfb40c |
|
29-Mar-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename agp_type to cache_level ... to clarify just how we use it inside the driver and remove the confusion of the poorly matching agp_type names. We still need to translate through agp_type for interface into the fake AGP driver. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
b259f673 |
|
29-Mar-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Move the irq wait queue initialisation into the ring init Required so that we don't obliterate the queue if initialising the rings after the global IRQ handler is installed. [Jesse, you recently looked at refactoring the IRQ installation routines, does moving the initialisation of ring buffer data structures away from that routine make sense in your grand scheme?] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
8692d00e |
|
05-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#" I stumbled over this magic bit in the gen3 INSTPM: Bit11 Interrupt-Based AGPBUSY# Enable: ‘0’ = Pending GMCH interrupts will not cause AGPBUSY# assertion. ‘1’ = Pending GMCH interrupts will cause AGPBUSY# assertion and hence can cause the CPU to exit C3. There is no suppression of cacheable writes. Note that in either case in C3 the interrupts are not lost. They will be forwarded to the ICH when the GMCH is out of C3. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@kernel.org
|
#
60c8bdf6 |
|
05-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU" Using PM latency request turns out to be very fragile and only works for some systems, depending upon the ACPI implementation. However, I've stumbled across a promising bit in INSTPM: "Interrupt-Based AGPBUSY#". This reverts commit b0b544cd37c060e261afb2cf486296983fcb56da. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
5d9faa16 |
|
01-Mar-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Silence an innocuous compiler warning for an unused variable drivers/gpu/drm/i915/i915_irq.c: In function ‘ironlake_irq_postinstall’: drivers/gpu/drm/i915/i915_irq.c:1618: warning: unused variable ‘pipe’ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a36dbec5 |
|
11-Feb-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: don't enable FDI & transcoder interrupts after all We can enable some safely, but FDI and transcoder interrupts can occur and block other interrupts from being detected (like port hotplug events). So keep them disabled by default (they can be re-enabled for debugging display bringup, but should generally be off). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e67189ab |
|
11-Feb-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: don't enable FDI & transcoder interrupts after all We can enable some safely, but FDI and transcoder interrupts can occur and block other interrupts from being detected (like port hotplug events). So keep them disabled by default (they can be re-enabled for debugging display bringup, but should generally be off). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
9db4a9c7 |
|
07-Feb-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: cleanup per-pipe reg usage We had some conversions over to the _PIPE macros, but didn't get everything. So hide the per-pipe regs with an _ (still used in a few places for legacy) and add a few _PIPE based macros, then make sure everyone uses them. [update: remove usage of non-existent no-op macro] [update 2: keep modesetting suspend/resume code, update to new reg names] Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [ickle: stylistic cleanups for checkpatch and taste] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
db53a302 |
|
03-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Refine tracepoints A lot of minor tweaks to fix the tracepoints, improve the outputting for ftrace, and to generally make the tracepoints useful again. It is a start and enough to begin identifying performance issues and gaps in our coverage. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b6f7833b |
|
01-Feb-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Include 'i915_error_state' hint for when the GPU catches fire Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
78c6e170 |
|
31-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Suppress spurious vblank interrupts Hugh Dickins found that characters in xterm were going missing and oft delayed. Being the curious type, he managed to associate this with the new high-precision vblank patches; disabling these he found, restored the orderliness of his characters. The oddness begins when one realised that Hugh was not using vblanks at all on his system (fvwm and some xterms). Instead, all he had to go on were warning of a pipe underrun, curiously enough at around 60Hz. He poked and found that in addition to the underrun warning, the hardware was flagging the start of a new frame, a vblank, which in turn was kicking off the pending vblank processing code. There is little we can do for the underruns on Hugh's machine, a Crestline [965GM], which must have its FIFO watermarks set to 8. However, we do not need to process the vblank if we know that they are disabled... Reported-by: Hugh Dickins <hughd@google.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e2f973d5 |
|
27-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record all error ringbuffers Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
8e934dbf |
|
23-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Prevent uninitialised reads during error state capture error_bo and pinned_bo could be used uninitialised if there were no active buffers. Caught by kmemcheck. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
5a9a8d1a |
|
23-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Handle the no-interrupts case for UMS by polling If the driver calls into the kernel to wait for a breadcrumb to pass, but hasn't enabled interrupts, fallback to polling the breadcrumb value. Reported-by: Chris Clayton <chris2553@googlemail.com> Tested-by: Chris Clayton <chris2553@googlemail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
4041b853 |
|
22-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Increase the amount of defense before computing vblank timestamps Reported-by: Chris Clayton <chris2553@googlemail.com> Tested-by: Chris Clayton <chris2553@googlemail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a37f2f87 |
|
22-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove unused code: i915_enable_interrupt() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
475553de |
|
20-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Don't kick-off hangcheck after a DRI interrupt Hangcheck and error recovery is only used by GEM. Reported-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b0b544cd |
|
08-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU 945 class hardware has an interesting quirk in which the vblank interrupt is not raised if the CPU is in a low power state. (We also suspect that the memory bus is clocked to the CPU/c-state and not the GPU so there are secondary starvation issues.) In order to prevent the most obvious issue of the low of the vblank interrupt (stuttering compositing that only updates when the mouse is moving) is to install a PM QoS request to prevent low c-states whilst the GPU is active. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c37d9a5d |
|
12-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Fix error handler to capture the first batch after the seqno Whilst we had no older batches on the active list, everything was fine. However, if the GPU is free running and the requests are only being reaped by the periodic retirer, than the current seqno may not be at the start of the list. In this case we need to select the first batch after the last seqno written by the gpu and not inclusive of the seqno. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a779e5ab |
|
09-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record AGP memory type upon error Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
bcfb2e28 |
|
07-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record the error batchbuffer on each ring Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
776ad806 |
|
04-Jan-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: detect & report PCH display error interrupts FDI and the transcoders can fail for various reasons, so detect those conditions and report on them. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
9862e600 |
|
04-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/debugfs: Show the per-ring IMR Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
0f46832f |
|
04-Jan-2011 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Mask USER interrupts on gen6 (until required) Otherwise we may consume 20% of the CPU just handling IRQs whilst rendering. Ouch. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3b8d8d91 |
|
17-Dec-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: dynamic render p-state support for Sandy Bridge Add an interrupt handler for switching graphics frequencies and handling PM interrupts. This should allow for increased performance when busy and lower power consumption when idle. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
0af7e4df |
|
07-Dec-2010 |
Mario Kleiner <mario.kleiner@tuebingen.mpg.de> |
drm/i915: Add support for precise vblank timestamping (v2) v2: Change IS_IRONLAKE to IS_GEN5 to adapt to 2.6.37 This patch adds new functions for use by the drm core: .get_vblank_timestamp() provides a precise timestamp for the end of the most recent (or current) vblank interval of a given crtc, as needed for the DRI2 implementation of the OML_sync_control extension. It is a thin wrapper around the drm function drm_calc_vbltimestamp_from_scanoutpos() which does almost all the work. .get_scanout_position() provides the current horizontal and vertical video scanout position and "in vblank" status of a given crtc, as needed by the drm for use by drm_calc_vbltimestamp_from_scanoutpos(). The patch modifies the pageflip completion routine to use these precise vblank timestamps as the timestamps for pageflip completion events. This code has been only tested on a HP-Mini Netbook with Atom processor and Intel 945GME gpu. The codepath for (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) gpu's has not been tested so far due to lack of hardware. Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c6df541c |
|
15-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
Revert "drm/i915: Avoid using PIPE_CONTROL on Ironlake" Restore PIPE_CONTROL once again just for Ironlake, as it appears that MI_USER_INTERRUPT does not have the same coherency guarantees, that is on Ironlake the interrupt following a GPU write is not guaranteed to arrive after the write is coherent from the CPU, as it does on the other generations. Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com> Reported-by: Shuang He <shuang.he@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32402 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b13c2b96 |
|
13-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/ringbuffer: Make IRQ refcnting atomic In order to enforce the correct memory barriers for irq get/put, we need to perform the actual counting using atomic operations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
88f23b8f |
|
05-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid using PIPE_CONTROL on Ironlake The workaround is hideous and we are using the STORE_DWORD on all other generations on all other rings, so use for the gen5 render ring as well. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
1ec14ad3 |
|
04-Dec-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Implement GPU semaphores for inter-ring synchronisation on SNB The bulk of the change is to convert the growing list of rings into an array so that the relationship between the rings and the semaphore sync registers can be easily computed. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
ab5793ad |
|
22-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Tweak on-error bbaddr parsing for clarity Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
748ebc60 |
|
24-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record fence registers on error. Having seen the effects of erroneous fencing on the batchbuffer, a useful sanity check is to record the fence registers at the time of an error. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
05394f39 |
|
08-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use drm_i915_gem_object as the preferred type A glorified s/obj_priv/obj/ with a net reduction of over a 100 lines and many characters! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3685092b |
|
23-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Avoid oops when capturing NULL ring for inactive pinned buffers Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c4a1d9e4 |
|
21-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Capture interesting display registers on error When trying to diagnose mysterious errors on resume, capture the display register contents as well. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c724e8a9 |
|
22-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Capture pinned buffers on error The pinned buffers are useful for diagnosing errors in setting up state for the chipset, which may not necessarily be 'active' at the time of the error, e.g. the cursor buffer object. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3143a2bf |
|
16-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Convert (void)I915_READ to POSTING_READ ... and so hide the flushes from tracing. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
8168bd48 |
|
11-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove the definitions for Primary Ring Buffer We only ever used the PRB0, neglecting the secondary ring buffers, and now with the advent of multiple engines with separate ring buffers we need to excise the anachronisms from our code (and be explicit about which ring we mean where). This is doubly important in light of the FORCEWAKE required to read ring buffer registers on SandyBridge. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
527f9e90 |
|
10-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove the global irq wait queue ... as it has been replaced by per-ring waiters. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e5c65260 |
|
01-Nov-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/debugfs: Report ring in error state Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
add354dd |
|
29-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record BSD engine error state Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
1d8f38f4 |
|
29-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record BLT engine error state Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
f406839f |
|
27-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Capture ERROR register on Sandybridge hangs This holds error state from the main graphics arbiter mainly involving the DMA engine and address translation. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b2223497 |
|
27-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove the confusing global waiting/irq seqno Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
893eead0 |
|
27-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Fix hangcheck to handle multiple rings Currently, we believe the GPU is idle if just the RENDER ring is idle. This is obviously wrong if we only using either the BLT or the BSD rings and so masking genuine hangs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
e1f99ce6 |
|
26-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Propagate errors from writing to ringbuffer Preparing the ringbuffer for adding new commands can fail (a timeout whilst waiting for the GPU to catch up and free some space). So check for any potential error before overwriting HEAD with new commands, and propagate that error back to the user where possible. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
78501eac |
|
26-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915/ringbuffer: Drop the redundant dev from the vfunc interface The ringbuffer keeps a pointer to the parent device, so we can use that instead of passing around the pointer on the stack. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3e4d3af5 |
|
26-Oct-2010 |
Peter Zijlstra <a.p.zijlstra@chello.nl> |
mm: stack based kmap_atomic() Keep the current interface but ignore the KM_type and use a stack based approach. The advantage is that we get rid of crappy code like: #define __KM_PTE \ (in_nmi() ? KM_NMI_PTE : \ in_irq() ? KM_IRQ_PTE : \ KM_PTE0) and in general can stop worrying about what context we're in and what kmap slots might be appropriate for that. The downside is that FRV kmap_atomic() gets more expensive. For now we use a CPP trick suggested by Andrew: #define kmap_atomic(page, args...) __kmap_atomic(page) to avoid having to touch all kmap_atomic() users in a single patch. [ not compiled on: - mn10300: the arch doesn't actually build with highmem to begin with ] [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c] Acked-by: Rik van Riel <riel@redhat.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by: Chris Metcalf <cmetcalf@tilera.com> Cc: David Howells <dhowells@redhat.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: David Miller <davem@davemloft.net> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Dave Airlie <airlied@linux.ie> Cc: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
549f7365 |
|
19-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Enable SandyBridge blitter ring Based on an original patch by Zhenyu Wang, this initializes the BLT ring for SandyBridge and enables support for user execbuffers. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
69dc4987 |
|
19-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Track objects in global active list (as well as per-ring) To handle retirements, we need per-ring tracking of active objects. To handle evictions, we need global tracking of active objects. As we enable more rings, rebuilding the global list from the individual per-ring lists quickly grows tiresome and overly complicated. Tracking the active objects in two lists is the lesser of two evils. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
139d363b |
|
15-Oct-2010 |
Andrea Gelmini <andrea.gelmini@gelma.net> |
drivers: gpu: drm: i915: Fix a typo. "userpace" -> "userspace" Signed-off-by: Andrea Gelmini <andrea.gelmini@gelma.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
2d7b8366 |
|
08-Oct-2010 |
Yuanhan Liu <yuanhan.liu@intel.com> |
drm/i915: Update hotplug interrupts register definitions for Sandybridge On Sandybridge, the bit definition for hotplug on SDE has changed, so update the code to new definition. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30378 Cc: stable@kernel.org Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
2fa772f3 |
|
01-Oct-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only print 'generating error event' if we actually are Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
30dbf0c0 |
|
25-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Adjust hangcheck EIO semantics Owain Ainsworth reported an issue between the interaction of the hangcheck and userspace immediately (and permanently) falling back to s/w rasterisation. In order to break the mutex and begin resetting the GPU, we must abort the current operation (usually within the wait) and climb sufficiently far back up the call chain to drop the mutex. In his implementation, Owain has a loop within the ioctl handler to detect the hang and then sleep until the error handler has run. I've chosen to return to userspace and report an EAGAIN which should trigger the userspace ioctl handler to repeat the call (simply because it felt less invasive...). Before hitting a wedged GPU, we then wait upon completion of the error handler. Reported-by: Owain G. Ainsworth <zerooa@googlemail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
f787a5f5 |
|
24-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only hold a process-local lock whilst throttling. Avoid cause latencies in other clients by not taking the global struct mutex and moving the per-client request manipulation a local per-client mutex. For example, this allows a compositor to schedule a page-flip (through X) whilst an OpenGL application is monopolising the GPU. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
881f47b6 |
|
19-Sep-2010 |
Xiang, Haihao <haihao.xiang@intel.com> |
drm/i915: add a new BSD ring buffer for Sandybridge This ring buffer is used for video decoding/encoding on Sandybridge. Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
f803aa55 |
|
18-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Clean up bo lists on all hung gpus Previously we only tidied up the active bo lists for chipsets were we would attempt to reset the GPU. However, this action is necessary for the system to continue and reclaim the dead bo for all chipsets. Pointed out, in passing, by Owain Ainsworth. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
0573ed4a |
|
11-Sep-2010 |
Kenneth Graunke <kenneth@whitecape.org> |
drm/i915: Add support for GPU soft reset on Ironlake. Ironlake's graphics reset register has to be accessed via the MCHBAR, rather than via PCI config space, which requires some refactoring. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
eeccdcac |
|
11-Sep-2010 |
Kenneth Graunke <kenneth@whitecape.org> |
drm/i915: Rename graphics reset registers. The graphics domains are listed as GRDOM in the documentation, and the GDRST PCI config register (0xc0) is only valid on I965 and GM45. Newer chips (like Sandy Bridge) have a different GDRST. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
a6c45cf0 |
|
16-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: INTEL_INFO->gen supercedes i8xx, i9xx, i965g Avoid confusion between i965g meaning broadwater and the gen4+ chipset families. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
b3b079db |
|
13-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Reduce hangcheck frequency By reducing the hangcheck frequency we check less often, conserving resources, and still detect a lock up quickly. On a fast machine with a slow GPU (like a Core2 paired with a 945G) it is easy for the hangcheck to misfire as we check too fast. Also once hung and if we fail to completely reset the chip, we have a nasty habit of proclaming a hang many times a second and generating a strobe-like display. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
5eddb70b |
|
11-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Use macros to switch between equivalent pipe registers The purpose is to make the code much easier to read and therefore reduce the possibility for bugs. A side effect is that it also makes it much easier for the compiler, reducing the object size by 4k -- from just a few functions! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
4ef69c7a |
|
09-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename intel_encoder->enc to base for consistency [Patch is slightly larger than is strictly necessary to fixup surrounding checkpatch.pl errors.] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
7839d956 |
|
08-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Double check that the wait_request is not pending before warning If we are busy, then we may have woken up the wait_request handler but not yet serviced it before the hang check fires. So in hang check, double check that the i915_gem_do_wait_request() is still pending the wake-up before declaring all hope lost. Fixes regression with e78d73b16bcde921c9cf458d2e4de8e4fc2518f3. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30073 Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
8c80b59b |
|
08-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Add ringbuffer wait reset to hangcheck The GPU records whether it is currently waiting for a completion of a WAIT_FOR_EVENT in the RB_WAIT bit in the ringbuffer control registers. On third generation chipsets and later, a write of 1 to this bit breaks the hang and returns the GPU to arbitration, i.e. the GPU should continue executing the reminder of the batchbuffer and return to normal operations. By adding this to hangcheck we can avoid a full GPU reset under these conditions. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
995b6762 |
|
20-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Quieten sparse warnings for missing prototypes. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3bd3c932 |
|
19-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Compile out error state without DEBUG_FS Alexander reported that the compilation of intel_overlay.c was failing due to an inclusion that was only valid with CONFIG_DEBUG_FS. As the whole error reporting is only useful with debugfs enabled, remove all the redundant error state collection code when compiling without CONFIG_DEBUG_FS. Reported-by: Alexander Lam <lambchop468@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
2bbda389 |
|
02-Sep-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Ironlake page-flipping is per-plane not per-pipe Fix a minor confusion between intel_page_flip_finish(pipe) and intel_page_flip_finish_plane(plane) -- should have no effect as currently we map pipe 0 to plane 0 (and pipe 1 to plane 1). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3b617967 |
|
24-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Rename i915_opregion.c to intel_opregion.c It's part of the generic Intel driver infrastructure so rename it in prepreparation for using it for VBT. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
4e5359cd |
|
01-Sep-2010 |
Simon Farnsworth <simon.farnsworth@onelan.co.uk> |
drm/i915: Avoid pageflipping freeze when we miss the flip prepare interrupt When we miss the flip prepare interrupt, we never get into the software state needed to restart userspace, resulting in a freeze of a full-screen OpenGL application (such as a compositor). Work around this by checking DSPxSURF/DSPxBASE to see if the page flip has actually happened. If it has, do the work we would have done when the flip prepare interrupt comes in. Also, add debugfs information to tell us what's going on (based on the patch from Chris Wilson attached to bugs.fdo bug #29798). Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
3fdef020 |
|
18-Aug-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm/i915: fix render pipe control notify on sandybridge This one is missed in last pipe control fix for sandybridge, that really unmask interrupt bit for notify in render engine IMR. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
e78d73b1 |
|
07-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Wake-up wait_request() from elapsed hang-check (v2) If our watchdog fires and we see that the GPU is idle, but that we are still waiting on an interrupt, forcibly wake-up the waiter. i915_do_wait_request() should not be racy, yet there are persistent reports that 945GM hangs whilst the GPU is idle. This implies that the hardware is not quite as coherent as the documentation claims - a write followed by a flush is supposed to be coherent in main memory before the flush is retired and the irq is emitted. This seems to be a sensible and elegant guard to force the wait to timeout. v2: Daniel Vetter pointed out that a warning would be useful to explain why the machine appeared to stall. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
e56660dd |
|
07-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record error batch buffers using iomem Directly read the GTT mapping for the contents of the batch buffers rather than relying on possibly stale CPU caches. Also for completeness scan the flushing/inactive lists for the current buffers - we are collecting error state after all. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
6ef3d427 |
|
04-Aug-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Capture the overlay status upon a GPU hang. v2: Add the interrupt status and address. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
cbb465e7 |
|
05-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Include instdone[1] in hangcheck References: Bug 26691 - Spurious hangcheck whilst executing a long shader over a large vertex buffer https://bugs.freedesktop.org/show_bug.cgi?id=26691 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
d874bcff |
|
30-Jun-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: remove duplicate PIPE*STAT bit definitions Having two sets has made me think I caught a bug more than once now. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
e25e6601 |
|
30-Jun-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: remove unused vblank_enable var from i915_driver_irq_handler Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
70565d00 |
|
01-Jul-2010 |
Jesse Barnes <jbarnes@jbarnes-acer.localdomain> |
drm/i915: fix page flip finish vs. prepare on plane B The refreshed patch had a copy & paste bug. Reported-by: Simon Farnsworth <simon.farnsworth@onelan.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
2d1c9752 |
|
12-Jun-2010 |
Andy Lutomirski <luto@MIT.EDU> |
drm/i915: Fix CRT hotplug regression in 2.6.35-rc1 Commit 7a772c492fcfffae812ffca78a628e76fa57fe58 has two bugs which made the hotplug problems on my laptop worse instead of better. First, it did not, in fact, disable the CRT plug interrupt -- it disabled all the other hotplug interrupts. It seems rather doubtful that that bit of the patch fixed anything, so let's just remove it. (If you want to add it back, you probably meant ~CRT_HOTPLUG_INT_EN.) Second, on at least my GM45, setting CRT_HOTPLUG_ACTIVATION_PERIOD_64 and CRT_HOTPLUG_VOLTAGE_COMPARE_50 (when they were previously unset) causes a hotplug interrupt about three seconds later. The old code never restored PORT_HOTPLUG_EN so this could only happen once, but they new code restores those registers. So just set those bits when we set up the interrupt in the first place. Signed-off-by: Andy Lutomirski <luto@mit.edu> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
1afe3e9d |
|
26-Mar-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: gen3 page flipping fixes Gen3 chips have slightly different flip commands, and also contain a bit that indicates whether a "flip pending" interrupt means the flip has been queued or has been completed. So implement support for the gen3 flip command, and make sure we use the flip pending interrupt correctly depending on the value of ECOSKPD bit 0. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
c496fa1f |
|
27-May-2010 |
Adam Jackson <ajax@redhat.com> |
drm/i915/gen4: Fix interrupt setup ordering Unmask, then enable interrupts, then enable interrupt sources; matches PCH ordering. The old way (sources, enable, unmask) gives a window during which interrupt conditions would appear in ISR but would never reach IIR and thus never raise an IRQ. Since interrupts only trigger on rising edges in ISR, this would lead to conditions where (for example) output hotplugging would never fire an interrupt because it was already stuck on in ISR. Also, since we know IIR and PIPExSTAT have been cleared during irq_preinstall, don't clear them again during irq_postinstall, nothing good can come of that. Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
35aed2e6 |
|
27-May-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Only print an message if there was an error Only report an error if the GPU has actually detected one, otherwise we are just hung. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
7648fa99 |
|
20-May-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: add power monitoring support Add power monitoring support to the i915 driver for use by the IPS driver. Export the available power info to the IPS driver through a few new inter-driver hooks. When used together, the IPS driver and this patch can significantly increase graphics performance on Ironlake class chips. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: Fixed 32-bit compile. stupid obfuscating div_u64()] Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
d1b851fc |
|
20-May-2010 |
Zou Nan hai <nanhai.zou@intel.com> |
drm/i915: implement BSD ring buffer V2 The BSD (bit stream decoder) ring is used for accessing the BSD engine which decodes video bitstream for H.264 and VC1 on G45+. It is asynchronous with the render ring and has access to separate parts of the GPU from it, though the render cache is coherent between the two. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Xiang Hai hao <haihao.xiang@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
852835f3 |
|
20-May-2010 |
Zou Nan hai <nanhai.zou@intel.com> |
drm/i915: convert some gem structures to per-ring V2 The active list and request list move into the ringbuffer structure, so each can track its active objects in the order they are in that ring. The flushing list does not, as it doesn't matter which ring caused data to end up in the render cache. Objects gain a pointer to the ring they are active on (if any). Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Xiang Hai hao <haihao.xiang@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
8187a2b7 |
|
20-May-2010 |
Zou Nan hai <nanhai.zou@intel.com> |
drm/i915: introduce intel_ring_buffer structure (V2) Introduces a more complete intel_ring_buffer structure with callbacks for setup and management of a particular ringbuffer, and converts the render ring buffer consumers to use it. Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Xiang Hai hao <haihao.xiang@intel.com> [anholt: Fixed up whitespace fail and rebased against prep patches] Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
d3301d86 |
|
21-May-2010 |
Eric Anholt <eric@anholt.net> |
drm/i915: Rename dev_priv->ring to dev_priv->render_ring. With the advent of the BSD ring, be clear about which ring this is. The docs are pretty consistent with calling this the Render engine at this point.
|
#
62fdfeaf |
|
21-May-2010 |
Eric Anholt <eric@anholt.net> |
drm/i915: Move ringbuffer-related code to intel_ringbuffer.c. This is preparation for supporting multiple ringbuffers on Ironlake. The non-copy-and-paste changes are: - de-staticing functions - I915_GEM_GPU_DOMAINS moving to i915_drv.h to be used by both files. - i915_gem_add_request had only half its implementation copy-and-pasted out of the middle of it.
|
#
eb1f8e4f |
|
07-May-2010 |
Dave Airlie <airlied@redhat.com> |
drm/fbdev: rework output polling to be back in the core. (v4) After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls v4: config lock was a bit agressive, only needed around connector list reading. otherwise it could re-enter. glisse: discard drm_helper_hpd_irq_event v3: Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
788885ae |
|
11-May-2010 |
Andrew Morton <akpm@linux-foundation.org> |
drivers/gpu/drm/i915/i915_irq.c:i915_error_object_create(): use correct kmap-atomic slot i915_error_object_create() is called from the timer interrupt and hence can corrupt the KM_USER0 slot. Use KM_IRQ0 instead. Reported-by: Jaswinder Singh Rajput <jaswinderlinux@gmail.com> Tested-by: Jaswinder Singh Rajput <jaswinderlinux@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
e552eb70 |
|
21-Apr-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: use PIPE_CONTROL instruction on Ironlake and Sandy Bridge Since 965, the hardware has supported the PIPE_CONTROL command, which provides fine grained GPU cache flushing control. On recent chipsets, this instruction is required for reliable interrupt and sequence number reporting in the driver. So add support for this instruction, including workarounds, on Ironlake and Sandy Bridge hardware. https://bugs.freedesktop.org/show_bug.cgi?id=27108 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
a8089e84 |
|
09-Apr-2010 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: drop pointer to drm_gem_object Luckily the change is quite a little bit less invasive than I've feared. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
edcb49ca |
|
07-Apr-2010 |
Zhao Yakui <yakui.zhao@intel.com> |
drm/i915: Fix legacy BLC event for pipe A OpRegion event on 965G requires legacy BLC event enabled in pipe stat. As LVDS could be on either pipe now, we should enable BLC event on both pipe. If fail to do so, we couldn't handle the brightness request triggered from graphics opregion. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
5bf4c9c4 |
|
30-Mar-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm/i915: use encoder_list for hotplug callback Instead of walking through drm connector_list uses encoder_list for calling hotplug functions which is consistent with intel display hotplug reporting. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
4abe3520 |
|
29-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: use slow work mechanism for normal hotplug also. a) slow work is always used now for any fbcon hotplug, as its not a fast task and is more suited to being ran under slow work. b) attempt to not do any fbdev changes when X is running as we'll just mess it up. This hooks set_par to hopefully do the changes once X hands control to fbdev. This also adds the nouveau/intel hotplug support. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
5a0e3ad6 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
|
#
21d40d37 |
|
25-Mar-2010 |
Eric Anholt <eric@anholt.net> |
drm/i915: Rename intel_output to intel_encoder. The intel_output naming is inherited from the UMS code, which had a structure of screen -> CRTC -> output. The DRM code has an additional notion of encoder/connector, so the structure is screen -> CRTC -> encoder -> connector. This is a useful structure for SDVO encoders which can support multiple connectors (each of which requires different programming in the one encoder and could be connected to different CRTCs), or for DVI-I, where multiple encoders feed into the connector for whether it's used for digital or analog. Most of our code is encoder-related, so transition it to talking about encoders before we start trying to distinguish connectors. This patch is produced by sed s/intel_output/intel_encoder/ over the driver. Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
23010e43 |
|
08-Mar-2010 |
Daniel Vetter <daniel.vetter@ffwll.ch> |
drm/i915: introduce to_intel_bo helper This is a purely cosmetic change to make changes in this area easier. And hey, it's not only clearer and typechecked, but actually shorter, too! [anholt: To clarify, this is a change to let us later make drm_i915_gem_object subclass drm_gem_object, instead of having drm_gem_object have a pointer to i915's private data] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
c619eed4 |
|
28-Jan-2010 |
Eric Anholt <eric@anholt.net> |
drm/i915: More s/IS_IRONLAKE/HAS_PCH_SPLIT for Sandybridge. I think this is pretty much correct. Not really tested. Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
b9201c14 |
|
08-Jan-2010 |
Eric Anholt <eric@anholt.net> |
drm/i915: Disable the hangcheck reset on Sandybridge until we add support. Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
bad720ff |
|
22-Oct-2009 |
Eric Anholt <eric@anholt.net> |
drm/i915: Add initial bits for VGA modesetting bringup on Sandybridge. Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
9df30794 |
|
18-Feb-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Record batch buffer following GPU error In order to improve our diagnostic capabilities following a GPU hang and subsequent reset, we need to record the batch buffer that triggered the error. We assume that the current batch buffer, plus a few details about what else is on the active list, will be sufficient -- at the very least an improvement over nothing. The extra information is stored in /debug/dri/.../i915_error_state following an error, and may be decoded using intel_gpu_tools/tools/intel_error_decode. v2: Avoid excessive work under spinlocks. v3: Include ringbuffer for later analysis. v4: Use kunmap correctly and record more buffer state. v5: Search ringbuffer for current batch buffer v6: Use a work fn for the impossible IRQ error case. v7: Avoid non-atomic paths whilst in IRQ context. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
b5b72e89 |
|
02-Feb-2010 |
Matthew Garrett <mjg59@srcf.ucam.org> |
drm/i915: Deobfuscate the render p-state obfuscation The ironlake render p-state support includes some rather odd variable names. Clean them up in order to improve the readability of the code. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
f97108d1 |
|
29-Jan-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: add dynamic performance control support for Ironlake Ironlake (and 965GM, which this patch doesn't support) supports a hardware performance and power management feature that allows it to adjust to changes in GPU load over time with software help. The goal if this is to maximize performance/power for a given workload. This patch enables that feature, which is also a requirement for supporting Intelligent Power Sharing, a feature which allows for dynamic budgeting of power between the CPU and GPU in Arrandale platforms. Tested-by: ykzhao <yakui.zhao@intel.com> [anholt: Resolved against the irq handler loop removal] Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
f072d2e7 |
|
08-Feb-2010 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm/i915: fix flip done interrupt on Ironlake On Ironlake plane flip interrupt means flip done event already, the behavior is not like old chips, and perform like other usual interrupt. So only need to handle flip done event when receiving that interrupt. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
013d5aa2 |
|
29-Jan-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: page flip support for Ironlake This patch adds support for page flipping on Ironlake, which uses different interrupt bits for triggering flip submit IRQs. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: hand-resolved for rebasing off of render power saving patch] Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
643ced9b |
|
27-Jan-2010 |
Li Peng <peng.li@linux.intel.com> |
drm/i915: don't trigger ironlake vblank interrupt at irq install Zhenyu noticed that the ironlake vblank enabling patch has one issue that it will trigger vblank starting from irq postinstall, this isn't necessary. This patch addresses this issue by only adding the vblank into DEIER but mask them in DEIMR, so that it won't trigger vblank interrupt at irq install. Signed-off-by: Li Peng <peng.li@intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
c062df61 |
|
22-Jan-2010 |
Li Peng <peng.li@linux.intel.com> |
drm/i915: enable vblank interrupt on ironlake so far vblank interrupt on ironlake is disabled, this would cause bad gfx performance if userspace calls drm_wait_vblank. This patch enables vblank interrupt on ironlake and follows vblank get/put model. Signed-off-by: Li Peng <peng.li@intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
c7c85101 |
|
14-Jan-2010 |
Zou Nan hai <Nanhai.zou@intel.com> |
drm/i915: remove loop in Ironlake interrupt handler On Ironlake, there is an interrupt master control bit. With the bit disabled before clearing IIR, we do not need to handle extra interrupt in a loop. This patch removes the loop in Ironlake interrupt handler. It fixed irq lost issue on some Ironlake platforms. Cc: Stable Team <stable@kernel.org> Signed-off-by: Zou Nan hai <Nanhai.zou@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
c566ec49 |
|
17-Dec-2009 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm/i915: Reload hangcheck timer too for Ironlake Make sure hangcheck timer won't beat us unexpectedly on Ironlake. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
b01f2c3a |
|
11-Dec-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: only enable hotplug for detected outputs This patch changes around our hotplug enable code a bit to only enable it for ports we actually detect and initialize. This prevents problems with stuck or spurious interrupts on outputs that aren't actually wired up, and is generally more correct. Fixes FDO bug #23183. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
4f8d619c |
|
08-Dec-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Remove a debugging printk from hangcheck A residual bare printk survived the merger of the hang detector, remove this debugging left-over. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
f2b115e6 |
|
03-Dec-2009 |
Adam Jackson <ajax@redhat.com> |
drm/i915: Fix product names and #defines IGD* isn't a useful name. Replace with the codenames, as sourced from pci.ids. Signed-off-by: Adam Jackson <ajax@redhat.com> [anholt: Fixed up for merge with pineview/ironlake changes] Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
6b95a207 |
|
18-Nov-2009 |
Kristian Høgsberg <krh@bitplanet.net> |
drm/i915: Add intel implementation of the pageflip ioctl Acked-by: Jakob Bornecrantz <jakob@vmware.com> Acked-by: Thomas Hellström <thomas@shipmail.org> Review-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jesse "Orange Smoothie" Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Kristian Høgsberg <krh@bitplanet.net> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
26444877 |
|
14-Oct-2009 |
Shaohua Li <shaohua.li@intel.com> |
drm/i915: remove Pineview EOS protection support HW guys have an evaluation about the impact about EOS, and say the impact is quite small, so they have removed EOS detection support. This patch removes EOS feature. revert commit 043029655816ed4cfc2ed247020ef97e5d637392 directly reverting it gives a hunk error, so please use this one. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net> [anholt: fixed up commit message for update that the feature's really gone]
|
#
2d109a84 |
|
05-Nov-2009 |
Zou, Nanhai <nanhai.zou@intel.com> |
drm/i915: Fix IRQ stall issue on Ironlake The master irq control in DE must be disabled before irq handling, and enable after the process. This fixes the irq stall issue on Ironlake. Cc: Stable Team <stable@kernel.org> Signed-off-by: Zou, Nanhai <nanhai.zou@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
c650156a |
|
03-Nov-2009 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm/i915: Add display hotplug event on Ironlake Enable display hotplug irqs from Ibex Peak (PCH). Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
01c66889 |
|
27-Oct-2009 |
Zhao Yakui <yakui.zhao@intel.com> |
drm/i915: Add ACPI OpRegion support for Ironlake Add the support of ACPI opregion on Ironlake so that the backlight brightness can be adjusted by using ACPI interface >/sys/class/backlight/acpi_video0/brightness Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Tested-by: Zhao Yakui <yakui.zhao@intel.com> [zhenyuw: cleanups, fix typo for checking GSE irq and convert to current irq handling logic.] Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
44d98a61 |
|
08-Oct-2009 |
Zhao Yakui <yakui.zhao@intel.com> |
drm/i915: Replace DRM_DEBUG with DRM_DEBUG_DRIVER Replace the DRM_DEBUG with DRM_DEBUG_DRIVER in generic i915 driver. Then the debug info can be obtained by adding the boot option of "drm.debug=0x02". At the same time the debug info in increase/decrease clock is also printed by using DRM_DEBUG_DRIVER instead of DRM_DEBUG_KMS. Signed-off-by: Zhao Yakui <yakui.zhao@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
9d34e5db |
|
23-Sep-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Enable irq to trace batch buffer completion. If we trigger a tracepoint for batch buffer submission, it is a reasonable assumption that we wish to also trace the batch buffer completion. So in order to capture the completion events, we need to enable irqs... However, we cannot rely on the completion event to disable the irq later, so we defer the irq disable to the retire request. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
1c5d22f7 |
|
25-Aug-2009 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/i915: Add tracepoints By adding tracepoint equivalents for WATCH_BUF/EXEC we are able to monitor the lifetimes of objects, requests and significant events. These events can then be probed using the tracing frameworks, such as systemtap and, in particular, perf. For example to record the stack trace for every GPU stall during a run, use $ perf record -e i915:i915_gem_request_wait_begin -c 1 -g And $ perf report to view the results. [Updated to fix compilation issues caused.] Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Ben Gamari <bgamari@gmail.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
ba1234d1 |
|
14-Sep-2009 |
Ben Gamari <bgamari.foss@gmail.com> |
drm/i915: Make dev_priv->mm.wedged an atomic_t There is a very real possibility that multiple CPUs will notice that the GPU is wedged. This introduces all sorts of potential race conditions. Make the wedged flag atomic to mitigate this risk. Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f316a42c |
|
14-Sep-2009 |
Ben Gamari <bgamari.foss@gmail.com> |
drm/i915: Hookup chip reset in error handler This patch uses the previously introduced chip reset logic to reset the chip when an error event is detected. Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
11ed50ec |
|
14-Sep-2009 |
Ben Gamari <bgamari.foss@gmail.com> |
drm/i915: Implement GPU reset on i965 This patch puts in place the machinery to attempt to reset the GPU. This will be used when attempting to recover from a GPU hang. Signed-off-by: Owain G. Ainsworth <oga@openbsd.org> Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
f65d9421 |
|
14-Sep-2009 |
Ben Gamari <bgamari.foss@gmail.com> |
drm/i915: Add hangcheck timer We set a periodic timer to check on the GPU, resetting it every time a batch is completed. If the timer elapses, we check acthd. If acthd hasn't changed in two timer periods, we assume the chip is wedged. This is implemented in such a way that it leaves the option open to employ adaptive timer intervals in the future. One could wait until several timer periods have elapsed before declaring the chip dead. If the chip comes back after several periods but before the "dead" threshold, the timer interval or dead threshold could be raised. It is important to note that while checking for active requests, we need to account for the fact that requests are removed from the list (i.e. retired) in a deferred work queue handler. This means that merely checking for an empty request_list is insufficient; the list could be non-empty yet the GPU still idle, causing the hangcheck timer to incorrectly mark the GPU as wedged (it took me a while to figure that out---sigh...) Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
#
04302965 |
|
23-Aug-2009 |
Shaohua Li <shaohua.li@intel.com> |
drm/i915: Support IGD EOS In the event that any one of the DAC analog outputs (R,G,B) were driven at full-scale (white video) or some analog level close to full-scale voltage, and if the video cable were then disconnected, the analog video voltage level would exceed the maximum electrical overstress limit of the native (thin-oxide) transistors thus causing a long-term reliability concern. The electrical overstress condition occurs in this particular case. This patch address the IGD EOS (electrical overstress condition) issue. When the EOS interrupt occurs, OS should disable DAC and then disable EOS, then the normal hotplug operation follows. TODO: it appears the normal unplug interrupt is missed as reported by Li Peng, need more checks here. Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
6cb504c2 |
|
08-Aug-2009 |
Frans Pop <elendil@planet.nl> |
drm/i915: silence vblank warnings these errors are pretty pointless Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
9c9fe1f8 |
|
03-Aug-2009 |
Eric Anholt <eric@anholt.net> |
drm/i915: Use our own workqueue to avoid wedging the system along with the GPU. Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
8a905236 |
|
11-Jul-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: refactor error detection & collection This patch refactors the existing error detection and collection code, placing most of it in i915_handle_error(). Additionally, we introduce a work queue for scheduling post-crash tasks such as generating a uevent. Using the uevent facility, userspace should be able to capture a post-mortem dump for diagnostics. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
7662c8bd |
|
25-Jun-2009 |
Shaohua Li <shaohua.li@intel.com> |
drm/i915: add FIFO watermark support This patch from jbarnes and myself adds FIFO watermark control to the driver. This is needed for both power saving features on new platforms with the so-called "big FIFO" and for controlling FIFO allocation between pipes in multi-head configurations. It's also necessary infrastructure to support things like framebuffer compression and configuration supportability checks (i.e. checking a configuration against available bandwidth). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
63eeaf38 |
|
18-Jun-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: enable error detection & state collection This patch enables error detection by enabling several types of error interrupts. When an error interrupt is received, the interrupt handler captures the error state; hopefully resulting in an accurate set of error data (error type, active head pointer, etc.). The new record is then available from sysfs. The current code will also dump the error state to the system log. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
c31c4ba3 |
|
06-May-2009 |
Keith Packard <keithp@keithp.com> |
drm/i915: add per-output hotplug callback for KMS This allows each output to deal with plug/unplug events as needed. Signed-off-by: Keith Packard <keithp@keithp.com>
|
#
036a4a7d |
|
08-Jun-2009 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm/i915: handle interrupt on new chipset Update interrupt handling methods for IGDNG with new registers for display and graphics interrupt functions. As we won't use irq-based vblank sync in dri2, so display interrupt on new chip will be used for hotplug only in future. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
42c2798b |
|
05-May-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: apply G45 vblank count code to all G4x chips and fix max_frame_count All G4x and newer chips use the new style frame count register, with a full 32 bit frame count. Update the code to reflect this. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
e170b030 |
|
05-Jun-2009 |
Zhenyu Wang <zhenyuw@linux.intel.com> |
drm/i915: Disable opregion on IGDNG for now Disable OpRegion support for now until verified on new chipsets. Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
07f4f8bf |
|
16-Apr-2009 |
Eric Anholt <eric@anholt.net> |
drm/i915: Don't let an oops get triggered from irq_emit without dma init. Userland is broken if it's trying this, but we also shouldn't allow oopses. Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
5ca58282 |
|
31-Mar-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: add VGA hotplug support for 945+ Add VGA port hotplug detection to the i915 driver. When KMS is enabled, plugging in or removing a VGA cable from the VGA connector will generate a uevent, which indicates to userspace that it should re-probe outputs on this device (to determine modes, etc.). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: dropped extra PORT_HOTPLUG_STAT clear with ack from jbarnes] Signed-off-by: Eric Anholt <eric@anholt.net>
|
#
299eb93c |
|
24-Feb-2009 |
Eric Anholt <eric@anholt.net> |
drm/i915: Fix use-before-null-check in i915_irq_emit(). This could be triggered by a client asking to emit an irq when the device wasn't initialized. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
|
#
9880b7a5 |
|
06-Feb-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: add get_vblank_counter function for GM45 As discussed in the long thread about vblank related timeouts, it turns out GM45 has different frame count registers than previous chips. This patch adds support for them, which prevents us from waiting on really stale sequence values in drm_wait_vblank (which rather than returning immediately ends up timing out or getting interrupted). Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
|
#
71e0ffa5 |
|
08-Jan-2009 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm/i915: don't enable vblanks on disabled pipes In some cases userland may be confused and try to wait on vblank events from pipes that aren't actually enabled. We shouldn't allow this, so return -EINVAL if the pipe isn't on. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
|
#
79e53945 |
|
07-Nov-2008 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
DRM: i915: add mode setting support This commit adds i915 driver support for the DRM mode setting APIs. Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are supported. HDMI, DisplayPort and additional SDVO output support will follow. Support for the mode setting code is controlled by the new 'modeset' module option. A new config option, CONFIG_DRM_I915_KMS controls the default behavior, and whether a PCI ID list is built into the module for use by user level module utilities. Note that if mode setting is enabled, user level drivers that access display registers directly or that don't use the kernel graphics memory manager will likely corrupt kernel graphics memory, disrupt output configuration (possibly leading to hangs and/or blank displays), and prevent panic/oops messages from appearing. So use caution when enabling this code; be sure your user level code supports the new interfaces. A new SysRq key, 'g', provides emergency support for switching back to the kernel's framebuffer console; which is useful for testing. Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
7c1c2871 |
|
27-Nov-2008 |
Dave Airlie <airlied@redhat.com> |
drm: move to kref per-master structures. This is step one towards having multiple masters sharing a drm device in order to get fast-user-switching to work. It splits out the information associated with the drm master into a separate kref counted structure, and allocates this when a master opens the device node. It also allows the current master to abdicate (say while VT switched), and a new master to take over the hardware. It moves the Intel and radeon drivers to using the sarea from within the new master structures. Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
9c84ba4e |
|
01-Dec-2008 |
Andrew Morton <akpm@linux-foundation.org> |
drivers/gpu/drm/i915/i915_irq.c: fix warning drivers/gpu/drm/i915/i915_irq.c: In function 'i915_disable_pipestat': drivers/gpu/drm/i915/i915_irq.c:101: warning: control may reach end of non-void function 'i915_pipestat' being inlined Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
#
52440211 |
|
18-Nov-2008 |
Keith Packard <keithp@keithp.com> |
drm: move drm vblank initialization/cleanup to driver load/unload drm vblank initialization keeps track of the changes in driver-supplied frame counts across vt switch and mode setting, but only if you let it by not tearing down the drm vblank structure. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
05eff845 |
|
19-Nov-2008 |
Keith Packard <keithp@keithp.com> |
drm/i915: Always read pipestat in irq_handler Because we write pipestat before iir, it's possible that a pipestat interrupt will occur between the pipestat write and the iir write. This leaves pipestat with an interrupt status not visible in iir. This may cause an interrupt flood as we never clear the pipestat event. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
cdfbc41f |
|
04-Nov-2008 |
Eric Anholt <eric@anholt.net> |
drm/i915: Remove IMR masking during interrupt handler, and restart it if needed. The IMR masking was a technique recommended for avoiding getting stuck with no interrupts generated again in MSI mode. It kept new IIR bits from getting set between the IIR read and the IIR write, which would have otherwise prevented an MSI from ever getting generated again. However, this caused a problem for vblank as the IMR mask would keep the pipe event interrupt from getting reflected in IIR, even after the IMR mask was brought back down. Instead, just check the state of IIR after we ack the interrupts we're going to handle, and restart if we didn't get IIR all the way to zero. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
7c463586 |
|
04-Nov-2008 |
Keith Packard <keithp@keithp.com> |
drm/i915: Manage PIPESTAT to control vblank interrupts instead of IMR. The pipestat fields affect reporting of all vblank-related interrupts, so we have to reset them during the irq_handler, and while enabling vblank interrupts. Otherwise, if a pipe status field had been set to non-zero before enabling reporting, we would never see an interrupt again. This patch adds i915_enable_pipestat and i915_disable_pipestat to abstract out the steps needed to change the reported interrupts. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
0baf823a |
|
07-Nov-2008 |
Keith Packard <keithp@keithp.com> |
drm/i915: Move legacy breadcrumb out of the reserved status page area Addresses in the hardware status page below index 0x20 are reserved for use by the hardware. The legacy breadcrumb was sitting at index 5. Move it to index 0x21, and make sure everyone uses the defined value instead of hard-coded constants. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
|
#
bd95e0a4 |
|
04-Nov-2008 |
Eric Anholt <eric@anholt.net> |
i915: Remove racy delayed vblank swap ioctl. When userland detected that this ioctl was supported (by version number check), it used it in a racy way -- dispatch delayed swap, wait for vblank, continue rendering. As there was no mechanism for it to wait for the swap to finish, sometimes it would render before the swap and garbage would be displayed on the screen. By removing the ioctl and returning -EINVAL, userland returns to its previous, correct rendering path of waiting for a vblank then dispatching a swap. The only path that could have used this ioctl correctly was page flipping, which relied on only one client running and emitting wait-for-vblank-before-rendering in the command stream. That path also falls back correctly, at the performance cost of not being able to queue up rendering before the flip occurs. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
|
#
42f52ef8 |
|
18-Oct-2008 |
Keith Packard <keithp@keithp.com> |
drm/i915: use pipes, not planes to label vblank data vblank in the kernel is far simpler if it deals with pipes instead of planes, so we're changing both user and kernel side. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
9e44af79 |
|
16-Oct-2008 |
Keith Packard <keithp@keithp.com> |
drm/i915: hold dev->struct_mutex and DRM lock during vblank ring operations To synchronize clip lists with the X server, the DRM lock must be held while looking at drawable clip lists. To synchronize with other ring access, the ring mutex must be held while inserting commands into the ring. Failure to do the first resulted in easy visual corruption when moving windows, and the second could have corrupted the ring with DRI2. Grabbing the DRM lock involves using the DRM tasklet mechanism, grabbing the ring mutex means potentially sleeping. Deal with both of these by always running the tasklet from a work handler. Also, protect from clip list changes since the vblank request was queued by making sure the window has at least one rectangle while looking inside, preventing oopses . Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
053d7f24 |
|
17-Oct-2008 |
Eric Anholt <eric@anholt.net> |
i915: Enable IMR passthrough of vblank events before enabling it in pipestat. Otherwise, if we lost the race, the pipestat bit would be set without being reflected in IIR, and we would never clear the pipestat bit so the pipe event would never be generated again, and all vblank waits would time out. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
35ad68c1 |
|
17-Oct-2008 |
Eric Anholt <eric@anholt.net> |
drm: Remove two leaks of vblank reference count in error paths. If the failing paths were hit, the vblank IRQ would never get turned off again. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
e9d21d7f |
|
16-Oct-2008 |
Keith Packard <keithp@keithp.com> |
i915: Protect vblank IRQ reg access with spinlock This uses the same spinlock as the user_irq code as it shares the same register, ensuring that interrupt registers are updated atomically. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
630681d9 |
|
06-Oct-2008 |
Eric Anholt <eric@anholt.net> |
drm: Increment dev_priv->irq_received so i915_gem_interrupts count works. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
c99b058f |
|
20-Aug-2008 |
Kristian Høgsberg <krh@redhat.com> |
i915: Make use of sarea_priv conditional. We fail ioctls that depend on the sarea_priv with EINVAL. Signed-off-by: Kristian Høgsberg <krh@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
546b0974 |
|
01-Sep-2008 |
Eric Anholt <eric@anholt.net> |
i915: Use struct_mutex to protect ring in GEM mode. In the conversion for GEM, we had stopped using the hardware lock to protect ring usage, since it was all internal to the DRM now. However, some paths weren't converted to using struct_mutex to prevent multiple threads from concurrently working on the ring, in particular between the vblank swap handler and ioctls. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
673a394b |
|
30-Jul-2008 |
Eric Anholt <eric@anholt.net> |
drm: Add GEM ("graphics execution manager") to i915 driver. GEM allows the creation of persistent buffer objects accessible by the graphics device through new ioctls for managing execution of commands on the device. The userland API is almost entirely driver-specific to ensure that any driver building on this model can easily map the interface to individual driver requirements. GEM is used by the 2d driver for managing its internal state allocations and will be used for pixmap storage to reduce memory consumption and enable zero-copy GLX_EXT_texture_from_pixmap, and in the 3d driver is used to enable GL_EXT_framebuffer_object and GL_ARB_pixel_buffer_object. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
0a3e67a4 |
|
30-Sep-2008 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm: Rework vblank-wait handling to allow interrupt reduction. Previously, drivers supporting vblank interrupt waits would run the interrupt all the time, or all the time that any 3d client was running, preventing the CPU from sleeping for long when the system was otherwise idle. Now, interrupts are disabled any time that no client is waiting on a vblank event. The new method uses vblank counters on the chipsets when the interrupts are turned off, rather than counting interrupts, so that we can continue to present accurate vblank numbers. Co-author: Michel Dänzer <michel@tungstengraphics.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
8ee1c3db |
|
05-Aug-2008 |
Matthew Garrett <mjg59@srcf.ucam.org> |
Add Intel ACPI IGD OpRegion support This adds the support necessary for allowing ACPI backlight control to work on some newer Intel-based graphics systems. Tested on Thinkpad T61 and HP 2510p hardware. Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
|
#
ed4cb414 |
|
29-Jul-2008 |
Eric Anholt <eric@anholt.net> |
i915: Add support for MSI and interrupt mitigation. Previous attempts at interrupt mitigation had been foiled by i915_wait_irq's failure to update the sarea seqno value when the status page indicated that the seqno had already been passed. MSI support has been seen to cut CPU costs by up to 40% in some workloads by avoiding other expensive interrupt handlers for frequent graphics interrupts. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
585fb111 |
|
29-Jul-2008 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
i915: Use more consistent names for regs, and store them in a separate file. Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
|
#
c0e09200 |
|
28-May-2008 |
Dave Airlie <airlied@redhat.com> |
drm: reorganise drm tree to be more future proof. With the coming of kernel based modesetting and the memory manager stuff, the everything in one directory approach was getting very ugly and starting to be unmanageable. This restructures the drm along the lines of other kernel components. It creates a drivers/gpu/drm directory and moves the hw drivers into subdirectores. It moves the includes into an include/drm, and sets up the unifdef for the userspace headers we should be exporting. Signed-off-by: Dave Airlie <airlied@redhat.com>
|