Chris Wilson
33883310cd
drm/i915/selftests: Unroll the CS frequency loop
...
Having noticed that MI_BB_START is incurring a memory stall (see the
correlation with uncore frequency), we have to unroll the loop in order
to diminish the impact of the MI_BB_START on the instruction throughput.
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/20200421171351.19575-1-chris@chris-wilson.co.uk
2020-04-21 20:48:45 +01:00
Linus Torvalds
189522da8b
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
...
Pull virtio fixes and cleanups from Michael Tsirkin:
- Some bug fixes
- Cleanup a couple of issues that surfaced meanwhile
- Disable vhost on ARM with OABI for now - to be fixed fully later in
the cycle or in the next release.
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (24 commits)
vhost: disable for OABI
virtio: drop vringh.h dependency
virtio_blk: add a missing include
virtio-balloon: Avoid using the word 'report' when referring to free page hinting
virtio-balloon: make virtballoon_free_page_report() static
vdpa: fix comment of vdpa_register_device()
vdpa: make vhost, virtio depend on menu
vdpa: allow a 32 bit vq alignment
drm/virtio: fix up for include file changes
remoteproc: pull in slab.h
rpmsg: pull in slab.h
virtio_input: pull in slab.h
remoteproc: pull in slab.h
virtio-rng: pull in slab.h
virtgpu: pull in uaccess.h
tools/virtio: make asm/barrier.h self contained
tools/virtio: define aligned attribute
virtio/test: fix up after IOTLB changes
vhost: Create accessors for virtqueues private_data
vdpasim: Return status in vdpasim_get_status
...
2020-04-21 12:27:18 -07:00
Russell King
4f39467e52
Update rmk's email address in various drivers
...
Globally update my email address in six files scattered through the
tree.
Acked-by: Sam Ravnborg <sam@ravnborg.org >
Acked-by: Hans Verkuil <hverkuil-cisco@xs4all.nl >
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk >
2020-04-21 17:50:09 +01:00
Chris Wilson
bd3ec9e758
drm/i915/gt: Poison residual state [HWSP] across resume.
...
Since we may lose the content of any buffer when we relinquish control
of the system (e.g. suspend/resume), we have to be careful not to rely
on regaining control. A good method to detect when we might be using
garbage is by always injecting that garbage prior to first use on
load/resume/etc.
v2: Drop sanitize callback on cleanup
v3: Move seqno reset to timeline enter, so we reset all timelines.
However, this is done on every activation during runtime and not reset.
The similar level of paranoia we apply to correcting context state after
a period of inactivity.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Venkata Ramana Nayana <venkata.ramana.nayana@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200421092504.7416-1-chris@chris-wilson.co.uk
2020-04-21 16:27:39 +01:00
Chris Wilson
cf9ba27840
drm/i915/selftests: Disable C-states when measuring RPS frequency response
...
Let's isolate the impact of cpu frequency selection on determing the GPU
throughput in response to selection of RPS frequencies.
For real systems, we do have to be concerned with the impact of
integrating c-states, p-states and rp-states, but for the sake of
proving whether or not RPS works, one baby step at a time.
For the record, as one would hope, it does not seem to impact on the
measured performance, but we do it anyway to reduce the number of
variables. Later, we can extend the testing to encourage the the
cpu/pkg to try and sleep while the GPU is busy.
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/20200421142236.8614-1-chris@chris-wilson.co.uk
Link: https://patchwork.freedesktop.org/patch/msgid/20200421142236.8614-1-chris@chris-wilson.co.uk
2020-04-21 16:24:34 +01:00
Chris Wilson
4ea6b1c456
drm/i915/selftests: Show the full scaling curve on failure
...
If we detect that the RPS end points do not scale perfectly, take the
time to measure all the in between values as well. We are aborting the
test, so we might as well spend the available time gathering critical
debug information instead.
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/20200421124636.22554-1-chris@chris-wilson.co.uk
2020-04-21 16:24:34 +01:00
Chris Wilson
74f103928d
drm/i915/selftests: Show the pstate limits on any failure to reset min
...
We want to see the pstate limits whenever we fail to set the minimum
frequency as that may help for debugging.
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/20200420203040.8984-1-chris@chris-wilson.co.uk
2020-04-21 09:39:35 +01:00
Pankaj Bharadiya
007ff34e61
drm/i915/display/vlv_dsi: Prefer drm_WARN_ON over WARN_ON
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
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/20200406112800.23762-14-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 11:23:17 +03:00
Pankaj Bharadiya
e278f07679
drm/i915/display/overlay: Prefer drm_WARN_ON over WARN_ON
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
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/20200406112800.23762-11-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 10:54:41 +03:00
Pankaj Bharadiya
8d641574f3
drm/i915/display/global_state: Prefer drm_WARN* over WARN*
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
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/20200406112800.23762-10-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 10:54:28 +03:00
Pankaj Bharadiya
a7f2ad3929
drm/i915/display/frontbuffer: Prefer drm_WARN_ON over WARN_ON
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
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/20200406112800.23762-9-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 10:54:22 +03:00
Pankaj Bharadiya
4ad53ededf
drm/i915/display/dpll_mgr: Prefer drm_WARN_ON over WARN_ON
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct drm_device
pointer can be extracted.
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/20200406112800.23762-8-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 10:53:53 +03:00
Souptick Joarder
871c60156d
drm/gma500: Remove dead code
...
These are dead code since 3.7. If there is no plan to use them further,
these can be removed forever.
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com >
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1587406337-32317-1-git-send-email-jrdr.linux@gmail.com
2020-04-21 09:02:29 +02:00
Pankaj Bharadiya
ce04ecd9cf
drm/i915/display/display: Prefer drm_WARN_ON over WARN_ON
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON at places where struct drm_device
pointer can be extracted.
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/20200406112800.23762-5-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 09:50:40 +03:00
Pankaj Bharadiya
8b4f2137cc
drm/i915/display/ddi: Prefer drm_WARN* over WARN*
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN* over WARN* calls.
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/20200406112800.23762-4-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 09:49:54 +03:00
Pankaj Bharadiya
1e6850ee4c
drm/i915/display/atomic_plane: Prefer drm_WARN_ON over WARN_ON
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
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/20200406112800.23762-3-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 09:49:30 +03:00
Pankaj Bharadiya
61198fe1bf
drm/i915/display/icl_dsi: Prefer drm_WARN_ON over WARN_ON
...
struct drm_device specific drm_WARN* macros include device information
in the backtrace, so we know what device the warnings originate from.
Prefer drm_WARN_ON over WARN_ON.
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/20200406112800.23762-2-pankaj.laxminarayan.bharadiya@intel.com
2020-04-21 09:49:10 +03:00
Jani Nikula
11ebc2321b
drm/i915/audio: fix compressed_bpp check
...
The early check for compressed_bpp being zero is too early, as it is hit
also when DSC is not enabled. Move the checks down to where the values
are actually needed. This is a paranoid check for a situation that
should not happen, so we don't really care about handling it gracefully
apart from not oopsing.
Fixes: 48b8b04c79https://gitlab.freedesktop.org/drm/intel/-/issues/1750
Cc: Anshuman Gupta <anshuman.gupta@intel.com >
Cc: Uma Shankar <uma.shankar@intel.com >
Reviewed-by: Uma Shankar <uma.shankar@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200420131632.23283-1-jani.nikula@intel.com
2020-04-21 09:38:04 +03:00
Jani Nikula
81b55ef1f4
drm/i915: drop a bunch of superfluous inlines
...
Remove a number of inlines from .c files, and let the compiler decide
what's best. There's more to do, but need to start somewhere, and need
to start setting the example.
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/20200420140438.14672-2-jani.nikula@intel.com
2020-04-21 09:31:37 +03:00
Jani Nikula
3c3041149c
drm/i915/hdmi: remove unused intel_hdmi_hdcp2_protocol()
...
Unused, hiding from the compiler warnings behind the inline keyword.
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/20200420140438.14672-1-jani.nikula@intel.com
2020-04-21 09:27:24 +03:00
YueHaibing
1cf6c1a74e
drm/gma500: remove unused variable 'hdmi_ids'
...
drivers/gpu/drm/gma500/oaktrail_hdmi.c:676:35: warning: ‘hdmi_ids’ defined but not used [-Wunused-const-variable=]
static const struct pci_device_id hdmi_ids[] = {
^~~~~~~~
It is never used, remove it.
Reported-by: Hulk Robot <hulkci@huawei.com >
Signed-off-by: YueHaibing <yuehaibing@huawei.com >
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417101032.8140-1-yuehaibing@huawei.com
2020-04-21 08:15:03 +02:00
Geert Uytterhoeven
add0aff201
drm: Fix misspellings of "Analog Devices"
...
According to https://www.analog.com/ , the company name is spelled
"Analog Devices".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be >
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Link: https://patchwork.freedesktop.org/patch/msgid/20200416103058.15269-4-geert+renesas@glider.be
2020-04-21 08:15:03 +02:00
Matt Roper
89e01caac6
drm/i915: Use single set of AUX powerwell ops for gen11+
...
AUX power wells sometimes need additional handling besides just
programming the specific power well registers:
* Type-C PHY's also require additional Type-C register programming
* ICL combo PHY's require additional workarounds
* TGL & EHL combo PHY's can be treated like any other power well
Today we have dedicated aux ops for the ICL combo PHY and Type-C cases.
This works fine, but means that when a new platform shows up with
identical general power well handling, but different types of PHYs on
its outputs, we have to define an entire new power well table for that
platform and can't just re-use the table from the earlier platform -- as
an example, see ehl_power_wells[], which is a subset of
icl_power_wells[], *except* that we need to specify different AUX ops
for the third display.
If we instead create a single set of top-level aux ops that will check
the PHY type and then dispatch to the appropriate handlers, we can get
more reuse out of our power well definitions. This allows us to
immediately eliminate ehl_power_wells[] and simply reuse the ICL table;
if future platforms follow the same general power well assignments as
either ICL or TGL, we'll be able to re-use those tables in the same way.
Note that I've only changed ICL+ platforms over to using the new icl_aux
ops; at this point it's unlikely that we'll have any new platforms that
re-use gen9 or earlier power well configurations.
v2:
- ICL_AUX_PW_TO_PHY() won't return the proper PHY for TBT AUX power
wells. But we know those wells will only used on Type-C outputs
anyway, so we can just check is is_tc_tbt flag in the condition.
(Jose).
Cc: José Roberto de Souza <jose.souza@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/20200415233435.3064257-2-matthew.d.roper@intel.com
2020-04-20 20:48:10 -07:00
Jitao Shi
6bd4763fd5
drm/mediatek: set dpi pin mode to gpio low to avoid leakage current
...
Config dpi pins mode to output and pull low when dpi is disabled.
Aovid leakage current from some dpi pins (Hsync Vsync DE ... ).
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com >
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org >
2020-04-21 06:31:53 +08:00
Mauro Carvalho Chehab
0c1bc6b845
docs: filesystems: fix renamed references
...
Some filesystem references got broken by a previous patch
series I submitted. Address those.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org >
Acked-by: David Sterba <dsterba@suse.com > # fs/affs/Kconfig
Link: https://lore.kernel.org/r/57318c53008dbda7f6f4a5a9e5787f4d37e8565a.1586881715.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net >
2020-04-20 15:45:22 -06:00
Mauro Carvalho Chehab
72ef5e52b3
docs: fix broken references to text files
...
Several references got broken due to txt to ReST conversion.
Several of them can be automatically fixed with:
scripts/documentation-file-ref-check --fix
Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org > # hwtracing/coresight/Kconfig
Reviewed-by: Paul E. McKenney <paulmck@kernel.org > # memory-barrier.txt
Acked-by: Alex Shi <alex.shi@linux.alibaba.com > # translations/zh_CN
Acked-by: Federico Vaga <federico.vaga@vaga.pv.it > # translations/it_IT
Acked-by: Marc Zyngier <maz@kernel.org > # kvm/arm64
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org >
Link: https://lore.kernel.org/r/6f919ddb83a33b5f2a63b6b5f0575737bb2b36aa.1586881715.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net >
2020-04-20 15:35:59 -06:00
Xiyu Yang
e07c7606a0
drm/i915/selftests: Fix i915_address_space refcnt leak
...
igt_ppgtt_pin_update() invokes i915_gem_context_get_vm_rcu(), which
returns a reference of the i915_address_space object to "vm" with
increased refcount.
When igt_ppgtt_pin_update() returns, "vm" becomes invalid, so the
refcount should be decreased to keep refcount balanced.
The reference counting issue happens in two exception handling paths of
igt_ppgtt_pin_update(). When i915_gem_object_create_internal() returns
IS_ERR, the refcnt increased by i915_gem_context_get_vm_rcu() is not
decreased, causing a refcnt leak.
Fix this issue by jumping to "out_vm" label when
i915_gem_object_create_internal() returns IS_ERR.
Fixes: a4e7ccdac3xiyuyang19@fudan.edu.cn >
Signed-off-by: Xin Tan <tanxin.ctf@gmail.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/1587361342-83494-1-git-send-email-xiyuyang19@fudan.edu.cn
2020-04-20 20:17:50 +01:00
Chris Wilson
e42a969e72
drm/i915/selftests: Exercise dynamic reclocking with RPS
...
After having testing all the RPS controls individually, we need to take
a step back and check how our RPS worker integrates them to perform
dynamic GPU reclocking. So do that by submitting a spinner and wait and
see what happens.
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/20200420172739.11620-6-chris@chris-wilson.co.uk
2020-04-20 20:08:07 +01:00
Chris Wilson
6b36fc9442
drm/i915/selftests: Show the pcode frequency table on error
...
If we encounter an error while scaling, read back the frequency tables
from the pcu.
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/20200420172739.11620-5-chris@chris-wilson.co.uk
2020-04-20 20:08:07 +01:00
Chris Wilson
0eaccc4b18
drm/i915/selftests: Split RPS frequency measurement
...
Split the frequency measurement into two modes, so that we can judge the
impact of the llc setup on top of the pure CS frequency scaling.
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/20200420172739.11620-4-chris@chris-wilson.co.uk
2020-04-20 20:08:07 +01:00
Chris Wilson
9938ee2e63
drm/i915/selftests: Check RPS controls
...
Check that the GPU does respond to our RPS frequency requests by setting
our desired frequency.
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/20200420172739.11620-3-chris@chris-wilson.co.uk
2020-04-20 20:08:06 +01:00
Chris Wilson
a740f5c5f6
drm/i915/selftests: Skip energy consumption tests if not controlling freq
...
If we can not manipulate the frequency with RPS, then comparing min/max
power consumption is pointless / misleading. We will leave the warning
about not being able to control the frequency selection via RPS to other
tests so as not to confuse this more specialised check.
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/20200420172739.11620-2-chris@chris-wilson.co.uk
2020-04-20 20:08:06 +01:00
Chris Wilson
4ba74e53ad
drm/i915/selftests: Verify frequency scaling with RPS
...
One of the core tenents of reclocking the GPU is that its throughput
scales with the clock frequency. We can observe this by incrementing a
loop counter on the GPU, and compare the different execution rates at
the notional RPS frequencies.
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/20200420172739.11620-1-chris@chris-wilson.co.uk
2020-04-20 20:08:06 +01:00
Ville Syrjälä
f0617ff0b8
drm/i915: Push MST link retraining to the hotplug work
...
We shouldn't try to do link retraining from the short hpd handler.
We can't take any modeset locks there so this is racy as hell.
Push the whole thing into the hotplug work like we do with SST.
We'll just have to adjust the SST retraining code to deal with
the MST encoders and multiple pipes.
TODO: I have a feeling we should just rip this all out and
do a full modeset instead. Stuff like port sync and the tgl+
MST master transcoder stuff maybe doesn't work well if we
try to retrain without following the proper modeset sequence.
So far haven't done any actual tests to confirm that though.
Cc: Lyude Paul <lyude@redhat.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417152734.464-2-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com >
2020-04-20 21:21:11 +03:00
Ville Syrjälä
3c0ec2c2d5
drm/i915: Flatten intel_dp_check_mst_status() a bit
...
Make intel_dp_check_mst_status() somewhat legible by humans.
Note that the return value of drm_dp_mst_hpd_irq() is always
either 0 or -ENOMEM, and we never did anything with the latter
so we can just ignore the whole thing.
We can also get rid of the direct drm_dp_mst_topology_mgr_set_mst(false)
call since returning -EINVAL causes the caller to do the very same call
for us.
Cc: Lyude Paul <lyude@redhat.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417152734.464-1-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com >
2020-04-20 21:21:11 +03:00
Ville Syrjälä
eed22a46b9
drm/i915: Pass encoder all the way to intel_ddi_transcoder_func_reg_val_get()
...
Pass the encoder all the way down to
intel_ddi_transcoder_func_reg_val_get(). Allows us eliminate the
intel_ddi_get_crtc_encoder() eyesore.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417134720.16654-4-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Acked-by: Jani Nikula <jani.nikula@intel.com >
2020-04-20 21:21:10 +03:00
Ville Syrjälä
7c2fedd760
drm/i915: Push TRANS_DDI_FUNC_CTL into the encoder->enable() hook
...
Push the TRANS_DDI_FUNC_CTL into the encoder enable hook. The disable
is already there, and as a followup will enable us to pass the encoder
all the way down.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417134720.16654-3-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Acked-by: Jani Nikula <jani.nikula@intel.com >
2020-04-20 21:21:10 +03:00
Ville Syrjälä
c38730987b
drm/i915: Move the TRANS_DDI_FUNC_CTL enable to a later point
...
No reason that I can see why we should enable TRANS_DDI_FUNC_CTL
before we set up the watermarks of configure the mbus stuff.
In fact reordering these seems to match the bspec sequence better,
and crucially will allow us to push the TRANS_DDI_FUNC_CTL enable
into the encoder enable hook as a followup.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417134720.16654-2-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk >
Acked-by: Jani Nikula <jani.nikula@intel.com >
2020-04-20 21:21:10 +03:00
Ville Syrjälä
02a715c371
drm/i915: Pass encoder to intel_ddi_enable_pipe_clock()
...
Since intel_ddi_enable_pipe_clock() was pushed down into the
encoder hooks we can pass on the encoder instead of having
to use intel_ddi_get_crtc_encoder().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417134720.16654-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Acked-by: Jani Nikula <jani.nikula@intel.com >
2020-04-20 21:20:58 +03:00
Lyude Paul
d082119f42
drm/i915/dpcd_bl: Unbreak enable_dpcd_backlight modparam
...
Looks like I accidentally made it so you couldn't force DPCD backlight
support on, whoops. Fix that.
Signed-off-by: Lyude Paul <lyude@redhat.com >
Fixes: 17f5d57915ajax@redhat.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200413214407.1851002-1-lyude@redhat.com
(cherry picked from commit d7fb38ae36rodrigo.vivi@intel.com >
2020-04-20 10:12:58 -07:00
Jani Nikula
a05b289917
drm/i915: fix Sphinx build duplicate label warning
...
Fix the warning caused by enabling the autosectionlabel extension in the
kernel Sphinx build:
Documentation/gpu/i915.rst:610: WARNING: duplicate label
gpu/i915:layout, other instance in Documentation/gpu/i915.rst
The autosectionlabel extension adds labels to each section title for
cross-referencing, but forbids identical section titles in a
document. With kernel-doc, this includes sections titles in the included
kernel-doc comments.
In the warning message, Sphinx is unable to reference the labels in
their true locations in the kernel-doc comments in source. In this case,
there's "Layout" sections in both gt/intel_workarounds.c and
i915_reg.h. Rename the section in the latter to "File Layout".
Fixes: 58ad30cf91chris@chris-wilson.co.uk >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200417130109.12791-1-jani.nikula@intel.com
(cherry picked from commit 27be41de45rodrigo.vivi@intel.com >
2020-04-20 10:12:53 -07:00
José Roberto de Souza
1239902875
drm/i915/display: Load DP_TP_CTL/STATUS offset before use it
...
Right now dp.regs.dp_tp_ctl/status are only set during the encoder
pre_enable() hook, what is causing all reads and writes to those
registers to go to offset 0x0 before pre_enable() is executed.
So if i915 takes the BIOS state and don't do a modeset any following
link retraing will fail.
In the case that i915 needs to do a modeset, the DDI disable sequence
will write to a wrong register not disabling DP 'Transport Enable' in
DP_TP_CTL, making a HDMI modeset in the same port/transcoder to
not light up the monitor.
So here for GENs older than 12, that have those registers fixed at
port offset range it is loading at encoder/port init while for GEN12
it will keep setting it at encoder pre_enable() and during HW state
readout.
Fixes: 4444df6e20matthew.d.roper@intel.com >
Cc: Lucas De Marchi <lucas.demarchi@intel.com >
Signed-off-by: José Roberto de Souza <jose.souza@intel.com >
Reviewed-by: Matt Roper <matthew.d.roper@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200414230442.262092-1-jose.souza@intel.com
(cherry picked from commit edcb9028d6rodrigo.vivi@intel.com >
2020-04-20 10:12:46 -07:00
Matt Roper
335f62e760
drm/i915/tgl: TBT AUX should use TC power well ops
...
As on ICL, we want to use the Type-C aux handlers for the TBT aux wells
to ensure the DP_AUX_CH_CTL_TBT_IO flag is set properly.
Fixes: 656409bbafjose.souza@intel.com >
Cc: Imre Deak <imre.deak@intel.com >
Signed-off-by: Matt Roper <matthew.d.roper@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200415233435.3064257-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com >
(cherry picked from commit 3cbdb97564rodrigo.vivi@intel.com >
2020-04-20 10:12:43 -07:00
Oliver Barta
ced633266b
drm/i915: HDCP: fix Ri prime check done during link check
...
The check was always succeeding even in case of a mismatch due to the
HDCP_STATUS_ENC bit being set. Make sure both bits are actually set.
Signed-off-by: Oliver Barta <oliver.barta@aptiv.com >
Fixes: 2320175febramalingam.c@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200328104100.12162-1-oliver.barta@aptiv.com
(cherry picked from commit 3ffaf56e91rodrigo.vivi@intel.com >
2020-04-20 10:12:40 -07:00
Chris Wilson
e1eb075c50
drm/i915/gt: Update PMINTRMSK holding fw
...
If we use a non-forcewaked write to PMINTRMSK, it does not take effect
until much later, if at all, causing a loss of RPS interrupts and no GPU
reclocking, leaving the GPU running at the wrong frequency for long
periods of time.
Reported-by: Francisco Jerez <currojerez@riseup.net >
Suggested-by: Francisco Jerez <currojerez@riseup.net >
Fixes: 35cc7f32c2chris@chris-wilson.co.uk >
Cc: Francisco Jerez <currojerez@riseup.net >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Andi Shyti <andi.shyti@intel.com >
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Reviewed-by: Andi Shyti <andi.shyti@intel.com >
Reviewed-by: Francisco Jerez <currojerez@riseup.net >
Cc: <stable@vger.kernel.org > # v5.6+
Link: https://patchwork.freedesktop.org/patch/msgid/20200415170318.16771-2-chris@chris-wilson.co.uk
(cherry picked from commit a080bd994crodrigo.vivi@intel.com >
2020-04-20 10:12:36 -07:00
Matt Roper
81fdd7bfeb
drm/i915/tgl: Add Wa_14010477008:tgl
...
Media decompression support should not be advertised on any display
planes for steppings A0-C0.
Bspec: 53273
Fixes: 2dfbf9d287matthew.s.atwood@intel.com >
Signed-off-by: Matt Roper <matthew.d.roper@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200414211118.2787489-3-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com >
(cherry picked from commit dbff5a8db9rodrigo.vivi@intel.com >
2020-04-20 10:12:32 -07:00
Peter Jones
6b7fc6a3e6
Make the "Reducing compressed framebufer size" message be DRM_INFO_ONCE()
...
This was sort of annoying me:
random:~$ dmesg | tail -1
[523884.039227] [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
random:~$ dmesg | grep -c "Reducing the compressed"
47
This patch makes it DRM_INFO_ONCE() just like the similar message
farther down in that function is pr_info_once().
Cc: stable@vger.kernel.org
Signed-off-by: Peter Jones <pjones@redhat.com >
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1745
Link: https://patchwork.freedesktop.org/patch/msgid/20180706190424.29194-1-pjones@redhat.com
[vsyrjala: Rebase due to per-device logging]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
2020-04-20 19:14:59 +03:00
Chris Wilson
f153f6395a
drm/i915/gt: Move the late flush_submission in retire to the end
...
Avoid flushing the submission queue (of others) under the client's
timeline lock, but instead move it to the end so that we may catch more.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/1066
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200420125356.26614-2-chris@chris-wilson.co.uk
2020-04-20 16:56:23 +01:00
Chris Wilson
a95f3ac21d
drm/i915/gem: Remove object_is_locked assertion from unpin_from_display_plane
...
Since moving the obj->vma.list to a spin_lock, and the vm->bound_list to
its vm->mutex, along with tracking shrinkable status under its own
spinlock, we no long require the object to be locked by the caller.
This is fortunate as it appears we can be called with the lock along an
error path in flipping:
<4> [139.942851] WARN_ON(debug_locks && !lock_is_held(&(&((obj)->base.resv)->lock.base)->dep_map))
<4> [139.943242] WARNING: CPU: 0 PID: 1203 at drivers/gpu/drm/i915/gem/i915_gem_domain.c:405 i915_gem_object_unpin_from_display_plane+0x70/0x130 [i915]
<4> [139.943263] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_realtek snd_hda_codec_generic coretemp snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core r8169 lpc_ich snd_pcm realtek prime_numbers [last unloaded: i915]
<4> [139.943347] CPU: 0 PID: 1203 Comm: kms_flip Tainted: G U 5.6.0-gd0fda5c2cf3f1-drmtip_474+ #1
<4> [139.943363] Hardware name: /D510MO, BIOS MOPNV10J.86A.0311.2010.0802.2346 08/02/2010
<4> [139.943589] RIP: 0010:i915_gem_object_unpin_from_display_plane+0x70/0x130 [i915]
<4> [139.943589] Code: 85 28 01 00 00 be ff ff ff ff 48 8d 78 60 e8 d7 9b f0 e2 85 c0 75 b9 48 c7 c6 50 b9 38 c0 48 c7 c7 e9 48 3c c0 e8 20 d4 e9 e2 <0f> 0b eb a2 48 c7 c1 08 bb 38 c0 ba 0a 01 00 00 48 c7 c6 88 a3 35
<4> [139.943589] RSP: 0018:ffffb774c0603b48 EFLAGS: 00010282
<4> [139.943589] RAX: 0000000000000000 RBX: ffff9a142fa36e80 RCX: 0000000000000006
<4> [139.943589] RDX: 000000000000160d RSI: ffff9a142c1a88f8 RDI: ffffffffa434a64d
<4> [139.943589] RBP: ffff9a1410a513c0 R08: ffff9a142c1a88f8 R09: 0000000000000000
<4> [139.943589] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9a1436ee94b8
<4> [139.943589] R13: 0000000000000001 R14: 00000000ffffffff R15: ffff9a1410960000
<4> [139.943589] FS: 00007fc73a744e40(0000) GS:ffff9a143da00000(0000) knlGS:0000000000000000
<4> [139.943589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4> [139.943589] CR2: 00007fc73997e098 CR3: 000000002f5fe000 CR4: 00000000000006f0
<4> [139.943589] Call Trace:
<4> [139.943589] intel_pin_and_fence_fb_obj+0x1c9/0x1f0 [i915]
<4> [139.943589] intel_plane_pin_fb+0x3f/0xd0 [i915]
<4> [139.943589] intel_prepare_plane_fb+0x13b/0x5c0 [i915]
<4> [139.943589] drm_atomic_helper_prepare_planes+0x85/0x110
<4> [139.943589] intel_atomic_commit+0xda/0x390 [i915]
<4> [139.943589] drm_atomic_helper_page_flip+0x9c/0xd0
<4> [139.943589] ? drm_event_reserve_init+0x46/0x60
<4> [139.943589] drm_mode_page_flip_ioctl+0x587/0x5d0
This completes the symmetry lost in commit 8b1c78e06ehttps://gitlab.freedesktop.org/drm/intel/-/issues/1743
Fixes: 8b1c78e06echris@chris-wilson.co.uk >
Cc: Matthew Auld <matthew.auld@intel.com >
Cc: Andi Shyti <andi.shyti@intel.com >
Cc: <stable@vger.kernel.org > # v5.6+
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200420125356.26614-1-chris@chris-wilson.co.uk
2020-04-20 16:23:24 +01:00
Thomas Zimmermann
f0adbc382b
drm/ast: Allocate initial CRTC state of the correct size
...
The ast driver inherits from DRM's CRTC state, but still uses the atomic
helper for struct drm_crtc_funcs.reset, drm_atomic_helper_crtc_reset().
The helper only allocates enough memory for the core CRTC state. That
results in an out-ouf-bounds access when duplicating the initial CRTC
state. Simplified backtrace shown below:
[ 21.469321] ==================================================================
[ 21.469434] BUG: KASAN: slab-out-of-bounds in ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469445] Read of size 8 at addr ffff888036c1c5f8 by task systemd-udevd/382
[ 21.469451]
[ 21.469464] CPU: 2 PID: 382 Comm: systemd-udevd Tainted: G E 5.5.0-rc6-1-default+ #214
[ 21.469473] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN FIRE X2270 M2, BIOS 2.05 07/01/2010
[ 21.469480] Call Trace:
[ 21.469501] dump_stack+0xb8/0x110
[ 21.469528] print_address_description.constprop.0+0x1b/0x1e0
[ 21.469557] ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469581] ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469597] __kasan_report.cold+0x1a/0x35
[ 21.469640] ? ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469665] kasan_report+0xe/0x20
[ 21.469693] ast_crtc_atomic_duplicate_state+0x84/0x100 [ast]
[ 21.469733] drm_atomic_get_crtc_state+0xbf/0x1c0
[ 21.469768] __drm_atomic_helper_set_config+0x81/0x5a0
[ 21.469803] ? drm_atomic_plane_check+0x690/0x690
[ 21.469843] ? drm_client_rotation+0xae/0x240
[ 21.469876] drm_client_modeset_commit_atomic+0x230/0x390
[ 21.469888] ? __mutex_lock+0x8f0/0xbe0
[ 21.469929] ? drm_client_firmware_config.isra.0+0xa60/0xa60
[ 21.469948] ? drm_client_modeset_commit_force+0x28/0x230
[ 21.470031] ? memset+0x20/0x40
[ 21.470078] drm_client_modeset_commit_force+0x90/0x230
[ 21.470110] drm_fb_helper_restore_fbdev_mode_unlocked+0x5f/0xc0
[ 21.470132] drm_fb_helper_set_par+0x59/0x70
[ 21.470155] fbcon_init+0x61d/0xad0
[ 21.470185] ? drm_fb_helper_restore_fbdev_mode_unlocked+0xc0/0xc0
[ 21.470232] visual_init+0x187/0x240
[ 21.470266] do_bind_con_driver+0x2e3/0x460
[ 21.470321] do_take_over_console+0x20a/0x290
[ 21.470371] do_fbcon_takeover+0x85/0x100
[ 21.470402] register_framebuffer+0x2fd/0x490
[ 21.470425] ? kzalloc.constprop.0+0x10/0x10
[ 21.470503] __drm_fb_helper_initial_config_and_unlock+0xf2/0x140
[ 21.470533] drm_fbdev_client_hotplug+0x162/0x250
[ 21.470563] drm_fbdev_generic_setup+0xd2/0x155
[ 21.470602] ast_driver_load+0x688/0x850 [ast]
<...>
[ 21.472625] ==================================================================
Allocating enough memory for struct ast_crtc_state in a custom ast CRTC
reset handler fixes the problem.
v2:
* implement according to drm_atomic_helper_crtc_reset()
* update state with __drm_atomic_helper_crtc_reset()
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de >
Fixes: 83be6a3cebdaniel.vetter@ffwll.ch >
Cc: Gerd Hoffmann <kraxel@redhat.com >
Cc: Dave Airlie <airlied@redhat.com >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Cc: Alex Deucher <alexander.deucher@amd.com >
Cc: "Noralf Trønnes" <noralf@tronnes.org >
Cc: Sam Ravnborg <sam@ravnborg.org >
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20200130094012.32140-1-tzimmermann@suse.de
2020-04-20 15:48:23 +02:00
