It's too chatty to have three places to tell us which one
is next vgpu for schedule. My log file was bloated to eat
all disk space..
Cc: Ping Gao <ping.a.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
The timeslice usage will determine vGPU whether has chance to
schedule or not at every vGPU switch checkpoint.
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
vGPU resource is allocated by scheduler. To account for non-allocated
free cycles, we create an idle vGPU as the placeholder similar to idle task
concept, which is useful to handle some corner cases in scheduling policy.
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This method tries to guarantee precision in second level, with the
adjustment conducted in every 100ms. At the end of each vGPU switch
calculate the sched time and subtract it from the time slice
allocated; the allocated time slice for every 100ms together with
remaining timeslice, will be used to decide how much timeslice
allocated to this vGPU in the next 100ms slice, with the end goal
to guarantee weight ratio in second level.
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
The weight defines proportional control of physical GPU resource
shared between vGPUs. So far the weight is tied to a specific vGPU
type, i.e when creating multiple vGPUs with different types, they
will inherit different weights.
e.g. The weight of type GVTg_V5_2 is 8, the weight of type GVTg_V5_4
is 4, so vGPU of type GVTg_V5_2 has double vGPU resource of vGPU type
GVTg_V5_4.
TODO: allow user control the weight setting in the future.
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Factor out the scheduler to a more clear structure, the basic
logic is to find out next vGPU first and then schedule it.
vGPUs were ordered in a LRU list, scheduler scan from the LRU
list head and choose the first vGPU who has pending workload.
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Add some statistic routine to collect the time when vGPU is
scheduled in/out and the time of the last ctx submission.
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Currently the scheduler is triggered by delayed_work, which doesn't
provide precision at microsecond level. Move to hrtimer instead for
more accurate control.
Signed-off-by: Ping Gao <ping.a.gao@intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
The variable info is never NULL, which is checked by the caller. This
patch removes the redundant info NULL check logic.
Fixes: 695fbc08d8 ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
From commit d1a513be1f ("drm/i915/gvt: add resolution definition for vGPU
type"), small type has been restricted to small resolution, so not
require larger high GM size any more. Change to smaller 384M for more
VM creation with vGPU enabled which still perform reasonable workload.
Fixes: d1a513be1f ("drm/i915/gvt: add resolution definition for vGPU type")
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
intel_shadow_wa_ctx is a field of intel_vgpu_workload. container_of() can
be used to refine the relation-ship between intel_shadow_wa_ctx and
intel_vgpu_workload. This patch removes the useless dereference.
v2. add "drm/i915/gvt" prefix. (Zhenyu)
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Turn on KBL WS platform support in gvt-g. More platforms would be
enabled, after validate.
Signed-off-by: Xu Han <xu.han@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This adds initial attribute group for mdev to hold vGPU related
for each mdev device, currently just vGPU id is shown.
v2: rename group name as "intel_vgpu"
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
GVT-g will emulate a fixed DPCD data to VM for DP/eDP panel. Update
this data to latest DP1.2 with the maximum lane bandwidth of 5.4G/s
to support 4K resolution in VM.
V3: modify patch comment
V2: add inline comment to describe the dpcd_fix_data.
Signed-off-by: Pei Zhang <pei.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Initialize the correct vreg for virtual monitor.
Set PG0/1/2 distribution and fuse download done in SKL_FUSE_STATUS.
Set PLL_ENABLE and PLL_LOCK in LCPLL_CTL.
Guest may need to check these registers for display monitor detection
on Skylake platforms.
Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Backmerge drm-next one more because Dave fumbled the conflict
resolution slightly and I didn't notice it. We need Zhenyu's hotfix
before he can assemble the gvt pull ...
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
From commit 73dec95e6b ("drm/i915: Emit to ringbuffer directly"),
copy_gma_to_hva() now returns copied data length instead of 0, so
need to change error return check for that.
Note: Looks this is caused by backmerge conflict resolving, so
4.11-rc4 is not impacted as commit 73dec95e6b ("drm/i915: Emit to
ringbuffer directly") is not in 4.11. But need to fix this before I
can apply 4.12 stuff against drm-intel-next correctly.
Fixes: e5c1ff1475 ("Backmerge tag 'v4.11-rc4' into drm-next")
Cc: Dave Airlie <airlied@redhat.com>
Cc: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Several major vendor USB-C->HDMI converters, in particular the DA200,
fail to recover a 5.4 GHz 1 lane signal if the link N is greater than
0x80000.
The link M and N depend on the pixel clock and link clock ratio. With
current code link N exceeds 0x80000 only when link clock >= 540000
kHz. Except for the eDP intermediate link clocks, at least the four
least significant bits are always zero. Just one bit shift right would
be enough to bring even the DP 1.4 810000 kHz link clock under 0x80000
link N. The pixel clock for modes that require a link clock >= 540000
kHz would also have several least significant bits zero. Unless the user
provides a mode with an odd pixel clock value, we can reduce the numbers
to reach the goal, with no loss in precision.
The DP spec even mentions sources making choices that "allow for static
and relatively small Mvid and Nvid values", thus reducing the link M/N
regardless of the sink in question seems justified.
Everything here is based on the work and information gathered by Clint
Taylor <clinton.a.taylor@intel.com>. This is just an iteration to reduce
the parameters regardless of lane count, link rate, or sink.
Reference: http://patchwork.freedesktop.org/patch/msgid/1490225256-11667-1-git-send-email-clinton.a.taylor@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93578
Tested-by: Mads <mads@ab3.no>
Tested-by: PJ <foobar@pjmodos.net>
Tested-by: François Guerraz <kubrick@fgv6.net>
Tested-by: Lev Popov <leo@nabam.net>
Tested-by: Igor Krivenko <igor.s.krivenko@gmail.com>
Tested-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1490614405-23337-1-git-send-email-jani.nikula@intel.com
Capturing GPU state requires the device to be awake in order to read
registers. Normally, this is taken along the error handler, but for the
direct debugfs access, we cannot make assumptions about the current
device state and so either need to wake it up, or abort.
Fixes: 5a4c6f1b1b ("drm/i915: The return of i915_gpu_info to debugfs")
Testcase: igt/pm_rpm/debugfs-read
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170328131407.14863-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
We don't expect the core runtime PM get helpers to return any error, so
add a WARN for this. Also print the return value for all the callsites
to help debugging.
v2:
- Don't call pm_runtime_get_sync() as part of initing locals. (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/1490693935-12638-1-git-send-email-imre.deak@intel.com
Don't throw a warning if we are given an invalid property id. While
here let's also bring back Robert' original idea of catching unhandled
enumeration values at compile time.
Fixes: eec688e142 ("drm/i915: Add i915 perf infrastructure")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Robert Bragg <robert@sixbynine.org>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170327203236.18276-1-matthew.auld@intel.com
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJY2C9qAAoJEHm+PkMAQRiGaBQIAIGzdlZ6ImiP6zoukrRv7qUr
44ITm0lsBiL85QGedhQQL+Y9UqwUmlqgFqnH0Gr8YHNbLJWXzdjGbl5aVo4KjASq
104NLUDXtPww/xZdH4wJMzhuwucYwZOUyDOjOr0ak3cGxOE2xjNjHMZXxWUf20GO
EpRr6WhV1DUAvAdjdNa9KlcOjMluNpMLLyL1CFLjrkkArrWAyqOURKHAb6ZLghfv
iZV1qJTVPyYGpnlI3kuEgu2GuDjxqpoNLSr3wHyEHm/pBPEl7MX6zPbzcegBV8TY
cRRlXo4notdsuknmSNcj0hHuTQvw1kl7BhieLKVsnCyCIM6jjX4TSQZFutmbzwM=
=5iRl
-----END PGP SIGNATURE-----
Backmerge tag 'v4.11-rc4' into drm-next
Linux 4.11-rc4
The i915 GVT team need the rc4 code to base some more code on.
If we were to ever encounter a sample_flags mismatch we need to ensure
we destroy the stream when we bail.
Fixes: d79651522e ("drm/i915: Enable i915 perf stream for Haswell OA unit")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170327203459.18398-1-matthew.auld@intel.com
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
Cc: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-7-git-send-email-shashank.sharma@intel.com
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
- high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
V5: Addressed review comments from Ville and Ander
- Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
- While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.
V6: Addressed review comments from Ville
- Do not add IS_GLK check in disable/enable function, instead add it
in compute_config, while setting state flags.
- Remove unnecessary paranthesis.
- Simplyfy handle_sink_scrambling function as suggested.
- Add readout code for scrambling status in get_ddi_config and add a
check for the same in pipe_config_compare.
V7: Addressed review comments from Ander/Ville
- No separate function for source scrambling, make it inline
- Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
- Do not add platform check while setting source scrambling
- Use pipe_config instead of crtc->config to set sink scrambling
- To readout scrambling status, Compare with SCRAMBLING_MASK
not any of its bits
- Remove platform check in intel_pipe_config_compare while checking
scrambling status
V8: Fixed mege conflict, Addressed review comments from Ander
- Remove the desciption/comment about scrambling fom the caller, move
it to the function
- Move the IS_GLK check into scrambling function
- Fix alignment
V9: Fixed review comments from Ville, Ander
- Pass the scrambling state variables as bool input to the sink_scrambling
function and let the disable call be unconditional.
- Fix alignments in function calls and debug messages.
- Add kernel doc for function intel_hdmi_handle_sink_scrambling
V10: Rebase
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
All it does is pick the encoder and call intel_get_shared_dpll(). We
can just do this in the caller. One less indirection level during code
reading.
As another plus, now the two callers of intel_get_shared_dpll() are
{ironlake,haswell}_crtc_compute_clock().
Reported-by: 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: http://patchwork.freedesktop.org/patch/msgid/1490209125-20046-2-git-send-email-paulo.r.zanoni@intel.com
Use the incoming value from debugfs/i915_wedged to select which engines
to marked as guilty in order to force us to reset those requests
(required to quickly bypass simulated hangs).
Testcase: igt/gem_exec_capture
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/20170325134735.30581-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Whilst I like having the assertions clearly visible in the code, they
are quite repetitious! As we find new limits we want to incorporate into
the set of assertions, it make sense to refactor them to a common
routine.
v2: Add a guc holdout.
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/20170327131412.20293-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
If the request->wa_tail is 0 (because it landed exactly on the end of
the ringbuffer), when we reconstruct request->tail following a reset we
fill in an illegal value (-8 or 0x001ffff8). As a result, RING_HEAD is
never able to catch up with RING_TAIL and the GPU spins endlessly. If
the ring contains a couple of breadcrumbs, even our hangcheck is unable
to catch the busy-looping as the ACTHD and seqno continually advance.
v2: Move the wrap into a common intel_ring_wrap().
Fixes: a3aabe86a3 ("drm/i915/execlists: Reinitialise context image after GPU hang")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: <stable@vger.kernel.org> # v4.10+
Link: http://patchwork.freedesktop.org/patch/msgid/20170327130009.4678-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
All the pre-SKL sprite planes compute the x/y/tile offsets in a
similar way. There are a couple of minor differences but the primary
planes have those as well. Thus i9xx_check_plane_surface()
already does what we need, so let's use it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-7-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
The effective difference between i9xx_update_primary_plane()
and ironlake_update_primary_plane() is only the HSW/BDW
DSPOFFSET special case. So bring that over into
i9xx_update_primary_plane() and eliminate the duplicated code.
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/20170323192712.30682-6-ville.syrjala@linux.intel.com
Extract the primary plane surfae offset/x/y calculations for
pre-SKL platforms into a common function, and call it during the
atomic check phase to reduce the amount of stuff we have to do
during the commit phase. SKL is already doing this.
v2: Update the comment about the rotation adjustments to
match the code better (Chris)
Cc: 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>
Link: http://patchwork.freedesktop.org/patch/msgid/20170323192712.30682-5-ville.syrjala@linux.intel.com
Computing the plane control register value is branchy so moving it out
from the plane commit hook seems prudent. Let's pre-compute it during
the atomic check phase and store the result in the plane state.
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/20170323192712.30682-4-ville.syrjala@linux.intel.com
Share the code to compute the primary plane control register value
between the i9xx and ilk codepaths as the differences are minimal.
Actually there are no differences between g4x and ilk, so the
current split doesn't really make any sense.
Cc: 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/20170323192712.30682-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Pull the code to calculate the pre-SKL primary plane control register
value into separate functions. Allows us to pre-compute it in the
future.
v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris)
Cc: 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/20170323192712.30682-2-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
intel_flush_status_page() is defunct since commit f8dd2934c4
("drm/i915: Remove BXT incoherent seqno write workaround"), time to
remove it.
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>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170324163540.31981-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Not all of our target platforms have clflush. For those without, just
assume the status page is sufficiently coherent that we do not need our
paranoia.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 14a6bbf9e5 ("drm/i915: Replace irq_seqno_barrier on hws write with a clflush")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170324163540.31981-1-chris@chris-wilson.co.uk
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Old devices have quite severe restrictions for using fences, and unlike
more recent device (anything from Pineview onwards) we need to enforce
those restrictions even for unfenced tiled access from the render
pipeline.
Fixes: 944397f04f ("drm/i915: Store required fence size/alignment for GGTT vma")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.11-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170325113243.16438-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We have only 8bits of precise timestamps in which to complete our
upper/load reads, along with the switch between precision. This is not
always enough time to read the upper counter twice within the same time
slice, leading to hard lockups. Limit the number of times to prevent
an inifite loop (my fault for assuming we would have no trouble doing
the write + reads fast enough).
Fixes: 47c21d9a1a ("drm/i915: Extend vlv/chv residency resolution")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100377
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170324165418.7455-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
I noticed that gcc was spilling the CSB to the stack, so rearrange the
code to be more compact. Spilling in this function is slightly more
interesting due to the mmio reads acting as memory barriers and so
end up flushing the stack spills. Still miniscule to having to do at
least the pair of uncached reads :(
function old new delta
intel_lrc_irq_handler 1039 878 -161
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/20170325201053.21306-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
There is no need to expose this function as it is called from
one function only. Also move it up to avoid forward declaration.
v2: drop intel_ prefix (Oscar) and rename to fetch_uc_fw (Michal)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170327094510.167400-1-michal.wajdeczko@intel.com
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
