Currently there are several instances of pointer fs_params being
dereferenced before fs_params is being null checked. Fix this by
only dereferencing fs_params after the null check.
Detected by CoverityScan, CID#1475565 ("Dereference before null check")
Fixes: e1e8a020c6 ("drm/amd/display: Add support for Freesync 2 HDR and Content to Display Mapping")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Based SDMA fw version to enable has_page_queue support. Have to move
sdma_v4_0_init_microcode from sw_init to early_init, to load firmware
and init fw_version before set_ring/buffer/vm_pte_funcs use it.
v2: don't enable on vega12, 20 until confirmed
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If we force a plane update to fix up our half populated plane state
we'll also force on the pipe gamma for the plane (since we always
enable pipe gamma currently). If the BIOS hasn't programmed a sensible
LUT into the hardware this will cause the image to become corrupted.
Typical symptoms are a purple/yellow/etc. flash when the driver loads.
To avoid this let's program something sensible into the LUT when
we do the plane update. In the future I plan to add proper plane
gamma enable readout so this is just a temporary measure.
Cc: Hans de Goede <hdegoede@redhat.com>
Fixes: 516a49cc19 ("drm/i915: Fix assert_plane() warning on bootup with external display")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181120135450.3634-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit fa6af5145b)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
If we force a plane update to fix up our half populated plane state
we'll also force on the pipe gamma for the plane (since we always
enable pipe gamma currently). If the BIOS hasn't programmed a sensible
LUT into the hardware this will cause the image to become corrupted.
Typical symptoms are a purple/yellow/etc. flash when the driver loads.
To avoid this let's program something sensible into the LUT when
we do the plane update. In the future I plan to add proper plane
gamma enable readout so this is just a temporary measure.
Cc: Hans de Goede <hdegoede@redhat.com>
Fixes: 516a49cc19 ("drm/i915: Fix assert_plane() warning on bootup with external display")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181120135450.3634-1-ville.syrjala@linux.intel.com
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Depending on the transcoder enum values to translate from transcoder to
the corresponding CHICKEN_TRANS register can easily break if we add a
new transcoder. Add an explicit mapping instead, by using helpers to
look up the register instance either by transcoder or port (since
unconveniently the registers have both port and transcoder specific
bits).
While at it also check for the correctness of GEN, port, transcoder. I
wasn't sure if psr2_enabled can only be set for GEN9+, but that seems to
be the case indeed (see setting of sink_psr2_support in
intel_psr_init_dpcd()).
v2 (Ville):
- Make gen9_chicken_trans_reg() internal to intel_psr.c.
- s/trans/cpu_transcoder/
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181119180021.370-1-imre.deak@intel.com
Writeback connectors do not produce any on-screen output and require
special care for use. Such connectors are hidden from enumeration in
DRM resources by default, but they are still picked-up by fbdev.
This makes rather little sense since fbdev is not really adapted for
dealing with writeback.
Moreover, this is also a source of issues when userspace disables the
CRTC (and associated plane) without detaching the CRTC from the
connector (which is hidden by default). In this case, the connector is
still using the CRTC, leading to am "enabled/connectors mismatch" and
eventually the failure of the associated atomic commit. This situation
happens with VC4 testing under IGT GPU Tools.
Filter out writeback connectors in the fbdev helper to solve this.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Maxime Ripard <maxime.ripard@bootlin.com>
Tested-by: Maxime Ripard <maxime.ripard@bootlin.com>
Fixes: 935774cd71 ("drm: Add writeback connector type")
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181115163248.21168-1-paul.kocialkowski@bootlin.com
QEMU keeps a vram reference to the last QXLCursorCmd it received.
This QXLCursorCmd command points to a QXLCursor instance (stored in vram
too). However, while the QXLCursorCmd memory is pinned, the QXLCursor
memory is not.
When booting a recent Fedora to its login screen while monitoring the
QXLCursorCmd QEMU holds, it's possible to see the QXLCursor memory
becoming invalid shortly after boot. Pinning that memory ensures that
that QXLCursor memory is not going to be moved by the guest kernel.
Moving the pin/unpin to qxl_release_list_add()/qxl_release_free_list()
would be a more generic fix. However, doing this quickly exhausts QXL
video memory, so more fixing would be needed before this is workable.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20181120162004.22807-3-cfergeau@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Due to the register name and setting change of HDP
memory light sleep on Vega20,change accordingly in
the driver.
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Because increase SDMA_DOORBELL_RANGE to add new SDMA doorbell for paging queue will
break SRIOV, instead we can reserve and map two doorbell pages for amdgpu, paging
queues doorbell index use same index as SDMA gfx queues index but on second page.
For Vega20, after we change doorbell layout to increase SDMA doorbell for 8 SDMA RLC
queues later, we could use new doorbell index for paging queue.
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It is to improve system limit by:
1. replacing userptrlimit with a total memory limit that
conunts TTM memory usage and userptr usage.
2. counting acc size for all BOs.
Signed-off-by: Eric Huang <JinHuiEric.Huang@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This change prepares for adding SG BOs that will be used for mapping
doorbells into GPUVM address space.
This type of BO would be mistaken for an invalid userptr BO. Improve
that check to test that it's actually a userptr BO so that SG BOs that
are still in the CPU domain can be validated and mapped correctly.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The adev parameter in amdgpu_sync_fence and amdgpu_sync_resv is only
needed for updating sync->last_vm_update. This breaks if different
adevs are passed to calls for the same sync object.
Always pass NULL for calls from KFD because sync objects used for
KFD don't belong to any particular device, and KFD doesn't need the
sync->last_vm_update fence.
This fixes kernel log warnings on multi-GPU systems after recent
changes in amdgpu_amdkfd_gpuvm_restore_process_bos.
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
PD or PT might have to be moved during validation and this move has to be
completed before updating it. If page table updates are done using SDMA
then this serializing is done by SDMA command submission.
And if PD/PT updates are done by CPU, then explicit waiting for PD/PT
updates are done in amdgpu VM amdgpu_vm_wait_pd function.
Sync to PD BO moving fence to handle corner case where none of the PTs
are updated but PD is evicted.
Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
v7: Added is_yuv field initialization according to latest
drm_fourcc format structure initialization changes.
v8: Edited commit message to be more clear about skl+, renamed
PLANE_CTL_FORMAT_AYUV to PLANE_CTL_FORMAT_XYUV as this format
doesn't support per-pixel alpha. Fixed minor code issues.
v9: Moved DRM format check to proper place in intel_framebuffer_init.
v10: Changed DRM_FORMAT_XYUV to be DRM_FORMAT_XYUV8888
v11: Fixed rebase conflict, caused by added new formats to drm-tip
meanwhile.
Reviewed-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
[vsyrjala: Removed stray tab and sorted the formats differently]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109093916.25858-2-stanislav.lisovskiy@intel.com
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself, it is
easier to have core helpers for the the various buffer types. The driver
only has to make the decision about buffer type on GEM object creation
and all other callbacks can be handled by the chosen helper.
drm_driver->gem_prime_res_obj has not been added since there's a todo to
put a reservation_object into drm_gem_object.
v3: Add todo entry
v2: Drop drm_gem_object_funcs->prime_mmap in favour of
drm_gem_prime_mmap() (Daniel Vetter)
v1:
- drm_gem_object_funcs.map -> .prime_map let it only do PRIME mmap like
the function it superseeds (Daniel Vetter)
- Flip around the if ladders and make obj->funcs the first choice
highlighting the fact that this the new default way of doing it
(Daniel Vetter)
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181110145647.17580-4-noralf@tronnes.org
