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 e9af4ea2b9 ("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 e9af4ea2b9, 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: e9af4ea2b9 ("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 60548c554b)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
A long time ago, we were afraid of handling interrupts and signaling
waiters during a reset, worrying that the confusion in request handling
would interfere with our attempts to process the reset in an orderly
fashion. Since then, we have isolated our irq-driven request handling by
virtue of the engine->timeline.lock and control of kthreads where
required, eliminating the danger of concurrently processing interrupts.
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: https://patchwork.freedesktop.org/patch/msgid/20180806145647.13131-1-chris@chris-wilson.co.uk
After disabling resource streamer on ICL (due to it actually not
existing there), I got feedback that there have been some experimental
patches for mesa to use RS years ago, but nothing ever landed or shipped
because there was no performance improvement.
This removes it from kernel keeping the uapi defines around for
compatibility.
v2: - re-add the inadvertent removal of CTX_CTRL_INHIBIT_SYN_CTX_SWITCH
- don't bother trying to document removed params on uapi header:
applications should know that from the query.
(from Chris)
v3: - disable CTX_CTRL_RS_CTX_ENABLE istead of removing it
- reword commit message after Daniele confirmed no performance
regression on his machine
- reword commit message to make clear RS is being removed due to
never been used
v4: - move I915_EXEC_RESOURCE_STREAMER to __I915_EXEC_ILLEGAL_FLAGS so
the check on ioctl() is made much earlier by
i915_gem_check_execbuffer() (suggested by Tvrtko)
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180803232443.17193-1-lucas.demarchi@intel.com
When the suballocator was unable to provide a suitable buffer for the MMUv1
linear window, we roll back the GPU initialization. As the GPU is runtime
resumed at that point we need to clear the kernel cmdbuf suballoc entry to
properly skip any attempt to manipulate the cmdbuf when the GPU gets shut
down in the runtime suspend later on.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref- commit 1c8f422059 ("mm: change return type to vm_fault_t")
Previously vm_insert_page() returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_page() will replace this inefficiency by
returning VM_FAULT_* type.
vmf_error() is the newly introduce inline function
in 4.17-rc6.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
The documentation of drm_sched_job_init and drm_sched_entity_push_job has
been clarified. Both functions should be called under a shared lock, to
avoid jobs getting pushed into the scheduler queue in a different order
than their sched_fence seqnos, which will confuse checks that are looking
at the seqnos to infer information about completion order.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
A new helper function(__drm_atomic_helper_plane_reset) has been added
for linking a plane with its state and resetting the core
properties(alpha, rotation, etc.) to their default values.
Use that instead of duplicating the logic.
__drm_atomic_helper_plane_reset initializes the alpha property to its
max value, which is defined by the drm core as DRM_BLEND_ALPHA_OPAQUE,
so nothing changes regarding the alpha value.
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180804161530.12275-9-alexandru-cosmin.gheorghe@arm.com
A new helper function(__drm_atomic_helper_plane_reset) has been added
for linking a plane with its state and resetting the core
properties(alpha, rotation, etc.) to their default values.
Use that instead of duplicating the logic.
__drm_atomic_helper_plane_reset initializes the alpha property to its
max value, which is defined by the drm core as DRM_BLEND_ALPHA_OPAQUE,
so nothing changes regarding the alpha value.
Acked-by: Boris Brezillon <boris.brezillon@bootlin.com>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180804161530.12275-5-alexandru-cosmin.gheorghe@arm.com
There are a lot of drivers that subclass drm_plane_state, all of them
duplicate the code that links together the plane with plane_state.
On top of that, drivers that enable core properties also have to
duplicate the code for initializing the properties to their default
values, which in all cases are the same as the defaults from core.
Change since v1:
- Make it consistent with the other helpers and require that both
plane and state not be NULL, suggested by Boris Brezillon and
Philipp Zabel.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180804161530.12275-2-alexandru-cosmin.gheorghe@arm.com
The next patch in this series will have to make the definition of
irq_cpustat_t available to entering_irq().
Inclusion of asm/hardirq.h into asm/apic.h would cause circular header
dependencies like
asm/smp.h
asm/apic.h
asm/hardirq.h
linux/irq.h
linux/topology.h
linux/smp.h
asm/smp.h
or
linux/gfp.h
linux/mmzone.h
asm/mmzone.h
asm/mmzone_64.h
asm/smp.h
asm/apic.h
asm/hardirq.h
linux/irq.h
linux/irqdesc.h
linux/kobject.h
linux/sysfs.h
linux/kernfs.h
linux/idr.h
linux/gfp.h
and others.
This causes compilation errors because of the header guards becoming
effective in the second inclusion: symbols/macros that had been defined
before wouldn't be available to intermediate headers in the #include chain
anymore.
A possible workaround would be to move the definition of irq_cpustat_t
into its own header and include that from both, asm/hardirq.h and
asm/apic.h.
However, this wouldn't solve the real problem, namely asm/harirq.h
unnecessarily pulling in all the linux/irq.h cruft: nothing in
asm/hardirq.h itself requires it. Also, note that there are some other
archs, like e.g. arm64, which don't have that #include in their
asm/hardirq.h.
Remove the linux/irq.h #include from x86' asm/hardirq.h.
Fix resulting compilation errors by adding appropriate #includes to *.c
files as needed.
Note that some of these *.c files could be cleaned up a bit wrt. to their
set of #includes, but that should better be done from separate patches, if
at all.
Signed-off-by: Nicolai Stange <nstange@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
This patch implement the necessary functions to compute and add CRCs
entries:
- Implement the set_crc_source() callback.
- Compute CRC using crc32 on the visible part of the framebuffer.
- Use ordered workqueue per output to compute and add CRC at the end
of a vblank.
- Use appropriate synchronization methods since the CRC computation must
be atomic wrt the generated vblank event for a given atomic update, by
using spinlock across atomic_begin/atomic_flush to wrap the event
handling code completely and match the flip event with the CRC.
Since vkms_crc_work_handle() can sleep, spinlock can't be acquired
while accessing vkms_output->primary_crc to compute CRC.
To make sure the data is updated and released without conflict with
the vkms_crc_work_handle(), the work_struct is flushed @crtc_destroy
and the data is updated before scheduling the work handle again, as
follow:
* CRC data update:
1- store vkms_crc_data {fb, src} per plane_state
2- @plane_duplicate_state -> allocate vkms_crc_data
3- during atomic commit (@atomic_update) ->
a) copy {fb, src} to plane_state->crc_data
b) get reference to fb,
3- @plane_destroy_state -> a) if (fb refcount) remove reference to fb
b) deallocate crc_data
* Atomic Commit:
1- vkms_plane_atomic_check
2- vkms_prepare_fb -> vmap vkms_gem_obj->vaddr
3- atomic_begin -> hold crc spinlock
4- atomic_plane_update -> a) update vkms_output->primary_crc
b) get reference to fb
5- atomic_flush -> a) send vblank event while holding event_lock
b) release crc spinlock
* hrtimer regular callback:
1- hold crc spinlock
2- drm_crtc_handle_vblank()
3- queue vkms_crc_work_handle
4- release crc spinlock
* cleanup:
1- @cleanup_fb ->vunmap vkms_gem_obj->vaddr
2- @crtc_destroy -> flush work struct
3- @plane_destroy -> a) if (fb refcount) remove reference to fb
b) deallocate crc_data
Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
[seanpaul fixed typo in vkms_crtc s/vblamk/vblank/]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/b948327f48c3e70ab232b4a0848ee6d033b26484.1533171495.git.hamohammed.sa@gmail.com
[Why]
VGA sometimes has trouble retrieving the EDID on very long cables, KVM
switches, or old displays.
[How]
Only require EDID read for HDMI and DVI and exempt other types (DP,
VGA). We currently don't support VGA but if anyone adds support in the
future this might get overlooked.
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Suggested-by: Michel Dänzer <michel@daenzer.net>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.
Ref- commit 1c8f422059 ("mm: change return type to vm_fault_t")
Previously vm_insert_mixed() returns err which driver
mapped into VM_FAULT_* type. The new function
vmf_insert_mixed() will replace this inefficiency by
returning VM_FAULT_* type.
vmf_error() is the newly introduce inline function
in 4.17-rc6.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We don't have proper watermark NV12 support on ICL due to differences
in how it should be implemented. In commit 234059da0f
("drm/i915/icl: NV12 y-plane ddb is not in same plane") we avoided
writing the non-existent PLANE_NV12_BUF_CFG registers but we forgot to
also avoid them on the hardware state readout. While the code is still
not correct, at least now we can avoid unclaimed register error
messages when dealing with RGB formats, which makes CI happier.
Also add some FIXME comments in order to make it even more clear that
there's still work to do.
References: commit 234059da0f ("drm/i915/icl: NV12 y-plane ddb is
not in same plane")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180801004614.22149-1-paulo.r.zanoni@intel.com
Move the non-DT configuration of the TDA998x into tda998x_create()
so that we do all setup in one place.
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
This fits better with the drm_bridge callbacks for when this
driver becomes a drm_bridge.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Peter Rosin <peda@axentia.se>
[edited by rmk to just split the tda998x_encoder_dpms() function
and restore the double-disable protection we originally had,
preserving original behaviour.]
Tested-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
if a context is a restore inhibit context, gfx hw only load the first page
for ring context, so we only need to copy from guest the 1 page too.
v3: use "return" instead of "goto" for inhibit case. (zhenyu wang)
v2: move judgement of restore inhibit to a macro in mmio_context.h
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Acked-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
MI_NOOP is a common command appearing in almost all command buffers, put it
into a fastpath can improve perfomance, especially in command buffers
contains lots of MI_NOOPs (0s).
Take glmark2 as an example, 3% performance increase is observed after
introduced this patch. Meanwhile, in case where abundant in MI_NOOPs,
up to 12% performance increase is measured.
v2: use lowercase for index of MI_NOOP in cmd_info (zhenyu wang)
Signed-off-by: Li Weinan <weinan.z.li@intel.com>
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This patch fixed the error when do not configure CONFIG_X86, otherwise, below
error will be encountered.
All errors (new ones prefixed by >>):
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: In function 'ttm_set_pages_caching':
>> drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:272:7: error: implicit declaration of function 'set_pages_array_uc'; did you mean
+'ttm_set_pages_array_uc'? [-Werror=implicit-function-declaration]
r = set_pages_array_uc(pages, cpages);
^~~~~~~~~~~~~~~~~~
ttm_set_pages_array_uc
cc1: some warnings being treated as errors
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
With this conversion, rockchip_drm_fb_resume() and
rockchip_drm_fb_suspend() will not be used anymore.
Both of these functions can be removed.
Also, in struct rockchip_drm_private state will not be
used anymore. So this can be removed forever.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Co-Developed-by: Ajit Negi <ajitn.linux@gmail.com>
[changed to Co-Developed-by, according to process/submitting-patches.rst]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180731203430.GA30136@jordon-HP-15-Notebook-PC
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
with this conversion, the remaining member of struct
imx_drm_device, state, will be no more useful and it
could be removed forever.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Signed-off-by: Ajit Negi <ajitn.linux@gmail.com>
[p.zabel@pengutronix.de: rebased onto drm-next, updated commit message]
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This set of changes migrates Armada DRM from legacy modeset to atomic
modeset. This is everything from the "Transition Armada DRM planes to
atomic state" and "Finish Armada DRM transition to atomic modeset"
patch sets as posted on drm-devel, excluding the "Finish Armada DRM DT
support" series.
These series did not evoke any comments - if there are any, these can
be addressed via follow up patches.
Developed and tested on Dove Cubox with xf86-video-armada including the
overlay plane, and also tested with the tools in libdrm.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180730110543.GA30664@rmk-PC.armlinux.org.uk
A bit larger this time around, due to introduction of "dpu1" support
for the display controller in sdm845 and beyond. This has been on
list and undergoing refactoring since Feb (going from ~110kloc to
~30kloc), and all my review complaints have been addressed, so I'd be
happy to see this upstream so further feature work can procede on top
of upstream.
Also includes the gpu coredump support, which should be useful for
debugging gpu crashes. And various other misc fixes and such.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGv-8y3zguY0Mj1vh=o+vrv_bJ8AwZ96wBXYPvMeQT2XcA@mail.gmail.com
idx can be indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.
This issue was detected with the help of Smatch:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:408 amdgpu_set_pp_force_state()
warn: potential spectre issue 'data.states'
Fix this by sanitizing idx before using it to index data.states
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
