summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-07-27drm/i915: Gather all the power well->domain mappings to one placeImre Deak
Shuffle the power well->domain mapping macros around so they are at one place in old->new GEN order. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-19-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Move hsw_power_well_enable() next to the rest of HSW helpersImre Deak
Move the helper next to the rest of HSW specific code. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-18-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen9+: Unify the HSW/BDW and GEN9+ power well helpersImre Deak
After the previous refactorings the HSW/BDW and GEN9+ power well helpers are practically identical, so use the HSW power well helpers for GEN9+ too. This means using the HSW power well ops instead of the SKL one and setting the irq_pipe_mask, has_vga and has_fuses attributes as needed. v2: - Rebased on v2 of patch 15. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-7-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw+: Add has_fuses power well attributeImre Deak
The pattern of a power well backing a set of fuses whose initialization we need to wait for during power well enabling is common to all GEN9+ platforms. Adding support for this to the HSW power well enable helper allows us to use the HSW/BDW power well code for GEN9+ as well in a follow-up patch. v2: - Use an enum for power gates instead of raw numbers. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-6-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Wait for the power well disabled stateImre Deak
Similarly to GEN9+ waiting for the power well disabled state is a safer option and also provides diagnostic info if the disabling didn't succeed or the power well was forced on by an external requester. While at it also use the existing GEN9+ helper to wait for the enabled state. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-15-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Add irq_pipe_mask, has_vga power well attributesImre Deak
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>
2017-07-27drm/i915/hsw+: Unify the hsw/bdw and gen9+ power well req/state macrosImre Deak
Although on HSW/BDW there is only a single display global power well, it's programmed the same way as other GEN9+ power wells. This also means we can get at the HSW/BDW request and status flags the same way it's done on GEN9+ by assigning the corresponding HSW/BDW power well ID. This ID was assigned in a recent patch, so we can now switch to using the same macros everywhere on HSW+. Updating the HSW power well control register with RMW is not strictly necessary, but this will allow us to use the same code for GEN9+. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-13-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Split power well set to enable/disable helpersImre Deak
We can reduce the code indentation by splitting the set helper to separate enable/disable helpers. This also allows us to unify the HSW/BDW and GEN9+ power well ops in follow-up patches, which introduces some differences between the enable and disable helpers. While at it also remove the redundant enable/disable debug messages, the same info is printed already elsewhere. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-12-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Remove redundant state check during power well togglingImre Deak
Similarly to the GEN9 power well toggling, saving an occasional extra MMIO write is not worth the code complexity, let's simplify things. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-11-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen9+: Remove redundant state check during power well togglingImre Deak
Atm we enable/disable a power well only if it wasn't already enabled/disabled respectively. The only reason for this I can think of is to save the extra MMIO writes. Since the HW state matches the power well's usage counter most of the time the overhead due to these MMIOs is insignificant. Let's simplify the code by making the writes unconditional. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-10-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen9+: Remove redundant power well state assert during enablingImre Deak
We check already for power wells that are unexpectedly on (or forced on) during power well disabling. Those checks also account for other power well requesters like KVMR or DEBUG. As such this check is redundant, let's remove it to simplify things. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-9-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/bxt, glk: Give a proper name to the power well struct phy fieldImre Deak
Follow-up patches will add new fields to the i915_power_well struct that are specific to the hsw_power_well_ops helpers. Prepare for this by changing the generic 'data' field to a union of platform specific structs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-8-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Check for duplicated power well IDsImre Deak
Check that all the power well IDs are unique on the given platform. v2: - Fix using BIT_ULL() instead of BIT() for 64 bit mask. v3: - Move the check to a separate function. (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-4-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/hsw, bdw: Add an ID for the global display power wellImre Deak
Add an ID for the HSW/BDW global display power well for consistency. The ID is selected so that it can be used to get at the HW request and status flags with the corresponding GEN9+ macros. Unifying the HSW/BDW and GEN9+ versions of these macros and the power well ops using them will be done in follow-up patches. v2: - Rebased on v2 of patch 2. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-3-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/gen2: Add an ID for the display pipes power wellImre Deak
Make the I830 power well ID assignment explicit for consistency. v2: - s/GEN2/I830/ in the comment, since other GEN2s don't have the power well. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-2-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Assign everywhere the always-on power well IDImre Deak
Power well IDs are used for lookup so they must be unique. To ensure this assign the always-on power well ID everywhere where it's missing. This didn't cause a problem so far, since we didn't need to look up power wells that happened to share their IDs. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-4-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Unify power well ID enumsImre Deak
Atm, the power well IDs are defined in separate platform specific enums, which isn't ideal for the following reasons: - the IDs are used by helpers like lookup_power_well() in a platform independent way - the always-on power well is used by multiple platforms and so needs now separate IDs, although these IDs refer to the same thing To make things more consistent use a single enum instead of the two separate ones, listing the IDs per platform (or set of very similar platforms like all GEN9/10). Replace the separate always-on power well IDs with a single ID. While at it also add a note clarifying the distinction between regular power wells that follow a common programming pattern and custom ones that are programmed in some other way. The IDs for regular power wells need to stay fixed, since they also define the request and state HW flag positions in their corresponding power well control register(s). v2: - Add comment about id to req,status bit mapping to the enum. (Rodrigo) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170711204236.5618-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/chv: Add unique power well ID for the pipe A power wellImre Deak
The power well IDs are used for lookup, so they must be unique on a given platform; ensure this on CHV. This didn't cause an actual problem since we didn't need to look up power wells which happened to share an ID. Mark this new power well as custom, since its programming pattern doesn't follow that of the rest of VLV/CHV power wells. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1499352040-8819-2-git-send-email-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Simplify scaler init during CRTC HW readoutImre Deak
The crtc state starts out being bzero'd, so no need to clear scaler_users. Also intel_crtc_init_scalers() knows already which platforms have scalers, so no need for the platform check here. Similarly intel_crtc_init_scalers() will init scaler_id as required, so no need to do it here separately. Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170719225057.20131-2-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Fix scaler init during CRTC HW state readoutImre Deak
The scaler allocation code depends on a non-zero default value for the crtc scaler_id, so make sure we initialize the scaler state accordingly even if the crtc is off. This fixes at least an initial YUV420 modeset (added in a follow-up patchset by Shashank) when booting with the screen off: after the initial HW readout and modeset which enables the scaler a subsequent modeset will disable the scaler which isn't properly allocated. This results in a funky HW state where the pipe scaler HW registers can't be modified and the normally black screen is grey and shifted to the right or jitters. The problem was revealed by Shashank's YUV420 patchset and first reported by Ville. v2: - In the stable tag also include versions which need backporting (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chandra Konduru <chandra.konduru@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: <stable@vger.kernel.org> # 4.2.x Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720112820.26816-1-imre.deak@intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915/selftests: Exercise independence of per-engine resetsChris Wilson
If all goes well, resetting one engine should not affect the operation of any others. So to test this, we setup a continuous stream of requests onto to each of the "innocent" engines whilst constantly resetting our target 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: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-16-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Disable per-engine reset for BroxtonChris Wilson
Triggering a GPU reset for one engine affects another, notably corrupting the context status buffer (CSB) effectively losing track of inflight requests. Adding a few printks: diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index ad41836fa5e5..a969456bc0fa 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1953,6 +1953,7 @@ int i915_reset_engine(struct intel_engine_cs *engine) goto out; } + pr_err("Resetting %s\n", engine->name); ret = intel_gpu_reset(engine->i915, intel_engine_flag(engine)); if (ret) { /* If we fail here, we expect to fallback to a global reset */ diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 716e5c9ea222..a72bc35d0870 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -355,6 +355,7 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN); port_set(&port[n], port_pack(rq, count)); desc = execlists_update_context(rq); + pr_err("%s: in (rq=%x) ctx=%d\n", engine->name, rq->global_seqno, upper_32_bits(desc)); GEM_DEBUG_EXEC(port[n].context_id = upper_32_bits(desc)); } else { GEM_BUG_ON(!n); @@ -594,9 +595,23 @@ static void intel_lrc_irq_handler(unsigned long data) if (!(status & GEN8_CTX_STATUS_COMPLETED_MASK)) continue; + pr_err("%s: out CSB (%x head=%d, tail=%d), ctx=%d, rq=%d\n", + engine->name, + readl(csb_mmio), + head, tail, + readl(buf+2*head+1), + port->context_id); + /* Check the context/desc id for this event matches */ - GEM_DEBUG_BUG_ON(readl(buf + 2 * head + 1) != - port->context_id); + if (readl(buf + 2 * head + 1) != port->context_id) { + pr_err("%s: BUG CSB (%x head=%d, tail=%d), ctx=%d, rq=%d\n", + engine->name, + readl(csb_mmio), + head, tail, + readl(buf+2*head+1), + port->context_id); + BUG(); + } rq = port_unpack(port, &count); GEM_BUG_ON(count == 0); Results in: [ 6423.006602] Resetting rcs0 [ 6423.009080] rcs0: in (rq=fffffe70) ctx=1 [ 6423.009216] rcs0: in (rq=fffffe6f) ctx=3 [ 6423.009542] rcs0: out CSB (2 head=1, tail=2), ctx=3, rq=3 [ 6423.009619] Resetting bcs0 [ 6423.009980] rcs0: BUG CSB (0 head=1, tail=2), ctx=0, rq=3 Note that this bug may be affect all machines and not just Broxton, Broxton is just the first machine on which I have confirmed this bug. Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang recovery") 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> Acked-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-13-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Emit a user level message when resetting the GPU (or engine)Chris Wilson
Although a banned context will be told to -EIO off if they try to submit more requests, we have a discrepancy between whole device resets and per-engine resets where we report the GPU reset but not the engine resets. This leaves a bit of mystery as to why the context was banned, and also reduces awareness overall of when a GPU (engine) reset occurs with its possible side-effects. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@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/20170721123238.16428-13-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Make i915_gem_context_mark_guilty() safe for unlocked updatesChris Wilson
Since we make call i915_gem_context_mark_guilty() concurrently when resetting different engines in parallel, we need to make sure that our updates are safe for the unlocked access. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@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/20170721123238.16428-12-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Clear engine irq posted following a resetChris Wilson
When the GPU is reset, we want to discard all pending notifications as either we have manually completed them, or they are no longer applicable. Make sure we do reset the engine->irq_posted prior to re-enabling the engine (e.g. the interrupt tasklets) in i915_gem_reset_finish_engine(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-11-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Assert that machine is wedged for nop_submit_requestChris Wilson
We should only ever do nop_submit_request when the machine is wedged, so assert it is so. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-10-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Wake up waiters after setting the WEDGED bitChris Wilson
After setting the WEDGED bit, make sure that we do wake up waiters as they may not be waiting for a request completion yet, just for its execution. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-9-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Move idle checks before intel_engine_init_global_seqno()Chris Wilson
intel_engine_init_globa_seqno() may be called from an uncontrolled set-wedged path where we have given up waiting for broken hw and declare it defunct. Along that path, any sanity checks that the hw is idle before we adjust its state will expectedly fail, so we simply cannot. Instead of asserting inside init_global_seqno, we move them to the normal caller reset_all_global_seqno() as it handles runtime seqno wraparound. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-8-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Clear execlist port[] before updating seqno on wedgingChris Wilson
When we wedge the device, we clear out the in-flight requests and advance the breadcrumb to indicate they are complete. However, the breadcrumb advance includes an assert that the engine is idle, so that advancement needs to be the last step to ensure we pass our own sanity checks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-7-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Check the execlist queue for pending requests before declaring idleChris Wilson
Including a check against the execlist queue before calling the engine idle and passing hangcheck. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-6-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Check execlist/ring status during hangcheckChris Wilson
Before we declare an engine as idle, check if there are any pending execlist context-switches and if the ring itself reports as idle. Otherwise, we may be left in a situation where we miss a crucial execlist event (or something more sinister) yet the requests complete. Since the seqno write happens, we believe the engine to be truly idle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-5-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Flush the execlist ports if idleChris Wilson
When doing a GPU reset, the CSB register will be trashed and we will lose any context-switch notifications that happened since the tasklet was disabled. If we find that all requests on this engine were completed, we want to make sure that the ELSP tracker is similarly empty so that we do not feed back in the completed requests upon recovering from the reset. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-4-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Serialize per-engine resets against new requestsChris Wilson
We rely on disabling the execlists (by stopping the tasklet) to prevent new requests from submitting to the engine ELSP before we are ready. However, we re-enable the engine before we call init_hw which gives userspace the opportunity to subit a new request which is then overwritten by init_hw -- but not before the HW may have started executing. The subsequent out-of-order CSB is detected by our sanity checks in intel_lrc_irq_handler(). Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@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/20170721123238.16428-3-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Reset context image on engines after triggering the resetChris Wilson
We try to fixup the context image after the reset to ensure that there are no more pending writes from the hw that may conflict and to fixup any that were in flight. Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-2-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm/i915: Report execlists irq bit in debugfsChris Wilson
As part of the knowing whether there is outstanding data in the CSB, also check whether there is an outstanding IRQ notification. 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> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170721123238.16428-1-chris@chris-wilson.co.uk Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27Merge airlied/drm-next into drm-intel-next-queuedDaniel Vetter
Resync with upstream to avoid git getting too badly confused. Also, we have a conflict with the drm_vblank_cleanup removal, which cannot be resolved by simply taking our side. Bake that in properly. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-27drm: linux-next: build failure after merge of the drm-misc treeStephen Rothwell
Hi all, After merging the drm-misc tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/vboxvideo/vbox_drv.c:235:2: error: unknown field 'set_busid' specified in initializer .set_busid = drm_pci_set_busid, ^ drivers/staging/vboxvideo/vbox_drv.c:235:15: error: 'drm_pci_set_busid' undeclared here (not in a function) .set_busid = drm_pci_set_busid, ^ drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_init': drivers/staging/vboxvideo/vbox_drv.c:273:9: error: implicit declaration of function 'drm_pci_init' [-Werror=implicit-function-declaration] return drm_pci_init(&driver, &vbox_pci_driver); ^ drivers/staging/vboxvideo/vbox_drv.c: In function 'vbox_exit': drivers/staging/vboxvideo/vbox_drv.c:278:2: error: implicit declaration of function 'drm_pci_exit' [-Werror=implicit-function-declaration] drm_pci_exit(&driver, &vbox_pci_driver); ^ Caused by commits 5c484cee7ef9 ("drm: Remove drm_driver->set_busid hook") 10631d724def ("drm/pci: Deprecate drm_pci_init/exit completely") interacting with commit dd55d44f4084 ("staging: vboxvideo: Add vboxvideo to drivers/staging") from the staging.current tree. I have applied the following merge fix patch - please check that it is correct. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 19 Jul 2017 11:41:01 +1000 Subject: [PATCH] drm: fixes for staging due to API changes in the drm core Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-07-27Backmerge tag 'v4.13-rc2' into drm-nextDave Airlie
Linux 4.13-rc2 This is required for drm-misc fixing.
2017-07-27Merge tag 'drm-misc-next-2017-07-26' of ↵Dave Airlie
git://anongit.freedesktop.org/git/drm-misc into drm-next drm-misc-next-2017-07-18: Core Changes: - A couple fixes to only opening crc when needed (Maarten) - Change atomic helper swap_state to be interruptible (Maarten) - fb_helper: Support waiting for an output before setting up (Daniel) - Allow drivers supporting runtime_pm to use helper_commit_tail (Maxime) Driver Changes: - misc: Use %pOF to print device node names (Rob) - Miscellaneous fixes drm-misc-next-2017-07-18: UAPI Changes: - Fail commits which request an event without including a crtc (Andrey) Core Changes: - Add YCBCR 4:2:0 support (Shashank) - s/drm_atomic_replace_property_blob/drm_property_replace_blob/ (Peter) - Add proper base class for private objs instead of using void* (Ville) - Remove pending_read/write_domains from drm_gem_object (Chris) - Add async plane update support (ie: cursor) to atomic helpers (Gustavo) - Add old state to .enable and rename to .atomic_enable (Laurent) - Add drm_atomic_helper_wait_for_flip_done() (Boris) - Remove drm_driver->set_busid hook (Daniel) - Migrate vblank documentation into the source files (Daniel) - Add fb_helper->lock instead of abusing modeset lock (Thierry/Daniel) Driver Changes: - stm: Add STM32 DSI controller driver (Phillipe) - amdgpu: Numerous small/misc fixes - bridge: Add Synopsys Designware MIPI DSI host bridge driver (Phillipe) - tinydrm: Add support for Pervasive Displays RePaper displays (Noralf) - misc: Replace for_each_[obj]_in_state to prep for removal (Maarten) - misc: Use .atomic_disable for atomic drivers (Laurent) - vgem: Pin pages when mapped/exported (Chris) - dw_hdmi: Add support for Rockchip RK3399 (Mark) - atmel-hlcdc: Add 8-bit color look-up table format (Peter) - vc4: Send vblank event when disabling a crtc (Boris) - vc4: Use atomic helpers for fence waits (Eric) - misc: drop drm_vblank_cleanup cargo-cult (Daniel) Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Cc: Eric Anholt <eric@anholt.net> Cc: Peter Rosin <peda@axentia.se> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.com> Cc: Thierry Reding <treding@nvidia.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Peter Rosin <peda@axentia.se> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Philippe CORNU <philippe.cornu@st.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Rob Herring <robh@kernel.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> * tag 'drm-misc-next-2017-07-26' of git://anongit.freedesktop.org/git/drm-misc: (171 commits) drm/hisilicon: fix build error without fbdev emulation drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm users drm: Improve kerneldoc for drm_modeset_lock drm/hisilicon: Remove custom FB helper deferred setup drm/exynos: Remove custom FB helper deferred setup drm/fb-helper: Support deferred setup dma-fence: Don't BUG_ON when not absolutely needed drm: Convert to using %pOF instead of full_name drm/syncobj: Fix kerneldoc drm/atomic: Allow drm_atomic_helper_swap_state to fail drm/atomic: Add __must_check to drm_atomic_helper_swap_state. drm/vc4: Handle drm_atomic_helper_swap_state failure drm/tilcdc: Handle drm_atomic_helper_swap_state failure drm/tegra: Handle drm_atomic_helper_swap_state failure drm/msm: Handle drm_atomic_helper_swap_state failure drm/mediatek: Handle drm_atomic_helper_swap_state failure drm/i915: Handle drm_atomic_helper_swap_state failure drm/atmel-hlcdc: Handle drm_atomic_helper_swap_state failure drm/nouveau: Handle drm_atomic_helper_swap_state failure drm/atomic: Change drm_atomic_helper_swap_state to return an error. ...
2017-07-26drm/hisilicon: fix build error without fbdev emulationArnd Bergmann
We cannot reference priv->fbdev outside of the #ifdef: drivers/net/virtio_net.c:1881:12: error: 'virtnet_restore_up' defined but not used [-Werror=unused-function] static int virtnet_restore_up(struct virtio_device *vdev) drivers/net/virtio_net.c:1859:13: error: 'virtnet_freeze_down' defined but not used [-Werror=unused-function] static void virtnet_freeze_down(struct virtio_device *vdev) As the #ifdef is a bit annoying here, this removes it entirely and uses an IS_ENABLED() check in it place where needed. Fixes: b4dd9f1ffaba ("drm/hisilicon: Remove custom FB helper deferred setup") Signed-off-by: Arnd Bergmann <arnd@arndb.de> [danvet: One step further, also remove the IS_ENABLED checks, core no-ops out the fb helper functions that the cma helpers use. Discussed with Arnd on dri-devel.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170725180555.3699056-1-arnd@arndb.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/atomic: implement drm_atomic_helper_commit_tail for runtime_pm usersMaxime Ripard
The current drm_atomic_helper_commit_tail helper works only if the CRTC is accessible, and documents an alternative implementation that is supposed to be used if that happens. That implementation is then duplicated by some drivers. Instead of documenting it, let's implement an helper that all the relevant users can use directly. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/a8f92dc70048bab746e94dadd1c23200626aff60.1500555652.git-series.maxime.ripard@free-electrons.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm: Improve kerneldoc for drm_modeset_lockLiviu Dudau
Explain better when the drm_modeset_acquire_ctx parameter can be skipped for drm_modeset_lock() call. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170720160748.12856-1-Liviu.Dudau@arm.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/hisilicon: Remove custom FB helper deferred setupThierry Reding
The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Dont' resurrect drm_vblank_cleanup. Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-5-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/exynos: Remove custom FB helper deferred setupThierry Reding
The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already. Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Inki Dae <inki.dae@samsung.com> Tested-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-4-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/fb-helper: Support deferred setupDaniel Vetter
FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a matching mode. The fallback is in place because VGA connectors can happen to report an unknown connection status even when they are in fact connected. Some drivers have custom solutions in place to defer FB helper setup until at least one output is connected. But the logic behind these solutions is always the same and there is nothing driver-specific about it, so a better alterative is to fix the FB helper core and add support for all drivers automatically. This patch adds support for deferred FB helper setup. It checks all the connectors for their connection status, and if all of them report to be disconnected marks the FB helper as needing deferred setup. Whet setup is deferred, the FB helper core will automatically retry setup after a hotplug event, and it will keep trying until it succeeds. v2: Rebase onto my entirely reworked fbdev helper locking. One big difference is that this version again drops&reacquires the fbdev lock (which is now fb_helper->lock, but before this patch series it was mode_config->mutex), because register_framebuffer must be able to recurse back into fbdev helper code for the initial screen setup. v3: __drm_fb_helper_initial_config must hold fb_helper->lock upon return, I've fumbled that in the deferred setup case (Liviu). v4: I was blind, redo this all. __drm_fb_helper_initial_config shouldn't need to reacquire fb_helper->lock, that just confuses callers. I myself got confused by kernel_fb_helper_lock and somehow thought it's the same as fb_helper->lock. Tsk. Also simplify the logic a bit (we don't need two functions to probe connectors), we can stick much closer to the existing code. And update some comments I've spotted that are outdated. v5: Don't pass -EAGAIN to drivers, it's just an internal error code (Liviu). v6: Add _and_unlock suffix to clarify locking (Maarten) Cc: Liviu Dudau <liviu@dudau.co.uk> Cc: John Stultz <john.stultz@linaro.org> Cc: Thierry Reding <treding@nvidia.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Tested-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com> (v1) Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com> Reviewed-by: Liviu Dudau <liviu@dudau.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170706130023.28417-3-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26dma-fence: Don't BUG_ON when not absolutely neededDaniel Vetter
It makes debugging a massive pain. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Gustavo Padovan <gustavo@padovan.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170720125107.26693-1-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm: Convert to using %pOF instead of full_nameRob Herring
Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring <robh@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Inki Dae <inki.dae@samsung.com> Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Cc: Kukjin Kim <kgene@kernel.org> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Cc: Xinliang Liu <z.liuxinliang@hisilicon.com> Cc: Rongrong Zou <zourongrong@gmail.com> Cc: Xinwei Kong <kong.kongxinwei@hisilicon.com> Cc: Chen Feng <puck.chen@hisilicon.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Carlo Caione <carlo@caione.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Maxime Ripard <maxime.ripard@free-electrons.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Partially-Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> [seanpaul changed subject prefix and fixed conflict in stm/ltdc.c] Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26Merge airlied/drm-next into drm-misc-nextDaniel Vetter
I need this to be able to apply the deferred fbdev setup patches, I need the relevant prep work that landed through the drm-intel tree. Also squash in conflict fixup from Laurent Pinchart. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/syncobj: Fix kerneldocDaniel Vetter
make htmldocs helps with catching these. Cc: Dave Airlie <airlied@gmail.com> Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170718074113.5554-1-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/atomic: Allow drm_atomic_helper_swap_state to failMaarten Lankhorst
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-13-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 11:12:32 +0000