If the whole object is already pinned by HW for use as scanout, we will
fail to move it to the mappable region and so must resort to using a
partial VMA covering the whole object.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104513
Fixes: aa136d9d72 ("drm/i915: Convert partial ggtt vma to full ggtt if it spans the entire object")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180630090509.469-1-chris@chris-wilson.co.uk
(cherry picked from commit 7e7367d3bc)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
new_active_crtcs is a bitmask, new_active_crtc_count is the
actual count.
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The phys and vm versions had the values swapped.
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The property size may be controlled by userspace, can be large (I've
seen failure with order 4, i.e. 16 pages / 64 KB) and doesn't need to be
physically contiguous.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180629142710.2069-1-michel@daenzer.net
Cc: stable@vger.kernel.org
changed gvt display transcode DDI mode from DP_SST to
DVI to address below calltrace issue during guest booting
up which is caused by zero dotclock initial value with DP_SST
mode. transcode DVI mode emulation also align with native with DP
connection.
[drm:drm_calc_timestamping_constants]
ERROR crtc 41: Can't calculate constants, dotclock = 0!
WARNING: at drivers/gpu/drm/drm_vblank.c:620
drm_calc_vbltimestamp_from_scanoutpos
Call Trace:
? drm_calc_timestamping_constants+0x144/0x150 [drm]
drm_get_last_vbltimestamp+0x54/0x90 [drm]
drm_reset_vblank_timestamp+0x59/0xd0 [drm]
drm_crtc_vblank_on+0x7b/0xd0 [drm]
intel_modeset_setup_hw_state+0xb67/0xfd0 [i915]
? gen2_read32+0x110/0x110 [i915]
? drm_modeset_lock+0x30/0xa0 [drm]
intel_modeset_init+0x794/0x19d0 [i915]
? intel_setup_gmbus+0x232/0x2e0 [i915]
i915_driver_load+0xb4a/0xf40 [i915]
Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
when guest writes ggtt entries, it could write 8 bytes a time if
gtt_entry_size is 8. But, qemu could split the 8 bytes into 2 consecutive
4-byte writes.
If each 4-byte partial write could trigger a host ggtt write, it is very
possible that a wrong combination is written to the host ggtt. E.g.
the higher 4 bytes is the old value, but the lower 4 bytes is the new
value, and this 8-byte combination is wrong but written to the ggtt, thus
causing bugs.
To handle this condition, we just record the first 4-byte write, then wait
until the second 4-byte write comes and write the combined 64-bit data to
host ggtt table.
To save memory space and to spot partial write as early as possible, we
don't keep this information for every ggtt index. Instread, we just record
the last ggtt write position, and assume the two 4-byte writes come in
consecutively for each vgpu.
This assumption is right based on the characteristic of ggtt entry which
stores memory address. When gtt_entry_size is 8, the guest memory physical
address should be 64 bits, so any sane guest driver should write 8-byte
long data at a time, so 2 consecutive 4-byte writes at the same ggtt index
should be trapped in gvt.
v2:
when incomplete ggtt entry write is located, e.g.
1. guest only writes 4 bytes at a ggtt offset and no long writes the
rest 4 bytes.
2. guest writes 4 bytes of a ggtt offset, then write at other ggtt
offsets, then return back to write the left 4 bytes of the first
ggtt offset.
add error handling logic to remap host entry to scratch page, and mark
guest virtual ggtt entry as not present. (zhenyu wang)
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch unifies the naming of DRM functions for reference counting
of struct drm_gem_object. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch unifies the naming of DRM functions for reference counting
of struct drm_framebuffer. The resulting code is more aligned with the
rest of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAls2oVcQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpr89D/9PaJCtLpCEU1HdaohIDXDyJKBdtCllIsqJ
YAJTlUkFRkMvsbdEA3U43rVRVlu7zxP3aRg79VRI+kdZ8y8XSiisAF/QUbG/Bwd3
NuFqKj4Hm5xFTtLMKIUlumR2/exD4ZpPHKnWmD4idp1PZRoTUwxeIjqVv77L6Nfy
c4/GVlz2t9buWxH/5PSa//rsT49xM6CLpyIwO2lFsNEk2HYE/uAWya5KZVJ1YKVw
mSjUdyFtJ//lFK9lVU4YkdNF0d5w2PcEoCfNyPe0n9F43iITACo2om7rkSkTgciS
izPAs1DkqNdWPta2twULt656WlUoGlwnWyFchU34N/I/pDiww4kdCQFfNIOi6qBW
7rPQ4xpywiw/U93C2GLEeE09++T8+yO4KuELhIcN5+D3D2VGRIuaGcf4xeY0CX3A
a335EZIxBGOfxyejknBDg3BsoUcLvejbANKD8ltis3zciGf/QyLt+FFqx25WCzkN
N028ppml8WPSiqhSlFDMyfscO1dx/WSYh1q7ANrBiPPaEjFYmakzEDT0cZW4JsUh
av4jqYt3cqrFIXyhRHJM2wjFymQv6aVnmLa4zOKCFbwm9KzMWUUFjc4R962T/sQK
0g+eCSFGidii4JZ4ghOAQk2dqCTIZqV72pmLlpJBGu+SAIQxkh+29h0LOi5U3v1Y
FnTtJ1JhCg==
=0uqV
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20180629' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Small set of fixes for this series. Mostly just minor fixes, the only
oddball in here is the sg change.
The sg change came out of the stall fix for NVMe, where we added a
mempool and limited us to a single page allocation. CONFIG_SG_DEBUG
sort-of ruins that, since we'd need to account for that. That's
actually a generic problem, since lots of drivers need to allocate SG
lists. So this just removes support for CONFIG_SG_DEBUG, which I added
back in 2007 and to my knowledge it was never useful.
Anyway, outside of that, this pull contains:
- clone of request with special payload fix (Bart)
- drbd discard handling fix (Bart)
- SATA blk-mq stall fix (me)
- chunk size fix (Keith)
- double free nvme rdma fix (Sagi)"
* tag 'for-linus-20180629' of git://git.kernel.dk/linux-block:
sg: remove ->sg_magic member
drbd: Fix drbd_request_prepare() discard handling
blk-mq: don't queue more if we get a busy return
block: Fix cloning of requests with a special payload
nvme-rdma: fix possible double free of controller async event buffer
block: Fix transfer when chunk sectors exceeds max
This was introduced more than a decade ago when sg chaining was
added, but we never really caught anything with it. The scatterlist
entry size can be critical, since drivers allocate it, so remove
the magic member. Recently it's been triggering allocation stalls
and failures in NVMe.
Tested-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Acked-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
The limit_id_fallback array uses enum drm_ipp_size_id to index its
content. The content itself is of type enum drm_exynos_ipp_limit_type.
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The only bits that should be preserved in decon_win_set_fmt() is
WINCONx_ENWIN_F. All other bits depends on the selected pixel formats and
are set by the mentioned function.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Set per-plane global alpha to maximum value to get proper blending of
XRGB and ARGB planes. This fixes the strange order of overlapping planes.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
DMA hardware should respect buffer pitch, so use the width calculated from
the buffer pitch instead of the virtual one.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Fix following issues related to planar YUV pixel format configuration:
- NV16/61 modes were incorrectly programmed as NV12/21,
- YVU420 was programmed as YUV420 on source,
- YVU420 and YUV422 were programmed as YUV420 on output.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Horizontal (DRM_MODE_REFLECT_Y) and vertical (DMR_MODE_REFLECT_Y) flip
were swapped in GScaler driver. Fix this by swapping code for interpreting
them.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Investigation revealed that GScaler hardware requires the real buffer width
(pitch) to be aligned to 16 pixels.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
DMA hardware should respect buffer pitch, so use the width calculated from
the buffer pitch instead of the virtual one.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Fix Cb/CR components order in two-planar YUV420, YUV422 and YUV444 modes.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Ensure that Scaler hardware is properly reset and interrupts are cleared
before processing next image.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Horizontal (DRM_MODE_REFLECT_Y) and vertical (DMR_MODE_REFLECT_Y) flip
were swapped in Rotator driver. Fix this by swapping code for interpreting
them.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Prepare a common function for size and scale checks and call it for
source and destination buffers. Then also move there the state-less checks
from exynos_drm_ipp_task_setup_buffer, so the format information is already
available in limits processing. Finally perform the IPP_LIMIT_BUFFER check
on the real width of the buffer (the width calculated from the provided
buffer pitch).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The other day I was testing one of the HP laptops at my office with an
i915/amdgpu hybrid setup and noticed that hotplugging was non-functional
on almost all of the display outputs. I eventually discovered that all
of the external outputs were connected to the amdgpu device instead of
i915, and that the hotplugs weren't being detected so long as the GPU
was in runtime suspend. After some talking with folks at AMD, I learned
that amdgpu is actually supposed to support hotplug detection in runtime
suspend so long as the OEM has implemented it properly in the firmware.
On this HP ZBook 15 G4 (the machine in question), amdgpu wasn't managing
to find the ATIF handle at all despite the fact that I could see acpi
events being sent in response to any hotplugging. After going through
dumps of the firmware, I discovered that this machine did in fact
support ATIF, but that it's ATIF method lived in an entirely different
namespace than this device's handle (the device handle was
\_SB_.PCI0.PEG0.PEGP, but ATIF lives in ATPX's handle at
\_SB_.PCI0.GFX0).
So, fix this by probing ATPX's ACPI parent's namespace if we can't find
ATIF elsewhere, along with storing a pointer to the proper handle to use
for ATIF and using that instead of the device's handle.
This fixes HPD detection while in runtime suspend for this ZBook!
v2: Update the comment to reflect how the namespaces are arranged
based on the system configuration. (Alex)
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Since it seems that some vendors are storing the ATIF ACPI methods under
the same handle that ATPX lives under instead of the device's own
handle, we're going to need to be able to retrieve this handle later so
we can probe for ATIF there.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Currently, there is nothing in amdgpu that actually uses these structs
other than amdgpu_acpi.c. Additionally, since we're about to start
saving the correct ACPI handle to use for calling ATIF in this struct
this saves us from having to handle making sure that the acpi_handle
(and by proxy, the type definition for acpi_handle and all of the other
acpi headers) doesn't need to be included within the amdgpu_drv struct
itself. This follows the example set by amdgpu_atpx_handler.c.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
- A single fix in meson for an unhandled error path in meson_drv_bind_master().
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAls0rxUACgkQ/lWMcqZw
E8NZIQ/6An8Mtj+cqLu6kBRNOFXpaWdouAy/LfHICrIA3lhNt7D6ANNs+H7Po6uO
d+S18rliimcxPrxAO3LXPoSk3PNDnScBAgZFTLHaQflcRKwGjHCcSeTAKzBFR/Ek
7Nl3rR2dD14atQ4Z7sdcXEpr7jMyK/7n8qCcYLn6EG1scolH6Rk+SWBiLnmyCylZ
BjfNzZcOoiP9RjoyOJMOUH46AQ+AOTeTaY5lTZbmHrNJR1DjttRrymaWbaJQfHsE
2AndEUjEEhr8NSVASi/RL6ds7q9jcNqbudCJXji9I8Y+BWaCUKG29jNzd2Tg3pC6
wgFzztxHzMRctCkuxbsJ6M0XGP5thj2/6uPqU0jryj27S9fh0ptm6nhaGA4RH0uS
nstZWZlA7TTyfaiJVxyKFwSoHhdDzOlhyoLhYRS1oStC88KfJwAPfvvk/vfYhEb/
IUME201f8PAM+O+0nyiw+cQXQsmSR/XZ8TPUgojZu6nzYPd4Lb/Yffk7THw/QMO1
1cV18uzlRE52q1QK7fl8+rCa0PZN/lpRC1do7qRgAZExwu4+NN0jOWqiPLoEWNA6
KPDao27gFFZoYeNBF1mN7nbM1ENQKCuCWzZIsN1BZpnxDF7X8GgvZWjMn63NQmBV
2U/woZ4FmNWaj4swf6qQUP/9r1Gbayue8rOyv9lqzVl0bmjQtvA=
=zPj3
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2018-06-28' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v4.18-rc3:
- A single fix in meson for an unhandled error path in meson_drv_bind_master().
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fa740f31-5a8d-ed45-5e8a-aecd3f6f11b7@linux.intel.com
A few fixes for 4.18:
- fix a read past the end of an array due to vega20 changes
- fix driver on systems with non-4K pages
- fix locking with pageflipping in DC that could lead to a sleep while atomic
- fix VCN firmware version reporting for upcoming firmware
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628032641.2765-1-alexander.deucher@amd.com
A new member Vr2_I2C_address is added.
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>
The vbios firmware structure changed between v3_1 and v3_2. So,
the code to setup bootup values needs different paths based
on header version.
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>
Thermal support is enabled on vega12.
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, amdgpu_do_flip() spinlocks crtc->dev->event_lock and
releases it only after committing updates to the stream.
dc_commit_updates_for_stream() should be moved out of
spinlock for the below reasons:
1. event_lock is supposed to protect access to acrct->pflip_status _only_
2. dc_commit_updates_for_stream() has potential sleep's
and also its not appropriate to be in an atomic state
for such long sequences of code.
Signed-off-by: Shirish S <shirish.s@amd.com>
Suggested-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Support new VCN FW version naming convention:
[31, 28] for VEP interface major version if applicable
[27, 24] for decode interface major version
[23, 20] for encode interface major version
[19, 12] for encode interface minor version
[11, 0] for firmware revision
Bit 20-23, it is encode major and non-zero for new naming convention.
This field is part of version minor and DRM_DISABLED_FLAG in old naming
convention. Since the latest version minor is 0x5B and DRM_DISABLED_FLAG
is zero in old naming convention, this field is always zero so far.
These four bits are used to tell which naming convention is present.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Fang, Peter <Peter.Fang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Here is the UBSAN dump:
[ 3.866656] index 2 is out of range for type 'amdgpu_uvd_inst [2]'
[ 3.866693] Workqueue: events work_for_cpu_fn
[ 3.866702] Call Trace:
[ 3.866710] dump_stack+0x85/0xc5
[ 3.866719] ubsan_epilogue+0x9/0x40
[ 3.866727] __ubsan_handle_out_of_bounds+0x89/0x90
[ 3.866737] ? rcu_read_lock_sched_held+0x58/0x60
[ 3.866746] ? __kmalloc+0x26c/0x2d0
[ 3.866846] amdgpu_fence_driver_start_ring+0x259/0x280 [amdgpu]
[ 3.866896] amdgpu_ring_init+0x12c/0x710 [amdgpu]
[ 3.866906] ? sprintf+0x42/0x50
[ 3.866956] amdgpu_gfx_kiq_init_ring+0x1bc/0x3a0 [amdgpu]
[ 3.867009] gfx_v8_0_sw_init+0x1ad3/0x2360 [amdgpu]
[ 3.867062] ? smu7_init+0xec/0x160 [amdgpu]
[ 3.867109] amdgpu_device_init+0x112c/0x1dc0 [amdgpu]
'ring->me' might be set as 2 with 'amdgpu_gfx_kiq_init_ring', that would
cause out of range for 'amdgpu_uvd_inst[2]'.
v2: simplified with ring type
Signed-off-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Russell King reported:
"When removing and reloading the etnaviv module, the following splat
occurs:
sysfs: cannot create duplicate filename '/devices/platform/etnaviv'
CPU: 0 PID: 1471 Comm: modprobe Not tainted 4.17.0+ #1608
Hardware name: Marvell Dove (Cubox)
Backtrace:
[<c00157d4>] (dump_backtrace) from [<c0015b8c>] (show_stack+0x18/0x1c)
r6:ef033e38 r5:ee07b340 r4:edb9d000 r3:00000000
[<c0015b74>] (show_stack) from [<c0620784>] (dump_stack+0x20/0x28)
[<c0620764>] (dump_stack) from [<c01bcd24>] (sysfs_warn_dup+0x5c/0x70)
[<c01bccc8>] (sysfs_warn_dup) from [<c01bce14>] (sysfs_create_dir_ns+0x90/0x98)
..."
Commit 246774d17f ("drm/etnaviv: remove the need for a gpu-subsystem
DT node") introduced DRM registration via
platform_device_register_simple(), but missed to call
platform_device_unregister() inside etnaviv_exit().
Fix the problem by calling platform_device_unregister() inside
etnaviv_exit(). While at it, also rearrange the function calls
in the exit path to make them happen in the opposite order of
registration.
Tested on a imx6-sabresd board.
Cc: <stable@vger.kernel.org>
Fixes: 246774d17f ("drm/etnaviv: remove the need for a gpu-subsystem DT node")
Reported-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
platform_device_register_simple() may fail, so we should better
check its return value and propagate it in the case of error.
Cc: <stable@vger.kernel.org>
Fixes: 246774d17f ("drm/etnaviv: remove the need for a gpu-subsystem DT node")
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
If 'platform_get_resource_byname()' fails, we should release some resources
before leaving, as already done in the other error handling path of the
function.
Fixes: acaa3f13b8 ("drm/meson: Fix potential NULL dereference in meson_drv_bind_master()")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611165335.24542-1-christophe.jaillet@wanadoo.fr
start / last / max_entries are numbers of GPU pages, pfn / count are
numbers of CPU pages. Convert between them accordingly.
Fixes badness on systems with > 4K page size.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/106258
Reported-by: Matt Corallo <freedesktop@bluematt.me>
Tested-by: foxbat@ruin.net
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This fixes a regression I accidentally reduced that was picked up by
kasan, where we were checking the CRTC atomic states after DRM's helpers
had already freed them. Example:
==================================================================
BUG: KASAN: use-after-free in amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
Read of size 1 at addr ffff8803a697b071 by task kworker/u16:0/7
CPU: 7 PID: 7 Comm: kworker/u16:0 Tainted: G O 4.18.0-rc1Lyude-Upstream+ #1
Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.21 05/02/2018
Workqueue: events_unbound commit_work [drm_kms_helper]
Call Trace:
dump_stack+0xc1/0x169
? dump_stack_print_info.cold.1+0x42/0x42
? kmsg_dump_rewind_nolock+0xd9/0xd9
? printk+0x9f/0xc5
? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
print_address_description+0x6c/0x23c
? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
kasan_report.cold.6+0x241/0x2fd
amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
? commit_planes_to_stream.constprop.45+0x13b0/0x13b0 [amdgpu]
? cpu_load_update_active+0x290/0x290
? finish_task_switch+0x2bd/0x840
? __switch_to_asm+0x34/0x70
? read_word_at_a_time+0xe/0x20
? strscpy+0x14b/0x460
? drm_atomic_helper_wait_for_dependencies+0x47d/0x7e0 [drm_kms_helper]
commit_tail+0x96/0xe0 [drm_kms_helper]
process_one_work+0x88a/0x1360
? create_worker+0x540/0x540
? __sched_text_start+0x8/0x8
? move_queued_task+0x760/0x760
? call_rcu_sched+0x20/0x20
? vsnprintf+0xcda/0x1350
? wait_woken+0x1c0/0x1c0
? mutex_unlock+0x1d/0x40
? init_timer_key+0x190/0x230
? schedule+0xea/0x390
? __schedule+0x1ea0/0x1ea0
? need_to_create_worker+0xe4/0x210
? init_worker_pool+0x700/0x700
? try_to_del_timer_sync+0xbf/0x110
? del_timer+0x120/0x120
? __mutex_lock_slowpath+0x10/0x10
worker_thread+0x196/0x11f0
? flush_rcu_work+0x50/0x50
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x40/0x70
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x40/0x70
? __switch_to_asm+0x34/0x70
? __switch_to_asm+0x40/0x70
? __schedule+0x7d6/0x1ea0
? migrate_swap_stop+0x850/0x880
? __sched_text_start+0x8/0x8
? save_stack+0x8c/0xb0
? kasan_kmalloc+0xbf/0xe0
? kmem_cache_alloc_trace+0xe4/0x190
? kthread+0x98/0x390
? ret_from_fork+0x35/0x40
? ret_from_fork+0x35/0x40
? deactivate_slab.isra.67+0x3c4/0x5c0
? kthread+0x98/0x390
? kthread+0x98/0x390
? set_track+0x76/0x120
? schedule+0xea/0x390
? __schedule+0x1ea0/0x1ea0
? wait_woken+0x1c0/0x1c0
? kasan_unpoison_shadow+0x30/0x40
? parse_args.cold.15+0x17a/0x17a
? flush_rcu_work+0x50/0x50
kthread+0x2d4/0x390
? kthread_create_worker_on_cpu+0xc0/0xc0
ret_from_fork+0x35/0x40
Allocated by task 1124:
kasan_kmalloc+0xbf/0xe0
kmem_cache_alloc_trace+0xe4/0x190
dm_crtc_duplicate_state+0x78/0x130 [amdgpu]
drm_atomic_get_crtc_state+0x147/0x410 [drm]
page_flip_common+0x57/0x230 [drm_kms_helper]
drm_atomic_helper_page_flip+0xa6/0x110 [drm_kms_helper]
drm_mode_page_flip_ioctl+0xc4b/0x10a0 [drm]
drm_ioctl_kernel+0x1d4/0x260 [drm]
drm_ioctl+0x433/0x920 [drm]
amdgpu_drm_ioctl+0x11d/0x290 [amdgpu]
do_vfs_ioctl+0x1a1/0x13d0
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x6f/0xb0
do_syscall_64+0x147/0x440
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 1124:
__kasan_slab_free+0x12e/0x180
kfree+0x92/0x1a0
drm_atomic_state_default_clear+0x315/0xc40 [drm]
__drm_atomic_state_free+0x35/0xd0 [drm]
drm_atomic_helper_update_plane+0xac/0x350 [drm_kms_helper]
__setplane_internal+0x2d6/0x840 [drm]
drm_mode_cursor_universal+0x41e/0xbe0 [drm]
drm_mode_cursor_common+0x49f/0x880 [drm]
drm_mode_cursor_ioctl+0xd8/0x130 [drm]
drm_ioctl_kernel+0x1d4/0x260 [drm]
drm_ioctl+0x433/0x920 [drm]
amdgpu_drm_ioctl+0x11d/0x290 [amdgpu]
do_vfs_ioctl+0x1a1/0x13d0
ksys_ioctl+0x60/0x90
__x64_sys_ioctl+0x6f/0xb0
do_syscall_64+0x147/0x440
entry_SYSCALL_64_after_hwframe+0x44/0xa9
The buggy address belongs to the object at ffff8803a697b068
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 9 bytes inside of
1024-byte region [ffff8803a697b068, ffff8803a697b468)
The buggy address belongs to the page:
page:ffffea000e9a5e00 count:1 mapcount:0 mapping:ffff88041e00efc0 index:0x0 compound_mapcount: 0
flags: 0x8000000000008100(slab|head)
raw: 8000000000008100 ffffea000ecbc208 ffff88041e000c70 ffff88041e00efc0
raw: 0000000000000000 0000000000170017 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8803a697af00: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8803a697af80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8803a697b000: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb
^
ffff8803a697b080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8803a697b100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
So, we fix this by counting the number of CRTCs this atomic commit disabled
early on in the function before their atomic states have been freed, then use
that count later to do the appropriate number of RPM puts at the end of the
function.
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Cc: stable@vger.kernel.org
Fixes: 97028037a3 ("drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()")
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Michel Dänzer <michel@daenzer.net>
Reported-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
- A reversion of a commit in drm/sun4i to fix a run-time fault.
- Various fixes to the sii8620 bridge.
- Small bugfix to correctly check stride in atmel-hlcdc.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAlsrr5YACgkQ/lWMcqZw
E8PQWBAAkkX3H/NXFqfdMaWlFxLluIFRNXfglAQ7oJHAHO4KXtqthwBQPuYQd1cL
1LE+saIQmZMMB2LRif6B3aXLKIVcnMswNc5ByuDDSup4yVfCY1yhXQ6/sk3Wjmvh
EikvuOsPm5i9+r6KJqWykHAsMm7qxJGuP2NvXmeIk7Rq4lxfGi5/LLdC4p8t14Jb
/2yPnFIt4bf+of/+xZW9bn73unfKhOFRt8vc8PqQVSY4X6cjFfA6zBdGcU/uJ9hU
tUqMBDVsz5Qr133ENPCOxUxXkxsEMKlTtgJgrq37Eo22uEkrRRKhkMNQDSvBX3zh
dqTJ6UD5z9j0t0ShPgAebypSFKlZ3G8TQ6VL1jYRCOr7EvX0xDEJYfA/pOgfHWIU
GyD33bewmKPPCnI7KG6PM7LRX/vhoSEtCCa49cU9tdkhCZHbjsPAl7yAsVJ0xeO3
CAUOUkeXoj4oQrQFqWqJYz8yMpZKrOTkzWBhcuB+FpywfyxFxEPqxKhEfcWL1Puq
cdV6orZ6Ar9z6k3Z5GnopU5JVHbvVm1fi5e64y9G7JlPuUDwZ6+3YgMgkJMwDXbx
xuORZRkzOVDXODlMSlOZZu6kfnm67SRlQvnYWIIbpVQByZjt9RD4NQngkfYI54Am
7PJe9/24/KqmNe9vW6hCLDK21JeVFLQ2pblISrGHkx2rAaLtCRg=
=ngPr
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2018-06-21' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Fixes for v4.18-rc2:
- A reversion of a commit in drm/sun4i to fix a run-time fault.
- Various fixes to the sii8620 bridge.
- Small bugfix to correctly check stride in atmel-hlcdc.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/787d4bef-a579-4046-d0fc-f8c2c5b80c25@linux.intel.com
Currently packed pixel modes in MHL2 can't be displayed. The device
automatically recognizes output format, so setting format other than
RGB causes failure. Fix it by writing proper values to registers.
Tested on MHL1 and MHL2 using various vendors' dongles both in
DVI and HDMI mode.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516706239-9104-1-git-send-email-m.purski@samsung.com
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAlsfjRcACgkQ/lWMcqZw
E8O5ohAAkkaJkDOAAoKB3Tz0gaTR1lFFIB2yWcDkquMXANtAMhlyEtDxoRJv0Yo9
Mwbc3IGXRLJwrnSJUSTUTxbPfB0SedysUxm+5oY8sPdCKICnhG3bWmHuCiQjsUmA
UDklcxust1VWXiRO7oQJs1jlJ0KugyTrV0NKoEX0hr+HQjnT6xZmD4Y+w5ldWhmI
VpIlZumVKREni/lVRxSWzfPqjxOSFVSgJiPgQuJascX7IvhO0SAQeJcK/1O+YBUO
GnhRIxIFJ2kJZUN/AMeLyFHoUPmrw92lE+jNLzTgsWClpLCkUvZk42F3DKPlFUQa
XVRdZd1PLVw3h4EEbANjF0jJ60O6Qw5vP2RZJQewTLoqetgnagNPu1p9+SHLoqlA
UAgMxF62XUozq2zEJojvVEgaBCwXRhX/fcfc+d8vK1cdyVIHp0pC+L2ZQVb/cgOJ
t9oDHV6ymbdyAtUqES4Xn4NZImdD99kOd9wn5eWH1UvVE8kycRxGn8qryazpeg4O
INOXEnNiuYYKx3HFGBjV2N5hqLTtCUnDj+Jj9JZWRdZiYWDxModf2MY9QXp84b4L
bZWOtRFLt6pikLkZfDahNHvypl/ImAKC1Bv/j7I+4UQl9Rv63Rip3yoOCyUb80WW
TmtjcLa+owLdXH87bq2Iptc1e0S+r2sP+rN3NafrzfD+PQ13/oU=
=kCVp
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2018-06-12' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Only a small qxl fix that was queued for v4.17.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/08dcbd63-ed18-6232-7bbd-547a3d63b90f@linux.intel.com
Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least
partially in CPU visible VRAM, in particular when all VRAM is visible.
v2:
* Don't take VRAM mgr spinlock, not needed (Christian König)
* Make loop logic simpler and clearer.
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Preparation for the following fix, no functional change intended.
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
At least in theory, ttm_bo_validate may move the BO, in which case the
pin_size accounting would be inconsistent with when the BO was pinned.
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
All UVD instanses have only one dpm control, so it is better
to share one idle_work handle.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Tested-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We've had a number of users report failures to detect and light up
display with DC with LVDS and VGA. These connector types are not
currently supported with DC. I'd like to add support but unfortunately
don't have a system with LVDS or VGA available.
In order not to cause regressions we should probably fallback to the
non-DC driver for ASICs that support VGA and LVDS.
These ASICs are:
* Bonaire
* Kabini
* Kaveri
* Mullins
ASIC support can always be force enabled with amdgpu.dc=1
v2: Keep Hawaii on DC
v3: Added Mullins to the list
Cc: stable@vger.kernel.org
Signed-off-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It can be quite big, and there's no need for it to be physically
contiguous. This is less likely to fail under memory pressure (has
actually happened while running piglit).
Cc: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Initialize variable to 0 before performing logical OR operation.
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Rajan Vaja <rajan.vaja@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The SF and clipper units mishandle the provoking vertex in some cases,
which can cause misrendering with shaders that use flat shaded inputs.
There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN
(for the clipper) that work around the issue. These registers are
unfortunately not part of the logical context (even the power context),
and so we must reload them every time we start executing in a context.
Bugzilla: https://bugs.freedesktop.org/103047
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615190605.16238-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
(cherry picked from commit b77422f803)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If client is smart or lucky enough to create a new context
after each hang, our context banning mechanism will never
catch up, and as a result of that it will be saved from
client banning. This can result in a never ending streak of
gpu hangs caused by bad or malicious client, preventing
access from other legit gpu clients.
Fix this by always incrementing per client ban score if
it hangs in short successions regardless of context ban
scoring. The exception are non bannable contexts. They remain
detached from client ban scoring mechanism.
v2: xchg timestamp, tidyup (Chris)
v3: comment, bannable & banned together (Chris)
Fixes: b083a0870c ("drm/i915: Add per client max context ban limit")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615104429.31477-1-mika.kuoppala@linux.intel.com
(cherry picked from commit 14921f3cef)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
While Bspec doesn't list a specific sequence for turning off the DP port
on g4x we are getting an underrun if the port is disabled in the
.disable() hook. Looks like the pipe stops when the port stops, and by
that time the plane disable may not have completed yet. Also the plane(s)
seem to end up in some wonky state when this happens as they also signal
another underrun immediately after we turn them back on during the next
enable sequence.
We could add a vblank wait in .disable() to avoid wedging the planes,
but I assume we're still tripping up the pipe in some way. So it seems
better to me to just follow the ILK+ sequence and turn off the DP port
in .post_disable() instead. This sequence doesn't seem to suffer from
this problem. Could be it was always the intended sequence for DP and
the gen4 bspec was just never updated to include it.
Originally we used the bad sequence even on ilk+, but I changed that
in commit 08aff3fe26 ("drm/i915: Move DP port disable to post_disable
for pch platforms") as it was causing issues on those platforms as well.
I left out g4x then only because I didn't have the hardware to test it.
Now that I do it's fairly clear that the ilk+ sequence is also the
right choice for g4x.
v2: Fix whitespace fail (Jani)
Mention the ilk+ commit (Jani)
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 51a9f6dfc0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
On i965/g4x IIR is edge triggered. So in order for IIR to notice that
there is still a pending interrupt we have to force and edge in ISR.
For the ISR/IIR pipe event bits we can do that by temporarily
clearing all the PIPESTAT enable bits when we ack the status bits.
This will force the ISR pipe event bit low, and it can then go back
high when we restore the PIPESTAT enable bits.
This avoids the following race:
1. stat = read(PIPESTAT)
2. an enabled PIPESTAT status bit goes high
3. write(PIPESTAT, enable|stat);
4. write(IIR, PIPE_EVENT)
The end result is IIR==0 and ISR!=0. This can lead to nasty
vblank wait/flip_done timeouts if another interrupt source
doesn't trick us into looking at the PIPESTAT status bits despite
the IIR PIPE_EVENT bit being low.
Before i965 IIR was level triggered so this problem can't actually
happen there. And curiously VLV/CHV went back to the level triggered
scheme as well. But for simplicity we'll use the same i965/g4x
compatible code for all platforms.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 132c27c97c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When encountering a connector with the scaling mode property both
intel and modesetting ddxs sometimes add tons of DBLSCAN modes
to the output's mode list. The idea presumably being that since the
output will be going through the panel fitter anyway we can pretend
to use any kind of mode.
Sadly that means we can't reject user modes with the DBLSCAN flag
until we know whether we're going to be using the panel's native
mode or the user mode directly. Doing otherwise means X clients using
xf86vidmode/xrandr will get a protocol error (and often self
terminate as a result) when the kernel refuses to use the requested
mode with the DBLSCAN flag.
To undo the regression we'll move the DBLSCAN checks into the
connector->mode_valid() and encoder->compute_config() hooks.
Cc: stable@vger.kernel.org
Cc: Vito Caputo <vcaputo@pengaru.com>
Reported-by: Vito Caputo <vcaputo@pengaru.com>
Fixes: e995ca0b81 ("drm/i915: Provide a device level .mode_valid() hook")
References: https://lkml.org/lkml/2018/5/21/715
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524125403.23445-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106804
Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl>
(cherry picked from commit e4dd27aadd)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
On allocation error, do not jump to the unwind handler that tries to
free the error pointer.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: a89d1f921c ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611153332.14824-1-chris@chris-wilson.co.uk
(cherry picked from commit 467d35789e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We special case the position of the batch within the GTT to prevent
negative self-relocation deltas from underflowing. However, that
restriction is being applied after a trial pin of the batch in its
current position. Thus we are not rejecting an invalid location if the
batch has been used before, leading to an assertion if we happen to need
to rearrange the entire payload. In the worst case, this may cause a GPU
hang on gen7 or perhaps missing state.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105720
Fixes: 2889caa923 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180610194325.13467-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 746c8f143a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ctxdmas for cursors from all heads are setup in the core channel, and due
to us tracking allocated handles per-window, we were failing with -EEXIST
on multiple-head setups trying to allocate duplicate handles.
The cursor code is hardcoded to use the core channel vram ctxdma already,
so just skip ctxdma allocation for cursor fbs to fix the issue.
Fixes: 5bca1621c0 ("drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows")
Reported-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The width and height needs to be swapped
Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Brian Starkey <brian.starkey@arm.com>
Reviewed-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
[rebased on top of v4.18-rc1]
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
On some Mali-DP processors, the LAYER_FORMAT register contains fields
other than the format. These bits were unconditionally cleared when
setting the pixel format, whereas they should be preserved at their
reset values.
Reported-by: Brian Starkey <brian.starkey@arm.com>
Reported-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
In the situation that DE and SE aren’t shared the same interrupt number,
the Global SE interrupts mask bit MASK_IRQ_EN in MASKIRQ must be set, or
else other mask bits will not work and no SE interrupt will occur. This
patch enables MASK_IRQ_EN for SE to fix this problem.
Signed-off-by: Alison Wang <alison.wang@nxp.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
One needs to ensure that the crtcs are shutdown so that the
drm_crtc_state->connector_mask reflects that no connectors
are currently active. Further, it reduces the reference
count for each connector. This ensures that the connectors
and encoders can be cleanly removed either when _unbind
is called for the corresponding drivers or by
drm_mode_config_cleanup().
We need drm_atomic_helper_shutdown() to be called before
component_unbind_all() otherwise the connectors attached to the
component device will have the wrong reference count value and will not
be cleanly removed.
Signed-off-by: Ayan Kumar Halder <ayan.halder@arm.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
This reverts commit 2c17a4368a.
The offending commit triggers a run-time fault when accessing the panel
element of the sun4i_tcon structure when no such panel is attached.
It was apparently assumed in said commit that a panel is always used with
the TCON. Although it is often the case, this is not always true.
For instance a bridge might be used instead of a panel.
This issue was discovered using an A13-OLinuXino, that uses the TCON
in RGB mode for a simple DAC-based VGA bridge.
Cc: stable@vger.kernel.org
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613081647.31183-1-paul.kocialkowski@bootlin.com
The statement always evaluates to true since the struct fields
are arrays. This has shown up as a warning when compiling with
clang:
warning: address of array 'desc->layout.xstride' will always
evaluate to 'true' [-Wpointer-bool-conversion]
Check for values in the first plane instead.
Fixes: 1a396789f6 ("drm: add Atmel HLCDC Display Controller support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180617084826.31885-1-stefan@agner.ch
- can.rst: fix a footnote reference;
- crypto_engine.rst: Fix two parsing warnings;
- Fix a lot of broken references to Documentation/*;
- Improves the scripts/documentation-file-ref-check script,
in order to help detecting/fixing broken references,
preventing false-positives.
After this patch series, only 33 broken references to doc files are
detected by scripts/documentation-file-ref-check.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbJC2aAAoJEAhfPr2O5OEVPmMP/2rN5m9LZ048oRWlg4hCwo73
4FpWqDg18hbWCMHXYHIN1UACIMUkIUfgLhF7WE3D/XqRMuxHoiE5u7DUdak7+VNt
wunpksKFJbgyfFMHRvykHcZV+jQFVbM7eFvXVPIvoSaAeGH6zx4imHTyeDn3x/nL
gdtBqM4bvEhmBjotBTRR4PB8+oPrT/HIT5npHepx3UnFFFAzDQGEZ/I67/el2G5C
pVmYdBXvr7iqrvUs6FilHLTEfe1quCI4UaKNfLHKrxXrTkiJQFOwugYuobZfNmxT
GwjWzfpNy9HMlKJFYipcByALxel1Mnpqz5mIxFQaCTygBuEsORCWzW5MoKIsIUJ0
KOoG76v0rUyMvLBRvaoao3CHYHdzxhQbtVV9DjyDuDksa2G5IoCAF1t6DyIOitRw
9plMnGckk+FJ/MXJKYWXHszFS8NhI0SF2zHe3s1DmRTD8P6oxkxvxBFz6iqqADmL
W6XHd8CcqJItaS9ctPen91TFuysN1HFpdzLLY+xwWmmKOcWC/jFjhTm8pj7xLQHM
5yuuEcefsajf+Xk4w2fSQmRfXnuq+oOlPuWpwSvEy+59cHGI0ms18P1nHy/yt3II
CJywwdx6fjwDon57RFKH7kkGd7px317zMqWdIv9gUj/qZAy9gcdLdvEQLhx9u0aV
4F+hLKFDFEpf58xqRT1R
=/ozx
-----END PGP SIGNATURE-----
Merge tag 'docs-broken-links' of git://linuxtv.org/mchehab/experimental
Pull documentation fixes from Mauro Carvalho Chehab:
"This solves a series of broken links for files under Documentation,
and improves a script meant to detect such broken links (see
scripts/documentation-file-ref-check).
The changes on this series are:
- can.rst: fix a footnote reference;
- crypto_engine.rst: Fix two parsing warnings;
- Fix a lot of broken references to Documentation/*;
- improve the scripts/documentation-file-ref-check script, in order
to help detecting/fixing broken references, preventing
false-positives.
After this patch series, only 33 broken references to doc files are
detected by scripts/documentation-file-ref-check"
* tag 'docs-broken-links' of git://linuxtv.org/mchehab/experimental: (26 commits)
fix a series of Documentation/ broken file name references
Documentation: rstFlatTable.py: fix a broken reference
ABI: sysfs-devices-system-cpu: remove a broken reference
devicetree: fix a series of wrong file references
devicetree: fix name of pinctrl-bindings.txt
devicetree: fix some bindings file names
MAINTAINERS: fix location of DT npcm files
MAINTAINERS: fix location of some display DT bindings
kernel-parameters.txt: fix pointers to sound parameters
bindings: nvmem/zii: Fix location of nvmem.txt
docs: Fix more broken references
scripts/documentation-file-ref-check: check tools/*/Documentation
scripts/documentation-file-ref-check: get rid of false-positives
scripts/documentation-file-ref-check: hint: dash or underline
scripts/documentation-file-ref-check: add a fix logic for DT
scripts/documentation-file-ref-check: accept more wildcards at filenames
scripts/documentation-file-ref-check: fix help message
media: max2175: fix location of driver's companion documentation
media: v4l: fix broken video4linux docs locations
media: dvb: point to the location of the old README.dvb-usb file
...
- mark omapfb drivers as orphans in MAINTAINERS file (Tomi Valkeinen)
- add missing module license tags to omap/omapfb driver (Arnd Bergmann)
- add missing GPIOLIB dependendy to omap2/omapfb driver (Arnd Bergmann)
- convert savagefb, aty128fb & radeonfb drivers to use msleep & co.
(Jia-Ju Bai)
- allow COMPILE_TEST build for viafb driver (media part was reviewed by
media subsystem Maintainer)
- remove unused MERAM support from sh_mobile_lcdcfb and shmob-drm drivers
(drm parts were acked by shmob-drm driver Maintainer)
- remove unused auo_k190xfb drivers
- misc cleanups (Souptick Joarder, Wolfram Sang, Markus Elfring, Andy
Shevchenko, Colin Ian King)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJbIkf4AAoJEH4ztj+gR8IL6poP+gI3os4jd13ydS++4LtJCIoI
4ndhd6bjsVk53USAYP3lldQXSbbF1URN/FLvAAT/gDejd80z6UgSBDRuIcivxgRy
OdF9JjsAcrb1To26xV/sYNxcYuezzbHbb9bQMBEaKhjhN40V2vkHgs3xONPa0Uxe
AsJ077zkZryDPw90GgNBRmFQfRINqgIx3ta1XokVHRJBaiitSaVhz8lil5c1RQtK
z/gn+9eblK8JGQH7UcRrOsF8U1R2dHs1MEP3KCIkRGLyCXlOFP8nSkbZPQqeGuPL
WZjSLF/d6+C89CCXWCIjWO2zXofZd6jAlKxcTYIT3grV4DvFs8eUKxNhFTmPBMz1
xZsCtf1q/vLAwzlXhHwDOspk19+vjIUDyxBGh0TADJ2HIMDV6mUZ6VgfY0L5F0sc
0UmdHur/6EygorDhKof0Unf0BFyEPjcuOwwEqtvrP87Og/XSk/koYOsd7MNwtfAy
b3PeWbUczSfJwLtuVAo4HKQELpWJdOJDr5VHoiA/CeFNLRBirkzA26v4i4ZexFDU
i0/2Lb1WtKSCPWSIiZYQvACnQ22eyq2KpTnmNSF0cSQS5RzSo/kW1BLzCLD+0RJb
akijLC7eXBbdMDL6h3wnhy6ox8a4HrJ2VCqfEaQpLcqPPoptdgfEyXthJ5Zo5U9f
gBKKdU1Xdk25232Q9Dst
=DDf3
-----END PGP SIGNATURE-----
Merge tag 'fbdev-v4.18' of git://github.com/bzolnier/linux
Pull fbdev updates from Bartlomiej Zolnierkiewicz:
"There is nothing really major here, few small fixes, some cleanups and
dead drivers removal:
- mark omapfb drivers as orphans in MAINTAINERS file (Tomi Valkeinen)
- add missing module license tags to omap/omapfb driver (Arnd
Bergmann)
- add missing GPIOLIB dependendy to omap2/omapfb driver (Arnd
Bergmann)
- convert savagefb, aty128fb & radeonfb drivers to use msleep & co.
(Jia-Ju Bai)
- allow COMPILE_TEST build for viafb driver (media part was reviewed
by media subsystem Maintainer)
- remove unused MERAM support from sh_mobile_lcdcfb and shmob-drm
drivers (drm parts were acked by shmob-drm driver Maintainer)
- remove unused auo_k190xfb drivers
- misc cleanups (Souptick Joarder, Wolfram Sang, Markus Elfring, Andy
Shevchenko, Colin Ian King)"
* tag 'fbdev-v4.18' of git://github.com/bzolnier/linux: (26 commits)
fb_omap2: add gpiolib dependency
video/omap: add module license tags
MAINTAINERS: make omapfb orphan
video: fbdev: pxafb: match_string() conversion fixup
video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling"
video: fbdev: fix spelling mistake: "frambuffer" -> "framebuffer"
video: fbdev: pxafb: Convert to use match_string() helper
video: fbdev: via: allow COMPILE_TEST build
video: fbdev: remove unused sh_mobile_meram driver
drm: shmobile: remove unused MERAM support
video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support
video: fbdev: remove unused auo_k190xfb drivers
video: omap: Improve a size determination in omapfb_do_probe()
video: sm501fb: Improve a size determination in sm501fb_probe()
video: fbdev-MMP: Improve a size determination in path_init()
video: fbdev-MMP: Delete an error message for a failed memory allocation in two functions
video: auo_k190x: Delete an error message for a failed memory allocation in auok190x_common_probe()
video: sh_mobile_lcdcfb: Delete an error message for a failed memory allocation in two functions
video: sh_mobile_meram: Delete an error message for a failed memory allocation in sh_mobile_meram_probe()
video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency
...
As we move stuff around, some doc references are broken. Fix some of
them via this script:
./scripts/documentation-file-ref-check --fix
Manually checked if the produced result is valid, removing a few
false-positives.
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Reviewed-by: Coly Li <colyli@suse.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJbI0DcAAoJEAx081l5xIa+lJUP/2jY5MmTArMTJb7EqdBL4EJA
6aYAfLyoQZFKgkGE+qq6DsKPGRo82VeOorVjY3SZ3DhFMNUylu79zDL/2Qbtejrw
2K2Gd+JtC9I2uZIYwwKTVRk7Z3w/Y2stf9Sd8AA1pY4Ak3RpEKxav8NubmrET8Mu
7y7BPekHyn5kfTA8x6R71sR3tNxWSX9YT6kEsWh2I9wykyVs+za7qRfuQyO/wm0Z
AhqsZ/7cbmJQtGcVEU9hgSRcbmKDD7E/w6dczGZXYOXkVVmAOHM6As3D3SH2EIga
fZWhLOM2ri6o9UZ1sMqa2gKW0DvSMiMdkpAK+WMgke7uVGwfk/PVaHXczM7oZBIa
be/wE7Ilf5BgvfUezq1hs1LXMC769urNKzE85b3sDTYlFvGYjiPN1IXSqMazTdAI
yrQA2sE1mOaU8mgoTfDmWJtUau1yRF6Nn6HS0A+vHvgUM/UeoO3XtdMwszfMOgS9
fucnB6rNAK1HRfv2DZ29+dC2zUEiRbITPcKEw1PHnDlRW0EnK9vMrPEABbIkk+nf
9cBNgYSa1SO4UmZdkNxRjeNq3RlyoiQf8XQ9UQKnx4XTyzwFKOTWclJ1gVfL0JSE
P2so8hSj0rWQwVdy0UA+DhMmvleYu0tKXeRnpuu02H9nmA1h5TH4YyDxQhH9H4w1
6xxek0+cM6ISMDCzOjRZ
=YBRl
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2018-06-15' of git://anongit.freedesktop.org/drm/drm
Pull amd drm fixes from Dave Airlie:
"Just a single set of AMD fixes for stuff in -next for -rc1"
* tag 'drm-next-2018-06-15' of git://anongit.freedesktop.org/drm/drm: (47 commits)
drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2)
drm/amd/powerplay: remove uncessary extra gfxoff control call
drm/amdgpu: fix parsing indirect register list v2
drm/amd/include: Update df 3.6 mask and shift definition
drm/amd/pp: Fix OD feature enable failed on Vega10 workstation cards
drm/amd/display: Fix stale buffer object (bo) use
drm/amd/pp: initialize result to before or'ing in data
drm/amd/powerplay: fix wrong clock adjust sequence
drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()
drm/amd/powerplay: fix missed hwmgr check warning before call gfx_off_control handler
drm/amdgpu: fix CG enabling hang with gfxoff enabled
drm/amdgpu: fix clear_all and replace handling in the VM (v2)
drm/amdgpu: add checking for sos version
drm/amdgpu: fix the missed vcn fw version report
Revert "drm/amdgpu: Add an ATPX quirk for hybrid laptop"
drm/amdgpu/df: fix potential array out-of-bounds read
drm/amdgpu: Fix NULL pointer when load kfd driver with PP block is disabled
drm/gfx9: Update gc goldensetting for vega20.
drm/amd/pp: Allow underclocking when od table is empty in vbios
drm/amdgpu/display: check if ppfuncs exists before using it
...
Fix the issue that SCLK&MCLK can't be set higher than dpm7 when
OD is enabled in SMU7.
v2: fix warning (Alex)
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Acked-by: Rex Zhu<rezhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Gfxoff is already enabled in amdgpu_device_ip_set_powergating_state.
So, no need to enable it again in pp_late_init.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
WARN_ON possible buffer overflow and avoid unnecessary dereference.
v2: change BUG_ON to WARN_ON
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The register field hsas been changed in df 3.6, update to correct setting
Signed-off-by: Shaoyun Liu <Shaoyun.Liu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As hw required, soc clock must large than mclk, So we set max soc
clock to OD Max Memory clk.
But on workstation, vbios do not support OD feature, the OD max memory
clock is equal to 0. In this case, driver can support underclocking.
and set od max memory clock to the value in highest memory dpm level.
So the od max memory clock should be less than highest soc clock.
and driver should not change the soc clock.
caused by commit ca57b9b0a156
("drm/amd/pp: Allow underclocking when od table is empty in vbios")
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes stale buffer object (bo) usage for cursor plane
Cursor plane's bo operations are handled in DC code.
Currently, atomic_commit() does not handle bo operations
for cursor plane, as a result the bo assigned for cursor
plane in dm_plane_helper_prepare_fb() is not coherent
with the updates to the same made in dc code.This mismatch
leads to "bo" corruption and hence crashes during S3 entry.
This patch cleans up the code which was added as a hack
for 4.9 version only.
Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The current use of result is or'ing in values and checking for
a non-zero result, however, result is not initialized to zero
so it potentially contains garbage to start with. Fix this by
initializing it to the first return from the call to
vega10_program_didt_config_registers.
Detected by cppcheck:
"(error) Uninitialized variable: result"
Fixes: 9b7b8154cd ("drm/amd/powerplay: added didt support for vega10")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Huang Rui <ray.huang@amd.com>
[Fix the subject as Colin's comment]
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The clocks should be adjusted after display configuration changed.
Otherwise, the socclk and memclk may be forced on an unnecessary higher
level.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
So, unfortunately I recently made the discovery that in the upstream
kernel, the only reason that amdgpu is not currently suffering from
issues with runtime PM putting the GPU into suspend while it's driving
displays is due to the fact that on most prime systems, we have sound
devices associated with the GPU that hold their own runtime PM ref for
the GPU.
What this means however, is that in the event that there isn't any kind
of sound device active (which can easily be reproduced by building a
kernel with sound drivers disabled), the GPU will fall asleep even when
there's displays active. This appears to be in part due to the fact that
amdgpu has not actually ever relied on it's rpm_idle() function to be
the only thing keeping it running, and normally grabs it's own power
references whenever there are displays active (as can be seen with the
original pre-DC codepath in amdgpu_display_crtc_set_config() in
amdgpu_display.c). This means it's very likely that this bug was
introduced during the switch over the DC.
So to fix this, we start grabbing runtime PM references every time we
enable a previously disabled CRTC in atomic_commit_tail(). This appears
to be the correct solution, as it matches up with what i915 does in
i915/intel_runtime_pm.c.
The one sideaffect of this is that we ignore the variable that the
pre-DC code used to use for tracking when it needed runtime PM refs,
adev->have_disp_power_ref. This is mainly because there's no way for a
driver to tell whether or not all of it's CRTCs are enabled or disabled
when we've begun committing an atomic state, as there may be CRTC
commits happening in parallel that aren't contained within the atomic
state being committed. So, it's safer to just get/put a reference for
each CRTC being enabled or disabled in the new atomic state.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Acked-by: Christian König <christian.koenig@amd.com>.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Patch 9667849bbb: "drm/amd/powerplay: add control gfxoff enabling in late
init" from Mar 13, 2018, leads to the following static checker warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c:194
pp_late_init()
error: we previously assumed 'hwmgr' could be null (see line 185)
drivers/gpu/drm/amd/amdgpu/../powerplay/amd_powerplay.c
This patch fixes the warning to add hwmgr checking.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
After defer the execution of clockgating enabling, at that time, gfx already
enter into "off" state. Howerver, clockgating enabling will use MMIO to access
the gfx registers, then get the gfx hung.
So here we should move the gfx powergating and gfxoff enabling behavior at the
end of initialization behind clockgating.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Cc: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
v2: assign bo_va as well
We need to put the lose ends on the invalid list because it is possible
that we need to split up huge pages for them.
Cc: stable@vger.kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> (v2)
Reviewed-by: David Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The sos ucode version will be changed to align with the value of
mmMP0_SMN_C2PMSG_58. Then we add a checking for this. Meanwhile, we have to be
compatibility backwards. So it adds serveral recent legacy versions as the white
list for the version checking.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It missed vcn.fw_version setting when init vcn microcode, and it will be used to
report vcn ucode version via amdgpu_firmware_info sysfs interface.
Signed-off-by: Huang Rui <ray.huang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
MHL bridge is usually connected to TV via MHL dongle. Currently plugging
HDMI cable to dongle is handled improperly.
Fix it by splitting connecting of a dongle and a HDMI cable. The driver
should now handle unplugging a sink from a dongle and plugging a
different sink with new edid.
Tested on MHL1, MHL2 and MHL3 using various vendors' dongles both in
DVI and HDMI mode.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516705996-8928-1-git-send-email-m.purski@samsung.com
HSIC initialization was taken from the vendor code. HSIC in MHL circuit
is not connected, so it is not possible to test it. Tests prove that
without HSIC the device works well. Therefore it can be removed.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1511968368-30884-1-git-send-email-m.purski@samsung.com
The vendor code waits for infoframe to detect video mode set by source.
We do not need to follow this pattern, because video mode information is
provided by drm core. As a result most of the infoframe handling
code can be removed.
Start transmission immediately after detecting stream on HDMI lines
in irq_scdt() function without waiting for infoframe interrupt.
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1511956130-24482-1-git-send-email-m.purski@samsung.com
Buffer overflow error should not occur, as mode_fixup() callback
filters pixel clock value and it should never exceed 600000. However,
current implementation is not obviously safe and relies on
implementation of mode_fixup().
Make 'i' variable never reach unsafe value in order to avoid buffer
overflow error.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: bf1722ca ("drm/bridge/sii8620: rewrite hdmi start sequence")
Signed-off-by: Maciej Purski <m.purski@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1511341718-6974-1-git-send-email-m.purski@samsung.com
There is no need to flip reset pin twice. Also delays can be changed to
values present in vendor's code.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Maciej Purski <m.purski@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180608060457.18357-1-a.hajda@samsung.com
