This is already hooked up to the "amdgpu_gpr" debugfs file used by
the umr userspace debugging tool.
Signed-off-by: NNicolai Hähnle <nicolai.haehnle@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NKen Wang <Ken.Wang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The index to vddci_buf is using profile->ucElbVDDC_Num rather
than profile->ucElbVDDCI_Num; this looks like a copy-n-paste
error from previous code for the vddc_buf array and I'm pretty
sure this is incorrect. Fix this by using the correct variable.

Detected by CoverityScan, CID#1457172 ("Copy-paste error")

Fixes: 970d9804 ("drm/amd/powerplay: Add support functions for CI to ppatomctrl.c")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The array[first] may be null when the fence has already been signaled.

BUG: SWDEV-136239
Signed-off-by: NEmily Deng <Emily.Deng@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes vbios fetching on certain headless boards.
Signed-off-by: NKen Wang <Ken.Wang@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This lock is used during register accessing in SRIOV guest.
The register accessing could happen both in irq enabled and
irq disabled cases. Always use irq-safe lock.
Signed-off-by: NPixel Ding <Pixel.Ding@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

KIQ ring submission is used for register accessing on SRIOV
VF that could happen both in irq enabled and irq disabled cases.
Inversion lock could happen on adev->ring_lru_list_lock, while
this operation is useless and just adds overhead in this use
case.
Signed-off-by: NPixel Ding <Pixel.Ding@amd.com>
Reviewed-by: NMonk Liu <Monk.Liu@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

After commit ea09729c ("drm/amdgpu: rework page directory filling
v2") then it becomes a lot harder to verify that "r" is initialized.  My
static checker complains and so I've reviewed the code.  It does look
like it might be buggy... Anyway, it doesn't hurt to set "r" to zero
at the start.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We shifted some code around in commit 9cca0b8e ("drm/amdgpu: move
amdgpu_cs_sysvm_access_required into find_mapping") and now my static
checker complains that "r" might not be initialized at the end of the
function.  I've reviewed the code, and that seems possible, but it's
also possible I may have missed something.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Function vega10_apply_state_adjust_rules() only initializes
stable_pstate_sclk_dpm_percentage when
data->registry_data.stable_pstate_sclk_dpm_percentage is not between 1
and 100. The variable is then used to compute stable_pstate_sclk, which
therefore uses an uninitialized value.

Fix this by initializing stable_pstate_sclk_dpm_percentage to
data->registry_data.stable_pstate_sclk_dpm_percentage.

This issue has been found while building the kernel with clang. The
compiler reported a -Wsometimes-uninitialized warning.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Fixes: f83a9991 ("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Signed-off-by: NNicolas Iooss <nicolas.iooss_linux@m4x.org>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NEvan Quan <evan.quan@amd.com>
Tested-and-Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NRoger He <Hongbo.He@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Since commit 632c6e4e ("drm/vblank: Fix flip event vblank count")
even drivers that don't implement accurate vblank timestamps will end
up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
time drm_crtc_arm_vblank_event() gets called. The could be as often
as every frame for each active crtc.

Considering drm_crtc_accurate_vblank_count() is never any worse than
the drm_vblank_count() we used previously, let's just skip the WARN
unless DRM_UT_VBL is enabled. That way people won't be bothered by
this unless they're debugging vblank code. And let's also change it
to WARN_ONCE() so that even when you're debugging vblank code you
won't get drowned by constant WARNs.

Cc: stable@vger.kernel.org
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: "Szyprowski, Marek" <m.szyprowski@samsung.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Reported-by: NAndrzej Hajda <a.hajda@samsung.com>
Fixes: 632c6e4e ("drm/vblank: Fix flip event vblank count")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171023152540.15364-1-ville.syrjala@linux.intel.comAcked-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Build-testing on randconfig kernels revealed a dependency in the
newly added lvds sub-driver:

drivers/gpu/drm/rockchip/rockchip_lvds.c: In function 'rockchip_lvds_bind':
drivers/gpu/drm/rockchip/rockchip_lvds.c:380:24: error: 'struct drm_bridge' has no member named 'of_node'
   remote = lvds->bridge->of_node;

We could work around that in the code, adding a Kconfig dependency
seems easier.

Fixes: 34cc0aa2 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171106135852.1355487-1-arnd@arndb.de

Memory allocation failure should generally be handled gracefully by
callers. In particular, with transparent hugepage support, attempts
to allocate huge pages can fail under memory pressure, but the callers
fall back to allocating individual pages instead. In that case, there
would be spurious

 [TTM] Unable to get page %u

error messages in dmesg.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes a use-after-free due to a race condition in
ttm_bo_cleanup_refs_and_unlock, which allows one task to reserve a BO
and destroy its ttm_resv while another task is waiting for it to signal
in reservation_object_wait_timeout_rcu.

v2:
* Always initialize bo->ttm_resv in ttm_bo_init_reserved
 (Christian König)

Fixes: 0d2bd2ae "drm/ttm: fix memory leak while individualizing BOs"
Reviewed-by: Chunming Zhou <david1.zhou@amd.com> # v1
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Enabling of ACP in hw_init does away with requirement of order
of probe on designware_i2s and acp dma driver. designware_i2s
reads i2s registers and this use to fail if acp dma driver was not probed
prior to it.

BUG=:b:62103837
TEST=modprobe snd-soc-acp-pcm
modprobe snd-soc-acp-rt5645-mach
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: acprt5650 [acprt5650], device 0: RT5645_AIF1 rt5645-aif1-0 []
  Subdevices: 1/1
    Subdevice #0: subdevice #0

v2: use proper device in dev_err to fix warnings (Alex)
Signed-off-by: NAkshu Agrawal <akshu.agrawal@amd.com>
Reviewed-on: https://chromium-review.googlesource.com/670207Reviewed-by: NJason Clinton <jclinton@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/676628Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

vc4->purgeable.size and vc4->purgeable.purged_size are size_t fields
and should be printed with a %zd specifier.

Fixes: b9f19259 ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20171101095731.14878-1-boris.brezillon@free-electrons.com
(cherry picked from commit 50f365cd)
Signed-off-by: NEric Anholt <eric@anholt.net>

Accessing the THIS_MODULE directly is only possible when modules
are enabled, otherwise we get a build failure:

drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: In function 'amdgpu_virt_init_data_exchange':
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing pointer to incomplete type 'struct module'

Further, THIS_MODULE is NULL when the driver is built-in, so the
code would likely cause a NULL pointer dereference.

This adds an #ifdef check to avoid the compile-time error, plus
a NULL pointer check before dereferencing THIS_MODULE. It might
be better to find a way to avoid using the module version
altogether.

Fixes: 2dc8f81e ("drm/amdgpu: SR-IOV data exchange between PF&VF")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-By: NXiangliang Yu <Xiangliang.Yu@amd.com>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1260018
Addresses-Coverity-ID: 1260019
Addresses-Coverity-ID: 1260022
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 143119
Addresses-Coverity-ID: 143120
Addresses-Coverity-ID: 143121
Addresses-Coverity-ID: 143122
Addresses-Coverity-ID: 143123
Addresses-Coverity-ID: 143124
Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Don't populate arrays hwsq_signature and edid_sig on the stack but
instead make them static. Makes the object code smaller by over 190
bytes:

Before:
   text    data     bss     dec     hex filename
  35676    3312      64   39052    988c nouveau_bios.o

After:
   text    data     bss     dec     hex filename
  35319    3472      64   38855    97c7 nouveau_bios.o

(gcc version 7.2.0 x86_64)
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Rounding value is guaranteed to be power-of-two, so this is better
anyway.

Fixes build on 32-bit.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Enables the use of Pascal's 2MiB pages for larger buffers.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

VMAs are about to not take references on the VMM they belong to, which
means more care is required when handling delayed unmapping.

Queuing it on the client workqueue ensures all pending VMA unmaps will
have completed before the VMM is destroyed.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is already handled in the top-level gem_new() ioctl in another manner,
but this will be removed in a future commit.

Ideally we'd not need to check up-front at all, and let the VMM code handle
error checking, but there are paths in the current BO management code where
this isn't possible due to map() not always being called during BO creation,
and map() calls not being allowed to fail during buffer migration.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>