This bit was fliped on for "syncing dependencies between camera and
graphics". BSpec has no recollection why, and it is causing
unrecoverable GPU hangs with Vulkan compute workloads.
From BSpec, setting bit5 to 0 enables relaxed padding requirements for
buffers, 1D and 2D non-array, non-MSAA, non-mip-mapped linear surfaces;
and *must* be set to 0h on skl+ to ensure "Out of Bounds" case is
suppressed.
Reported-by: Jason Ekstrand <jason@jlekstrand.net>
Suggested-by: Jason Ekstrand <jason@jlekstrand.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110998
Fixes: 8424171e13 ("drm/i915/gen9: h/w w/a: syncing dependencies between camera and graphics")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: denys.kostin@globallogic.com
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.1+
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190904100707.7377-1-chris@chris-wilson.co.uk
(cherry picked from commit 9d7b01e935)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
My attempt at allowing MST to use the higher color depths has
regressed some configurations. Apparently people have setups
where all MST streams will fit into the DP link with 8bpc but
won't fit with higher color depths.
What we really should be doing is reducing the bpc for all the
streams on the same link until they start to fit. But that requires
a bit more work, so in the meantime let's revert back closer to
the old behavior and limit MST to at most 8bpc.
Cc: stable@vger.kernel.org
Cc: Lyude Paul <lyude@redhat.com>
Tested-by: Geoffrey Bennett <gmux22@gmail.com>
Fixes: f147721986 ("drm/i915: Remove the 8bpc shackles from DP MST")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111505
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190828102059.2512-1-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
(cherry picked from commit 75427b2a2b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
- Make ingenic panel type DPI insteado f unknown.
- Fixes for command line parser modes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl1xOnsACgkQ/lWMcqZw
E8O5Gw//fo85tbQwbKH59QwT96oZ/r7DWchQpLz8EJDfxbHgSeAhu6xgJaB/DZ6+
Hqp091OIFHuufXW5Xl7teXixs67ChLrtJc2iokA/RbMnLt7xWtSbf4w1Y3nYJ/p+
kG2kfvjimGQDMB3WL+gUpaRXBD2adc7S0EFsf4VVhVw1CfHG8RYrARtsPMV7SCox
F3d+J6ZHj2zyTZuSeDDg11N/bPrNTLKV7/cCX/cg5hKdDBkK0jfyLMwMqGB6Nd1D
s2kMyjqL7HEJpf6cXTqpWd/Du5fUgKi7sX7UWtW6vyd0IUnCWOUNmY4uRgKFRf2O
YeTH+Qt5gfBdg4vUe4iZLiILfgS9N2p806v3yMQodrXWD47DrXD1NFEQNq0AfIUV
nfyaccU1cgoBts/m9vJOOFgZGu8+b5YCVTdtgUi96o7P4+XZcy/85nE4c/c0fBUK
D30tlrCzqv9zrhotf60atN/eqbiMW4wJycSk4QNx1kFb8R9+ZzQvQN7FfZkO4oiU
qzO9c3fmE7qeHZdAm5g9OzamjOIw5esj7L0kEhczZ/9MU7XnJz2eKrE3SxhT3mdf
r2l5K02q0GZ54KmmhScVOeVAI8B/Fp0An3r7vpsIumPevtgQfLHcj88iT9Q23wZz
y5L9eS77DeZiJftcQB6FzGQ810bl9O24nNByW3+yu46SX+hfLS8=
=cZhy
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2019-09-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v5.3 final:
- Make ingenic panel type DPI insteado f unknown.
- Fixes for command line parser modes.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/606d87b2-1840-c893-eb30-d6c471c9e50a@linux.intel.com
We recently added a kfree() after the end of the loop:
if (retries == RETRIES) {
kfree(reply);
return -EINVAL;
}
There are two problems. First the test is wrong and because retries
equals RETRIES if we succeed on the last iteration through the loop.
Second if we fail on the last iteration through the loop then the kfree
is a double free.
When you're reading this code, please note the break statement at the
end of the while loop. This patch changes the loop so that if it's not
successful then "reply" is NULL and we can test for that afterward.
Cc: <stable@vger.kernel.org>
Fixes: 6b7c3b86f0 ("drm/vmwgfx: fix memory leak when too many retries have occurred")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Let's add some unit tests for the recent bugs we just fixed.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Thomas Graichen <thomas.graichen@gmail.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190827115850.25731-4-mripard@kernel.org
The named modes support has introduced a number of glitches that were in
part due to the fact that the parser will take any string as a named mode.
Since we shouldn't have a lot of options there (and they should be pretty
standard), let's introduce a whitelist of the available named modes so that
the kernel can differentiate between a poorly formed command line and a
named mode.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Thomas Graichen <thomas.graichen@gmail.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190827115850.25731-3-mripard@kernel.org
The command line parser when it has been rewritten introduced a regression
when the only thing on the command line is an option to force the detection
of a connector (such as video=HDMI-A-1:d), which are completely valid.
It's been further broken by the support for the named modes which take
anything that is not a resolution as a named mode.
Let's fix this by running the extra command line option parser on the named
modes if they only take a single character.
Fixes: e08ab74bd4 ("drm/modes: Rewrite the command line parser")
Reported-by: Jernej Škrabec <jernej.skrabec@gmail.com>
Reported-by: Thomas Graichen <thomas.graichen@googlemail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Thomas Graichen <thomas.graichen@gmail.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190827115850.25731-2-mripard@kernel.org
Some extra command line options can be either specified without anything
else on the command line (basically all the force connection options), but
some other are only relevant when matched with a resolution (margin and
interlace).
Let's add a switch to restrict if needed the available option set.
Fixes: e08ab74bd4 ("drm/modes: Rewrite the command line parser")
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Thomas Graichen <thomas.graichen@gmail.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190827115850.25731-1-mripard@kernel.org
- Make qxl reservel the vga ports using vgaargb to prevent switching to vga compatibility mode.
- Fix omap port lookup for SDI output
- Use virtio_max_dma_size to fix an issue with swiotlb.
- Compiler fixes to komeda.
- Add missing of_node_get() call in komeda.
- Reorder the komeda de-init functions.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl1mzmoACgkQ/lWMcqZw
E8P4fQ/8C7oJCASTNG20CenFHo/pdSR8cj1w9RGfSdolzve+2884KSR6I+rmZnY7
68CKAeMvywNmB9ReMhgxhwtJbo7DLYzsQoj/jKpC1SdH93m4XnPDx6aFn1ybVsHF
1KcCy1bT1YmM/a+MwiTqmJJqvYusSrXSsD185TLyD4pZEutpd1AjSrSBjJvZTsbb
t4bjLJuk6czCzvbQOLomjDaOp9J0cbcow4r8GNSDAZS+LeTsuphf/2y++PT6ZzzP
EtC5us9PYCR4ZDNa6Y8kXzahakIyyCTxWCzRw1rH0QbpO+aDtJnCdVX09meEARty
4FJ14qXTTSEZxAe27pNhiqFU0PeKAtC/1TlOGO5aFGz34CdOk+VbzkLZoeYhGwH0
T5by7sM6pQrJC5qdo1K94aPoCZHmqTuQrI+9StuH8JWFGc78SRx3+ODDsDgYv6dp
eaC/KDR9HT799HTbjxo6YyFaOSheegbTw7VIoFW/6Yj8kVBV5nP0cK+vMFKlulv+
a/Ce6OuhPQMOpSK9LmLLI9EeSEQtD57dyW87KbuAh+jrKxnFpwdlKxkw481tkNOS
ftIrBtq+LUPbeZfUCVMvaTqGTmwGqp0njoL3Z4lJOF4E5i/s9fo7jwyjp0+d7UXU
pNEAaq7+8+fxci8jCgVFb9fTgp7iAIZOZr91MVL9CRqC3fJWyco=
=UuWS
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2019-08-28' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v5.3 (rc7?):
- Make qxl reservel the vga ports using vgaargb to prevent switching to vga compatibility mode.
- Fix omap port lookup for SDI output
- Use virtio_max_dma_size to fix an issue with swiotlb.
- Compiler fixes to komeda.
- Add missing of_node_get() call in komeda.
- Reorder the komeda de-init functions.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f187c28b-6279-2c4f-3e53-296ee899133b@linux.intel.com
The de-init routine should be doing the following in order:-
1. Unregister the drm device
2. Shut down the crtcs - failing to do this might cause a connector leakage
See the 'commit 109c4d18e5 ("drm/arm/malidp: Ensure that the crtcs are
shutdown before removing any encoder/connector")'
3. Disable the interrupts
4. Unbind the components
5. Free up DRM mode_config info
Changes from v1:-
1. Re-ordered the header files inclusion
2. Rebased on top of the latest drm-misc-fixes
Signed-off-by:. Ayan Kumar Halder <Ayan.Halder@arm.com>
Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com>
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
Link: https://patchwork.freedesktop.org/patch/327606/
For picasso(adev->pdev->device == 0x15d8)&raven2(adev->rev_id >= 0x8),
firmware is sufficient to support gfxoff.
In commit 98f58ada2d, for picasso&raven2,
return directly and cause gfxoff disabled.
Fixes: 98f58ada2d ("drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible")
Reviewed-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Needs ATPX rather than _PR3 to really turn off the dGPU. This can save
~5W when dGPU is runtime-suspended.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Correct the settings for auto mode and skip the unnecessary
settings for dcefclk and fclk.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Currently, we don't call dma_set_max_seg_size() for i915 because we
intentionally do not limit the segment length that the device supports.
However, this results in a warning being emitted if we try to map
anything larger than SZ_64K on a kernel with CONFIG_DMA_API_DEBUG_SG
enabled:
[ 7.751926] DMA-API: i915 0000:00:02.0: mapping sg segment longer
than device claims to support [len=98304] [max=65536]
[ 7.751934] WARNING: CPU: 5 PID: 474 at kernel/dma/debug.c:1220
debug_dma_map_sg+0x20f/0x340
This was originally brought up on
https://bugs.freedesktop.org/show_bug.cgi?id=108517 , and the consensus
there was it wasn't really useful to set a limit (and that dma-debug
isn't really all that useful for i915 in the first place). Unfortunately
though, CONFIG_DMA_API_DEBUG_SG is enabled in the debug configs for
various distro kernels. Since a WARN_ON() will disable automatic problem
reporting (and cause any CI with said option enabled to start
complaining), we really should just fix the problem.
Note that as me and Chris Wilson discussed, the other solution for this
would be to make DMA-API not make such assumptions when a driver hasn't
explicitly set a maximum segment size. But, taking a look at the commit
which originally introduced this behavior, commit 78c47830a5
("dma-debug: check scatterlist segments"), there is an explicit mention
of this assumption and how it applies to devices with no segment size:
Conversely, devices which are less limited than the rather
conservative defaults, or indeed have no limitations at all
(e.g. GPUs with their own internal MMU), should be encouraged to
set appropriate dma_parms, as they may get more efficient DMA
mapping performance out of it.
So unless there's any concerns (I'm open to discussion!), let's just
follow suite and call dma_set_max_seg_size() with UINT_MAX as our limit
to silence any warnings.
Changes since v3:
* Drop patch for enabling CONFIG_DMA_API_DEBUG_SG in CI. It looks like
just turning it on causes the kernel to spit out bogus WARN_ONs()
during some igt tests which would otherwise require teaching igt to
disable the various DMA-API debugging options causing this. This is
too much work to be worth it, since DMA-API debugging is useless for
us. So, we'll just settle with this single patch to squelch WARN_ONs()
during driver load for users that have CONFIG_DMA_API_DEBUG_SG turned
on for some reason.
* Move dma_set_max_seg_size() call into i915_driver_hw_probe() - Chris
Wilson
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.18+
Link: https://patchwork.freedesktop.org/patch/msgid/20190823205251.14298-1-lyude@redhat.com
(cherry picked from commit acd674af95)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This patch fixes the intel_configure_pps_for_dsc_encoder() function to use
cpu_transcoder instead of encoder->type to select the correct DSC registers
that was wrongly used in the original patch for one DSC register isntance.
Fixes: 7182414e25 ("drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling")
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.0+
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821215950.24223-1-manasi.d.navare@intel.com
(cherry picked from commit d4c61c4a16)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We're not allowed to create new properties after device registration
so for MST connectors we need to either create the max_bpc property
earlier, or we reuse one we already have. Let's do the latter apporach
since the corresponding SST connector already has the prop and its
min/max are correct also for the MST connector.
The problem was highlighted by commit 4f5368b554 ("drm/kms:
Catch mode_object lifetime errors") which results in the following
spew:
[ 1330.878941] WARNING: CPU: 2 PID: 1554 at drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xa0/0xb0 [drm]
...
[ 1330.879008] Call Trace:
[ 1330.879023] drm_property_create+0xba/0x180 [drm]
[ 1330.879036] drm_property_create_range+0x15/0x30 [drm]
[ 1330.879048] drm_connector_attach_max_bpc_property+0x62/0x80 [drm]
[ 1330.879086] intel_dp_add_mst_connector+0x11f/0x140 [i915]
[ 1330.879094] drm_dp_add_port.isra.20+0x20b/0x440 [drm_kms_helper]
...
Cc: stable@vger.kernel.org
Cc: Lyude Paul <lyude@redhat.com>
Cc: sunpeng.li@amd.com
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <sean@poorly.run>
Fixes: 5ca0ef8a56 ("drm/i915: Add max_bpc property for DP MST")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820161657.9658-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
(cherry picked from commit 1b9bd09630)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
For the 40.46 SMU release, they changed CurrSocketPower to
AverageSocketPower, but this was changed back in 40.47 so just check if
it's 40.46 and make the appropriate change
Tested with 40.45, 40.46 and 40.47 successfully
Signed-off-by: Kent Russell <kent.russell@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The SMU changed reading from CurrSocketPower to AverageSocketPower, so
reflect this accordingly. This fixes the issue where Average Power
Consumption was being reported as 0 from SMU 40.46-onward
v2: Fixed headline prefix
v3: Add check for SMU version for proper compatibility
v4: Style fix
Signed-off-by: Kent Russell <kent.russell@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to grab a reference to the fence we wait for.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
mediatek:
- fix build in some cases
nouveau:
- fix hang with i2c and mst docks
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJdYMgbAAoJEAx081l5xIa+GkIP/1k6WUcpg1dRKVT17KOz1dd1
L03nK6yETBT2SrNRqZohQslkRhCY50BBXTZG93lvt2YQvnfLa6/CT2Obm6qzRaDG
mcpkibniikt0UDPpU5QXixEndyfo22DNYc8lr80bFnzWa+AH3/VOH7wlkEiXGUr/
hkc1FSu4LpBdHs0EQB8R5o3VJFOPDl/2ysvNitBZKXtZuAYswSja0ozxgasKSoG1
NxTSVrV5FIlf5Fy1odoOmEpdC2KsJGEOM/hOxg2KxgIm3KqHRmjKyDFlrKCxrf2i
TSu5ab4cgHDmyvZGb2nZsWS30eD/6Pw56RkqjGLTxT/CuuVMOVyzs6dfg+Jkpflr
qEwzN6rT+aH8ZL4zQIBFZwwH5Z5Cq8TBPLKhh+86QS2IY9sZ7MQcc3R7IsLmbI3Q
f1qcXeKeOZ66oLIhXttIDtlc8ZSUVy3fFAyaii0HwTGYDdbEkqgfW+rkI9tVob3m
FyI61VVpimpwfX/F2a0gfwEUFPmCzi37CAreu+kbP+5kqJFpc8Vt/qjCLkOMC8ju
ndXbvpw1dF4H6HQJqPT/SerluA/oWuHlhv/rSrdZhLPXxJPKTUZIGy78IMZxzIp5
ZpnrN165oIO85l2MfiwkTPQ7YI6mIiLm2GKVvTkWuiZ9k+v6BLEEKcokmdXJ/TYB
j4V9+SiVfMbJHarvb3CV
=4afb
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2019-08-24' of git://anongit.freedesktop.org/drm/drm
Pull more drm fixes from Dave Airlie:
"Although the tree built for me fine on arm here, it appears either
header cleanups in next or some kconfig combo it breaks, so this
contains a fix to mediatek to include dma-mapping.h explicitly.
There was also one nouveau fix that came in late that I was going to
leave until next week, but since I was sending this I thought it may
as well be in here:
mediatek:
- fix build in some cases
nouveau:
- fix hang with i2c and mst docks"
* tag 'drm-fixes-2019-08-24' of git://anongit.freedesktop.org/drm/drm:
drm/mediatek: include dma-mapping header
drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUX
Although it builds fine here in my arm cross compile, it seems
either via some other patches in -next or some Kconfig combination,
this fails to build for everyone.
Include linux/dma-mapping.h should fix it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
rcar-du:
- LVDS dual-link mode fix
mediatek:
- of node refcount fix
- prime buffer import fix
- dma max seg fix
komeda:
- output polling fix
- abfc format fix
- memory-region DT fix
amdgpu:
- bpc display fix
- ioctl memory leak fix
- gfxoff fix
- smu warnings fix
i915:
- HDMI mode readout fix
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJdX0hyAAoJEAx081l5xIa+1VQP/A6ItEQ3tC2fsf7ukB2w6HvS
lHDP9WMgujR/8q/Q3IguXUiuCba+WsftE1ebv6G8HrcVrFe97roB2mX2g9XBYcPU
oDW7jK8tbOQZ6J+aEQw5IPC4Ko4zOFtf47rUJMd2ceVuqHSf677Y8ZGUy2TSPlmn
uDcwEgvZxGA6/uZwxQBpbiiWHX3l3UPVaRNhmv3K8mOtN95qHp6mhsKinnmwqMWj
9tnVTwM+kA5+n0DAYJfmAaQz7j0znfqNQra8mpGjLeLiHMNJiQ3LMdT9DqwvjFoj
QqIlu/pZWlEsn2QBsxXWflZT02UGgutTgs5D5VeoCmVe9LM+b/XLZQeWwaCNZJmp
XQiHXlm4nhtCxOYbvqGYQrXP6ffSK+aNwKix9DELF4oRl7ZmQ/C6sfrBS2Xdy5rX
PJB1FVU16Y58/kRbkTdkaW3nz/vh5CMF5BactIYrfkQHx2x+F79QvCyRYZZlJ4S5
gZNJmhFeU/AcAHSf30NNDTjvIg3fzKZh935s+kP/9JItUBHNt+lL4KJivPZopVVL
1Ow5+QMnOWfjaSftMQ26FX2/3YAwY/bDmlzos6cluGycd7K2c/oHl8OdC3QLkUr/
w8J+vOyRZNkeGOCbODrKqmVJhlQ5BbXFiNUcMAzrzaL0OczJ1CRTIyMtZoZkK4zi
wa8Cv/IebpT4Rrsjpvqi
=eo32
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2019-08-23' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Live from the laundromat after my washing machine broke down, we have
the 5.3-rc6 fixes. Changelog is in the tag below, but nothing too
noteworthy in here:
rcar-du:
- LVDS dual-link mode fix
mediatek:
- of node refcount fix
- prime buffer import fix
- dma max seg fix
komeda:
- output polling fix
- abfc format fix
- memory-region DT fix
amdgpu:
- bpc display fix
- ioctl memory leak fix
- gfxoff fix
- smu warnings fix
i915:
- HDMI mode readout fix"
* tag 'drm-fixes-2019-08-23' of git://anongit.freedesktop.org/drm/drm:
drm/amdgpu/powerplay: silence a warning in smu_v11_0_setup_pptable
drm/amd/display: Calculate bpc based on max_requested_bpc
drm/amdgpu: prevent memory leaks in AMDGPU_CS ioctl
drm/amd/amdgpu: disable MMHUB PG for navi10
drm/amd/powerplay: remove duplicate macro smu_get_uclk_dpm_states in amdgpu_smu.h
drm/amd/powerplay: fix variable type errors in smu_v11_0_setup_pptable
drm/amdgpu/gfx9: update pg_flags after determining if gfx off is possible
drm/i915: Fix HW readout for crtc_clock in HDMI mode
drm/mediatek: mtk_drm_drv.c: Add of_node_put() before goto
drm: rcar_lvds: Fix dual link mode operations
drm/mediatek: set DMA max segment size
drm/mediatek: use correct device to import PRIME buffers
drm/omap: ensure we have a valid dma_mask
drm/komeda: Add support for 'memory-region' DT node property
drm/komeda: Adds internal bpp computing for arm afbc only format YU08 YU10
drm/komeda: Initialize and enable output polling on Komeda
komeda/komeda_pipeline.c: In function 'komeda_component_add':
komeda/komeda_pipeline.c:212:3: warning: function 'komeda_component_add' might be a candidate for 'gnu_printf' format attribute [-Wsuggest-attribute=format]
vsnprintf(c->name, sizeof(c->name), name_fmt, args);
^~~~~~~~~
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Reviewed-by: Ayan Kumar Halder <ayan.halder@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190813110759.10425-1-james.qian.wang@arm.com
Fixed two -Wunused-but-set-variable warnings:
/arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function ‘komeda_crtc_normalize_zpos’:
/arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:150:26: warning: variable ‘fb’ set but not used [-Wunused-but-set-variable]
struct drm_framebuffer *fb;
^~
/arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function ‘komeda_kms_check’:
/arm/linux/display/aosp-4.14-drm-next/drivers/gpu/drm/arm/display/komeda/komeda_kms.c:209:25: warning: variable ‘old_crtc_st’ set but not used [-Wunused-but-set-variable]
struct drm_crtc_state *old_crtc_st, *new_crtc_st;
^~~~~~~~~~~
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Reviewed-by: Ayan Kumar Halder <ayan.halder@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190812112322.15990-1-james.qian.wang@arm.com
The patch 5d51f6c0da1b: "drm/komeda: Add writeback support" from May
23, 2019, leads to the following static checker warning:
drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c:151 komeda_wb_connector_add()
error: not allocating enough data 1592 vs 1584
This is a typo which misuse "wb_conn" but which should be "kwb_conn" to
allocate the memory.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com>
Reviewed-by: Ayan Kumar Halder <ayan.halder@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190819080136.10190-1-james.qian.wang@arm.com
We must make sure our scatterlist segments are not too big, otherwise
we might see swiotlb failures (happens with sev, also reproducable with
swiotlb=force).
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190821111210.27165-1-kraxel@redhat.com
When refactoring port lookup for DSS outputs, commit d17eb4537a
("drm/omap: Factor out common init/cleanup code for output devices")
incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
(which uses the DT port 1) and DPI outputs other than DPI0 (which are
not used in mainline DT sources).
Fix this by using the port number from the output omap_dss_device
of_ports field.
Fixes: d17eb4537a ("drm/omap: Factor out common init/cleanup code for output devices")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190821183226.13784-1-laurent.pinchart@ideasonboard.com
Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
qxl has two modes: "native" (used by the drm driver) and "vga" (vga
compatibility mode, typically used for boot display and firmware
framebuffers).
Accessing any vga ioport will switch the qxl device into vga mode.
The qxl driver never does that, but other drivers accessing vga ports
can trigger that too and therefore disturb qxl operation. So aquire
the legacy vga ioports from vgaarb to avoid that.
Reproducer: Boot kvm guest with both qxl and i915 vgpu, with qxl being
first in pci scan order.
v2: Skip this for secondary qxl cards which don't have vga mode in the
first place (Frediano).
Cc: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20190805105401.29874-1-kraxel@redhat.com
While I had thought I had fixed this issue in:
commit 342406e4fb ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")
It turns out that while I did fix the error messages I was seeing on my
P50 when trying to access i2c busses with the GPU in runtime suspend, I
accidentally had missed one important detail that was mentioned on the
bug report this commit was supposed to fix: that the CPU would only lock
up when trying to access i2c busses _on connected devices_ _while the
GPU is not in runtime suspend_. Whoops. That definitely explains why I
was not able to get my machine to hang with i2c bus interactions until
now, as plugging my P50 into it's dock with an HDMI monitor connected
allowed me to finally reproduce this locally.
Now that I have managed to reproduce this issue properly, it looks like
the problem is much simpler then it looks. It turns out that some
connected devices, such as MST laptop docks, will actually ACK i2c reads
even if no data was actually read:
[ 275.063043] nouveau 0000:01:00.0: i2c: aux 000a: 1: 0000004c 1
[ 275.063447] nouveau 0000:01:00.0: i2c: aux 000a: 00 01101000 10040000
[ 275.063759] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000001
[ 275.064024] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[ 275.064285] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
[ 275.064594] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000
Because we don't handle the situation of i2c ack without any data, we
end up entering an infinite loop in nvkm_i2c_aux_i2c_xfer() since the
value of cnt always remains at 0. This finally properly explains how
this could result in a CPU hang like the ones observed in the
aforementioned commit.
So, fix this by retrying transactions if no data is written or received,
and give up and fail the transaction if we continue to not write or
receive any data after 32 retries.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
- dma fix for omap.
- Make output polling work on komeda.
- Fix bpp computing for AFBC formats in komeda.
- Support the memory-region property in komeda.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl1ebNEACgkQ/lWMcqZw
E8MuVQ/8DveoeV+CwTWF8Y9nY2IlhNg4CVcyQVRu/CX/Kiajoc6u+O/p0GPtX3RJ
BW+ulgyCYTrHSGC7QxoJzzrY4ZenQsmda1ATHVxcI/wjXD3Pj5bQ+Q1sDULn975O
QuNcs8duamQbmJoWTyeD/yv2+fBvxjAoB3x9Xxir5xK+gxO09+Q8Jmq9y8eGs0Mt
LWOfnQGmAQEDtl2CPUIU+/r8iHPuPZiGgt/pJ/teheMQNpJ07Y1Gqhed0MJnPiEc
7irnLKMsnkgys8j0eYah8TkjxWtRcTNOWnC276uA+tjgqQzvatwsD+MbNBKZRVcj
2VymC885LyiPstE5xayy7yFe/Rf6gmSTjC7Zi/tckPlVK7OFyQWeFoJr8diQhS/Q
RsfoeGMxXfjTO88S2lY8CFK6IhvH33HaNOh++uz0MUiYH0t23ww7vsjM/o6IfEBH
5RPS80FbnFMFFuwfsZwpLzr2dWm4daZSzxUrwTkV5mbTRuDQ6ENLWxdMdAKe6fBU
V4sEmxMWK0PMSNw3aR1QiSOMcutrKGV7hInzbOYDPhZio2FeU/aZE8cz/KwJKa0s
RdWZjUmhKuVprmB+7vs5z52IDVghjgZCcZkrVq9VTW2v72olP7ozIy1Y4osOj+Ar
SY+q5Nqsi5pePR1QNSsnMLe+BxYvFvyCCHlydRL1tjDkfXsSr/g=
=IG8M
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2019-08-22' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Fixes for v5.3-rc6:
- dma fix for omap.
- Make output polling work on komeda.
- Fix bpp computing for AFBC formats in komeda.
- Support the memory-region property in komeda.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5f1fdfe3-814e-fad1-663c-7279217fc085@linux.intel.com
Hi Linus,
Please, pull the following patches that mark switch cases where we are
expecting to fall through.
- Fix fall-through warnings on arm and mips for multiple
configurations.
Thanks
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEkmRahXBSurMIg1YvRwW0y0cG2zEFAl1clmEACgkQRwW0y0cG
2zGqbg/9HPC3Cf3oYq4o0/kV+cfS0ir6iJCz1mspFfbBloaS/EU7A2CF35bDz7k3
XUzl/ci82EQCnuJv/X6ddayUF1S/vFWLnQXRznz07kJspUnNpu7JKgsZr2qsHaRe
CfCj62J/Kuhnke8EUjuWEuga6YXYsYlcevgg/tpVXsTmxrpq2A15tWyut7WEe4JQ
kWPELwYbPsDvTj2siZrgMRBx4gVzQKQVo5TpZiuADeJu9RuFT/64PI9TDQGE7c+X
fFq4ijd1YPj/E+WI7k5VdUbXYiPIIXmkJ4VAPcu5VWmUS7y7bTeye0Jc3uYAxI1r
7rykYhNzniGn3SZL+wq8rHchL3dTLBYhd34HhTlb5xdGFwmbzKgHBqdlGpH8HOo+
CLu8kPYdmnzYCth4md0ENwgBVkj0tweyZuMzCys1qR6RFhOipxWLNGEvIXWZ0Sp8
uNyXnPdCrZTmlwubwY4FOOLsGKW06GnD64cfmEYoCMcmT2j7clbjasWYM4PXQvbt
0dVtt8k4M5LJBLh8qTX7RMZHDQYMiiYiMnLLAXf4wB0VUTqgNuLc4k0PpX3kBYtO
4b0lU/LQH+8811BMNVBHK55StQ8DjM0C2yfQWx610eoohjV70JTyxOWoqeHFL5hq
DIFdLDOgvJCqtyYgJDjmCmH9x6lgfvmxAKq66h9Z7vt25KLUizQ=
=fQZm
-----END PGP SIGNATURE-----
Merge tag 'Wimplicit-fallthrough-5.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux
Pull more fallthrough fixes from Gustavo A. R. Silva:
"Fix fall-through warnings on arm and mips for multiple configurations"
* tag 'Wimplicit-fallthrough-5.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux:
video: fbdev: acornfb: Mark expected switch fall-through
scsi: libsas: sas_discover: Mark expected switch fall-through
MIPS: Octeon: Mark expected switch fall-through
power: supply: ab8500_charger: Mark expected switch fall-through
watchdog: wdt285: Mark expected switch fall-through
mtd: sa1100: Mark expected switch fall-through
drm/sun4i: tcon: Mark expected switch fall-through
drm/sun4i: sun6i_mipi_dsi: Mark expected switch fall-through
ARM: riscpc: Mark expected switch fall-through
dmaengine: fsldma: Mark expected switch fall-through
[Why]
The only place where state->max_bpc is updated on the connector is
at the start of atomic check during drm_atomic_connector_check. It
isn't updated when adding the connectors to the atomic state after
the fact. It also doesn't necessarily reflect the right value when
called in amdgpu during mode validation outside of atomic check.
This can cause the wrong bpc to be used even if the max_requested_bpc
is the correct value.
[How]
Don't rely on state->max_bpc reflecting the real bpc value and just
do the min(...) based on display info bpc and max_requested_bpc.
Fixes: 01933ba42d ("drm/amd/display: Use current connector state if NULL when checking bpc")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Error out if the AMDGPU_CS ioctl is called with multiple SYNCOBJ_OUT and/or
TIMELINE_SIGNAL chunks, since otherwise the last chunk wins while the
allocated array as well as the reference counts of sync objects are leaked.
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Disable MMHUB PG for navi10 according to the production requirement.
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Kevin Wang <kevin1.wang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
fix size type errors, from uint32_t to uint16_t.
it will cause only initializes the highest 16 bits in
smu_get_atom_data_table function.
bug report:
This fixes the following static checker warning.
drivers/gpu/drm/amd/amdgpu/../powerplay/smu_v11_0.c:390 smu_v11_0_setup_pptable()
warn: passing casted pointer '&size' to 'smu_get_atom_data_table()' 32 vs 16.
Signed-off-by: Kevin Wang <kevin1.wang@amd.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to set certain power gating flags after we determine
if the firmware version is sufficient to support gfxoff.
Previously we set the pg flags in early init, but we later
we might have disabled gfxoff if the firmware versions didn't
support it. Move adding the additional pg flags after we
determine whether or not to support gfxoff.
Fixes: 005440066f ("drm/amdgpu: enable gfxoff again on raven series (v2)")
Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: stable@vger.kernel.org
Chris Wilson