Evan Quan [Thu, 28 Mar 2019 01:46:36 +0000 (09:46 +0800)]
drm/amd/powerplay: check for invalid profile mode before switching
Need to check for invalid profile mode settings before determining
to switch to that.
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>
drm/amd/display: Prevent cursor hotspot overflow for RV overlay planes
[Why]
The actual position for the cursor on the screen is essentially:
x_out = x - x_plane - x_hotspot
y_out = y - y_plane - y_hotspot
The register values for cursor position and cursor hotspot need to be
greater than zero when programmed, but we also need to subtract off
the plane position to display the cursor at the correct position.
Since we don't want x or y to be less than zero, we add the plane
position as a positive value to x_hotspot or y_hotspot. However, what
this doesn't take into account is that the hotspot registers are limited
by the maximum cursor size.
On DCN10 the cursor hotspot regitsers are masked to 0xFF, so they have
a maximum value of 0-255. Values greater this will wrap, causing the
cursor to display in the wrong position.
In practice this means that for sufficiently large plane positions, the
cursor will be drawn twice on the screen, and can cause screen flashes
or p-state WARNS depending on what the wrapped value is.
So we need a way to remove the value from x_plane and y_plane without
exceeding the maximum cursor size.
[How]
Subtract as much as x_plane/y_plane as possible from x and y and place
the remainder in the cursor hotspot register.
The value for x_hotspot and y_hotspot can still wrap around but it
won't happen in a case where the cursor is actually enabled.
The cursor plane needs to intersect at least one pixel of the plane's
rectangle to be enabled, so the cursor position + hotspot provided by
userspace must always be strictly less than the maximum cursor size for
the cursor to actually be enabled.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Sun peng Li <Sunpeng.Li@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Leo Li [Thu, 21 Mar 2019 14:36:07 +0000 (10:36 -0400)]
drm/amd/display: Fix "dc has no member named dml" compile error
For DCN disabled builds, dc->dml is stripped out. Therefore, guard usage
in dc_create_state() with CONFIG_DRM_AMD_DC_DCN1_0.
It fixes the following error:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c: In function 'dc_create_state':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1237:34: error: 'struct dc' has no member named 'dml'
memcpy(&context->bw_ctx.dml, &dc->dml, sizeof(struct display_mode_lib));
^~
Signed-off-by: Leo Li <sunpeng.li@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Aidan Wood [Fri, 22 Feb 2019 18:37:03 +0000 (13:37 -0500)]
drm/amd/display: Fix multi-thread writing to 1 state
[Why]
Multiple threads were writing back to one global VBA in DC resulting
in multiple threads overwriting eachother's data
[How]
Add an instance of DML (which contains VBA) to each context and
change all calls that used dc->dml to use context->dml. Created a
seperate copy constructor for linux in a case where there is no
access to DC.
Signed-off-by: Aidan Wood <Aidan.Wood@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mario Kleiner [Fri, 29 Mar 2019 12:00:57 +0000 (13:00 +0100)]
drm/amd/display: Make pageflip event delivery compatible with VRR.
We want vblank counts and timestamps of flip completion as sent
in pageflip completion events to be consistent with the vblank
count and timestamp of the vblank of flip completion, like in non
VRR mode.
In VRR mode, drm_update_vblank_count() - and thereby vblank
count and timestamp updates - must be delayed until after the
end of front-porch of each vblank, as it is only safe to
calculate vblank timestamps outside of the front-porch, when
we actually know when the vblank will end or has ended.
The function drm_update_vblank_count() which updates timestamps
and counts gets called by drm_crtc_accurate_vblank_count() or by
drm_crtc_handle_vblank().
Therefore we must make sure that pageflip events for a completed
flip are only sent out after drm_crtc_accurate_vblank_count() or
drm_crtc_handle_vblank() is executed, after end of front-porch
for the vblank of flip completion.
Two cases:
a) Pageflip irq handler executes inside front-porch:
In this case we must defer sending pageflip events until
drm_crtc_handle_vblank() executes after end of front-porch,
and thereby calculates proper vblank count and timestamp.
Iow. the pflip irq handler must just arm a pageflip event
to be sent out by drm_crtc_handle_vblank() later on.
b) Pageflip irq handler executes after end of front-porch, e.g.,
after flip completion in back-porch or due to a massively
delayed handler invocation into the active scanout of the new
frame. In this case we can call drm_crtc_accurate_vblank_count()
to safely force calculation of a proper vblank count and
timestamp, and must send the pageflip completion event
ourselves from the pageflip irq handler.
This is the same behaviour as needed for standard fixed refresh
rate mode.
To decide from within pageflip handler if we are in case a) or b),
we check the current scanout position against the boundary of
front-porch. In non-VRR mode we just do what we did in the past.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mario Kleiner [Fri, 29 Mar 2019 12:00:56 +0000 (13:00 +0100)]
drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank. (v2)
In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event delivery, to after the
end of front-porch when in VRR mode.
We add a new vupdate irq, which triggers at the end of the vupdate
interval, ie. at the end of vblank, and calls the core vblank handler
function. The new irq handler is not executed in standard non-VRR
mode, so vblank handling for fixed refresh rate mode is identical
to the past implementation.
v2: Implement feedback by Nicholas and Paul Menzel.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Acked-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mario Kleiner [Tue, 2 Apr 2019 22:00:06 +0000 (17:00 -0500)]
drm/amd/display: Rework vrr flip throttling for late vblank irq.
For throttling to work correctly, we always need a baseline vblank
count last_flip_vblank that increments at start of front-porch.
This is the case for drm_crtc_vblank_count() in non-VRR mode, where
the vblank irq fires at start of front-porch and triggers DRM core
vblank handling, but it is no longer the case in VRR mode, where
core vblank handling is done later, after end of front-porch.
Therefore drm_crtc_vblank_count() is no longer useful for this.
We also can't use drm_crtc_accurate_vblank_count(), as that would
screw up vblank timestamps in VRR mode when called in front-porch.
To solve this, use the cooked hardware vblank counter returned by
amdgpu_get_vblank_counter_kms() instead, as that one is cooked to
always increment at start of front-porch, independent of when
vblank related irq's fire.
This patch allows vblank irq handling to happen anywhere within
vblank of even after it, without a negative impact on flip
throttling, so followup patches can shift the vblank core
handling trigger point wherever they need it.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mario Kleiner [Fri, 29 Mar 2019 12:00:54 +0000 (13:00 +0100)]
drm/amd/display: Prevent vblank irq disable while VRR is active. (v3)
During VRR mode we can not allow vblank irq dis-/enable
transitions, as an enable after a disable can happen at
an arbitrary time during the video refresh cycle, e.g.,
with a high likelyhood inside vblank front-porch. An
enable during front-porch would cause vblank timestamp
updates/calculations which are completely bogus, given
the code can't know when the vblank will end as long
as we are in front-porch with no page flip completed.
Hold a permanent vblank reference on the crtc while
in active VRR mode to prevent a vblank disable, and
drop the reference again when switching back to fixed
refresh rate non-VRR mode.
v2: Make sure transition is also handled if vrr is
disabled and stream gets disabled in the same
atomic commit by moving the call to the transition
function outside of plane commit.
Suggested by Nicholas.
v3: Trivial rebase onto previous patch.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mario Kleiner [Fri, 29 Mar 2019 12:00:53 +0000 (13:00 +0100)]
drm/amd/display: Update VRR state earlier in atomic_commit_tail.
We need the VRR active/inactive state info earlier in
the commit sequence, so VRR related setup functions like
amdgpu_dm_handle_vrr_transition() know the final VRR state
when they need to do their hw setup work.
Split update_freesync_state_on_stream() into an early part,
that can run at the beginning of commit tail before the
vrr transition handling, and a late part that must run after
vrr transition handling inside the commit planes code for
enabled crtc's.
Suggested by Nicholas Kazlauskas. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Kent Russell [Mon, 1 Apr 2019 11:19:06 +0000 (07:19 -0400)]
drm/amdgpu: Allow switching to CUSTOM profile on Vega20
Vega20 stores a CUSTOM profile on the GPU, but it may not be valid. Add
a bool to vega20_hwmgr to determine whether or not a valid CUSTOM
profile has been set, and use that to check when a user requests
switching to the CUSTOM profile without passing in any arguments. Then
if the CUSTOM profile has been set already, we can switch to it without
providing the parameters again
Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Kent Russell [Mon, 1 Apr 2019 10:43:39 +0000 (06:43 -0400)]
drm/amdgpu: Allow switching to CUSTOM profile on Vega10 v2
Don't return an error if the CUSTOM profile is selected, just apply it
with the values saved to the GPU. But ensure that we zero out the
copy stored in adev to ensure that a valid profile has been submitted at
some point first
v2: Fix comment that wasn't updated from previous patch
Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Kent Russell [Fri, 22 Mar 2019 13:01:26 +0000 (09:01 -0400)]
drm/amdgpu: Allow switching to CUSTOM profile on smu7 v2
Allow changing to the CUSTOM profile without requiring the
parameters being passed in each time. Store the values in
the smu7_profiling table since it's defined here anyways
v2: Add check that CUSTOM was previously set
Signed-off-by: Kent Russell <kent.russell@amd.com> Reviewed-by: Evan Quan <evan.quan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
shaoyunl [Tue, 26 Mar 2019 18:47:57 +0000 (14:47 -0400)]
drm/amdgpu: Add preferred_domain check when determine XGMI state
Avoid unnecessary XGMI hight pstate trigger when mapping none-vram memory for peer device
Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Reviewed-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>
Christian König [Mon, 25 Mar 2019 15:13:44 +0000 (16:13 +0100)]
drm/amdgpu: provide the page fault queue to the VM code
We are going to need that for recoverable page faults.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Thu, 28 Mar 2019 12:51:23 +0000 (13:51 +0100)]
drm/amdgpu: handle leaf PDEs as PTEs on Vega
This way we get retry faults for missing PDs.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Thu, 28 Mar 2019 12:53:38 +0000 (13:53 +0100)]
drm/amdgpu: fix ATC handling for Ryzen
Otherwise we don't correctly use translate further.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Emily Deng [Thu, 28 Mar 2019 09:29:10 +0000 (17:29 +0800)]
drm/amdgpu: Correct the irq types' num of sdma
Fix the issue about TDR-2 will have "fallback timer expired on ring sdma1".
It is because the wrong number of irq types setting.
Signed-off-by: Emily Deng <Emily.Deng@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Wed, 3 Apr 2019 03:42:15 +0000 (13:42 +1000)]
Merge commit 'refs/for-upstream/mali-dp' of git://linux-arm.org/linux-ld into drm-next
This pull requests adds initial Mali D71 support into the Arm "komeda" DRM
driver. The code has been reviewed at the end of last year, I just been
too slow with pushing it into mainline. Since it started baking in
linux-next we had a kbuild-bot issue raised and one from Joe Perches on
the MAINTAINERS entry, for which I'm including fixes here.
Dave Airlie [Wed, 3 Apr 2019 01:36:52 +0000 (11:36 +1000)]
Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux into drm-next
amdgpu:
- Switch to HMM for userptr (reverted until HMM fixes land)
- New experimental SMU 11 replacement for powerplay for vega20 (not enabled by default)
- Initial RAS support for vega20
- BACO support for vega12
- BACO fixes for vega20
- Rework IH handling for page fault and retry interrupts
- Cleanly split CPU and GPU paths for GPUVM updates
- Powerplay fixes
- XGMI fixes
- Rework how DC interacts with atomic for planes
- Clean up and simplify DC/Powerplay interfaces
- Misc cleanups and bug fixes
amdkfd:
- Switch to HMM for userptr (reverted until HMM fixes land)
- Add initial RAS support
- MQD fixes
ttm:
- Unify DRM_FILE_PAGE_OFFSET handling
- Account for kernel allocations in kernel zone only
- Misc cleanups
Liviu Dudau [Mon, 25 Mar 2019 16:31:44 +0000 (16:31 +0000)]
arm/komeda: Compile komeda_debugfs_init() only if CONFIG_DEBUG_FS is enabled
We don't call this function if CONFIG_DEBUG_FS is not defined, but we
should not be compiling it either, as the declaration of the debugfs
core functions is not included.
Reported by the kbuild test robot.
Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
drm/komeda: Add debugfs node "register" for register dump
Add a debugfs node "register" and entry function dump_register to
dev/pipeline/component to register dump, then user can read
"/sys/kernel/debug/komeda/register" to get the register values via these
chip function.
Signed-off-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
[Added the d71_layer_dump() function that was in a previous commit] Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
1. Added irq_handler/irq_enable/irq_disable to komeda_dev_func, then the
Komeda-CORE can control the HW irq via these chip function.
2. Install irq and register irq_handler to system by DRM, so once the IRQ
coming, the handling sequence is:
komeda_kms_irq_handler(int irq, void *data)
/* step 1. call into the CHIP to recognize event */
mdev->funcs->irq_handler(mdev, &evts);
/* step 2. notify the crtc to handle the events */
for (i = 0; i < kms->n_crtcs; i++)
komeda_crtc_handle_event(&kms->crtcs[i], &evts);
v2:
- Move get IRQ number into this change.
- Enable irq before drm_dev_register.
Signed-off-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
1. Add detailed layer/layer_state definitions
2. Add d71_layer_init to report layer features and capabilities according
to D71 layer block.
3. Add d71_layer_updat/disable
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com>
[removed d71_layer_dump() from this commit] Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Dave Airlie [Fri, 29 Mar 2019 01:01:04 +0000 (11:01 +1000)]
Merge tag 'drm-intel-next-2019-03-28' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
UAPI Changes:
- Make mmap code more asynchronous. Avoid full SET_DOMAIN on GTT mmap pagefault,
and flushes pages on acquisition instead. Moves some of the work from mmap fault
time to execbuf time to avoid lock contention during mmap access.
Has neutral to positive impact on perf as the flushing moves to execbuf time
in real world workloads on the current known userspaces due to recycling of BOs.
If there exist an unknown non-recycling userspace, they should explicitly do the
SET_DOMAIN and not rely on kernel doing implicit SET_DOMAIN because swapout/in
might have happenedt.
- Restore the accidentally removed behaviour of returning object size on GEM_CREATE
From 2011: ff72145badb8 ("drm: dumb scanout create/mmap for intel/radeon (v3)")
- Includes a some neutered patches to prepare to complete the earlier Mesa
recovery feature uAPI. Looking to enable this in the next PR.
Driver Changes:
- Add Elkhartlake (Gen11) support code and PCI IDs
- Add missing Amberlake PCI ID 0x87CA (Ville)
- Fix to Bugzilla #109780: Pick the first mode from EDID as the fixed mode when there is no preferred mode (Ville)
- Fix GCC 4.8 build by using __is_constexpr() (Chris, Randy, Uma)
- Add "Broadcast RGB", "force_audio" and "max_bpc" properties to DP MST (Ville)
- Remove 8bpc limitation from DP MST (Ville)
- Fix changing between limited and full range RGB output in DP fastsets (Ville)
- Reject unsupported HDR formats (Maarten)
- Handle YUV subpixel support better (Maarten)
- Various plane watermarks fixes and cleaning of the code (Ville)
- Icelake port sync master select fix (Manasi)
- Icelake VEBOX disable bitmask fix (Jose)
- Close a race where userspace could see incompletely initialized GEM context (Chris)
- Avoid C3 on i945gm to keep vblank interrupts steady (Ville)
- Avoid recalculating PLL HW readout each time (Lucas)
- A ton of patches to modularize uncore code (Daniel)
- Instead of storing media fuse value, immediately derive engine masks (Daniele)
- Reduce struct_mutex usage (Chris)
- Iterate over child devices to initialize ddi_port_info (Jani)
- Fixes to return correct error values when bailing out of functions (Dan)
- Use bitmap_zalloc() (Andy)
- Reorder and clarify Gen3/4 code (Ville)
- Refactor out common code in display mode handling (Ville)
- GuC code fixes (Sujaritha, Michal)
- Selftest improvements (Chris)
Gerd Hoffmann [Mon, 18 Mar 2019 11:33:32 +0000 (12:33 +0100)]
drm/virtio: rework resource creation workflow.
This patch moves the virtio_gpu_cmd_create_resource() call (which
notifies the host about the new resource created) into the
virtio_gpu_object_create() function. That way we can call
virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
already knows about the object when ttm initializes the object and calls
our driver callbacks.
Specifically the object is already created when the
virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(),
so the extra virtio_gpu_object_attach() calls done after
virtio_gpu_object_create() are not needed any more.
The fence support for the create ioctl becomes a bit more tricky though.
The code moved into virtio_gpu_object_create() too. We first submit the
(fenced) virtio_gpu_cmd_create_resource() command, then initialize the
ttm object, and finally attach just created object to the fence for the
command in case it didn't finish yet.
Gerd Hoffmann [Mon, 18 Mar 2019 11:33:30 +0000 (12:33 +0100)]
drm/virtio: params struct for virtio_gpu_cmd_create_resource()
Add format, width and height fields to the virtio_gpu_object_params
struct. With that in place we can use the parameter struct for
virtio_gpu_cmd_create_resource() calls too.
Gerd Hoffmann [Mon, 18 Mar 2019 11:33:29 +0000 (12:33 +0100)]
drm/virtio: use struct to pass params to virtio_gpu_object_create()
Create virtio_gpu_object_params, use that to pass object parameters to
virtio_gpu_object_create. This is just the first step, followup patches
will add more parameters to the struct. The plan is to use the struct
for all object parameters.
Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is
unused and always false.
Also drop "pinned" parameter. virtio-gpu doesn't shuffle around
objects, so effecively they all are pinned anyway. Hardcode
TTM_PL_FLAG_NO_EVICT so ttm knows. Doesn't change much for the moment
as virtio-gpu supports TTM_PL_FLAG_TT only so there is no opportunity to
move around objects. That'll probably change in the future though.
Drop the dummy ttm backend implementation, add a real one for
TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call
virtio_gpu_object_{attach,detach}, to update the object state
on the host side, instead of invoking those calls from the
move_notify() callback.
With that in place the move and move_notify callbacks are not
needed any more, so drop them.
YueHaibing [Mon, 25 Mar 2019 09:26:31 +0000 (09:26 +0000)]
drm/virtio: remove set but not used variable 'vgdev'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_init_mem_type':
drivers/gpu/drm/virtio/virtgpu_ttm.c:117:28: warning:
variable 'vgdev' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_bo_swap_notify':
drivers/gpu/drm/virtio/virtgpu_ttm.c:300:28: warning:
variable 'vgdev' set but not used [-Wunused-but-set-variable]
It is never used since introduction in dc5698e80cf7 ("Add virtio gpu driver.")
drm: rcar-du: lvds: Set LVEN and LVRES bits together on D3
On the D3 SoC the LVDS PHY must be enabled in the same register write
that enables the LVDS output. Skip writing the LVEN bit independently
on that platform, it will be set by the write that sets LVRES.
drm: rcar-du: lvds: Adjust operating frequency for D3 and E3
The D3 and E3 SoCs have different pixel clock frequency limits for the
LVDS encoder than the other SoCs in the Gen3 family. Adjust the mode
fixup implementation accordingly.
Kieran Bingham [Fri, 15 Mar 2019 17:01:05 +0000 (17:01 +0000)]
drm: rcar-du: Link CRTCs to the DU device
The rcar_du_crtc functions have a heavy reliance on the rcar_du_group
structure, in many cases just to access the DU device context.
To better separate the groups out of the CRTC handling code, give the
rcar_du_crtc its own pointer to the device and remove the indirection
through the group pointers.
The PLL parameters are computed by looping over the range of acceptable
M, N and E values, and selecting the combination that produces the
output frequency closest to the target. The internal frequency
constraints are taken into account by restricting the tested values for
the PLL parameters, reducing the search space. The target frequency,
however, is only taken into account when computing the post-PLL divider,
which can result in a 0 value for the divider when the PLL output
frequency being tested is lower than half of the target frequency.
Subsequent loops will produce a better set of PLL parameters, but for
some of the iterations this can result in a division by 0.
Fix it by clamping the divider value. We could instead restrict the E
values being tested in the inner loop, but that would require additional
calculation that would likely be less efficient as the E parameter can
only take three different values.
Laurent Pinchart [Wed, 13 Mar 2019 10:29:05 +0000 (12:29 +0200)]
drm: Forward-declare struct drm_format_info in drm_framebuffer.h
drm_framebuffer.h makes use of a pointer to struct drm_format_info but
doesn't include drm_fourcc.h (neither directly nor indirectly).
Forward-declare the structure.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
drm: rcar-du: Support panels connected directly to the DPAD outputs
The R-Car DU driver assumes that a bridge is always connected to the DU
output. This is valid for the LVDS and HDMI outputs, but the DPAD
outputs can be connected directly to a panel, in which case no bridge is
available.
To support this use case, detect whether the entities connected to the
DU DPAD outputs are encoders or panels based on the number of ports of
their DT node, and retrieve the corresponding type of DRM objects. For
panels, additionally create panel bridge instances.
Hugo Hu [Mon, 25 Feb 2019 11:16:52 +0000 (19:16 +0800)]
drm/amd/display: Handle branch device with DFP count = 0 case.
[Why]
When you have a SST branch device the driver, Even no sink device connected,
it also send HPD with a valid EDID. Driver will config it to DP sink.
Therefore, there're two displays in display setting.
[How]
Driver determine DPCD 0x05 DFP_PRESENT = 1(branch) as an active dongle
And check DFP count.
Signed-off-by: Hugo Hu <hugo.hu@amd.com> Reviewed-by: Hugo Hu <Hugo.Hu@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Jun Lei [Tue, 12 Mar 2019 19:12:41 +0000 (15:12 -0400)]
drm/amd/display: add preferred pipe split logic
[why]
existing logic finds "first free pipe from 5 -> 0" to split
this will cause certain sequences to require DC to move
an MPCC from one tree to another, which is unsupported
this leads to blackscreen
to mitigate this problem, we will always try to acquire the
"preferred" pipe, and each pipe has a unique preferred pipe
this means we avoid most of the scenarios where
pipe splitting leads to moving MPCC from one tree
to another
Signed-off-by: Jun Lei <Jun.Lei@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Wed, 27 Mar 2019 10:34:24 +0000 (11:34 +0100)]
drm/amdgpu: don't put the root PD into the relocated list
Instead of skipping the root PD while processing the relocated list just never
put it on the list in the first place.
This avoids walking the list all together when the root PD is the only entry
and so also avoids trying to submit a zero sized IB to the SDMA.
Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Thu, 21 Mar 2019 15:43:39 +0000 (16:43 +0100)]
drm/amdgpu: drop the ib from the VM update parameters
It is redundant with the job pointer.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Thu, 21 Mar 2019 15:34:18 +0000 (16:34 +0100)]
drm/amdgpu: move VM table mapping into the backend as well
Clean that up further and also fix another case where the BO
wasn't kmapped for CPU based updates.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
shaoyunl [Wed, 20 Mar 2019 20:14:56 +0000 (16:14 -0400)]
drm/amdgpu: XGMI pstate switch initial support
Driver vote low to high pstate switch whenever there is an outstanding
XGMI mapping request. Driver vote high to low pstate when all the
outstanding XGMI mapping is terminated.
Signed-off-by: shaoyunl <shaoyun.liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Mon, 18 Mar 2019 20:15:57 +0000 (21:15 +0100)]
drm/amdgpu: use the new VM backend for clears
And remove the existing code when it is unused.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Evan Quan [Fri, 15 Mar 2019 02:04:34 +0000 (10:04 +0800)]
drm/amdgpu: trivial typo fix
"error" was not correctly spelled.
Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
xinhui pan [Thu, 21 Mar 2019 07:00:47 +0000 (15:00 +0800)]
drm/amdgpu: remove per obj debugfs write
there is ras_control node which can do its job.
Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
xinhui pan [Thu, 21 Mar 2019 04:47:07 +0000 (12:47 +0800)]
drm/amdgpu: use macro instead of enum for flags
better to use macro.
Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
xinhui pan [Tue, 19 Mar 2019 03:16:32 +0000 (11:16 +0800)]
drm/amdgpu: Fix some sanity check
ras context might be NULL, so move con->h_data after check !con
also fix sizeof wrong type while at it.
Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This was missing in the original addition of those formats, but in
PLANE_SIZE description it's mentioned that 8 cpp formats are not
valid with Yf tiling. Reject this case properly.
Also reject Y21x Yf tiling support this is also not supported.
Y41x formats is a 4:4:4 format, so it can be addressed with pixel level accuracy.
Meanwhile it seems that while rotating YUYV 4:2:2 formats need a multiple of 2
for width and height, otherwise corruption occurs.
For YUV 4:2:2, the spec says that w/h should always be even, but we get
away with odd height while unrotated. When rotating it seems corruption
occurs with an odd x/y, and w/h should always be even.
Just to be completely paranoid, reject odd x/y w/h when rotating 90/270.
Chris Wilson [Wed, 27 Mar 2019 10:58:14 +0000 (10:58 +0000)]
drm/i915: Drop new chunks of context creation ABI (for now)
The intent was to expose these as part of the means to perform full
context recovery (though not the SINGLE_TIMELINE, that is for later and
just sucked as collateral damage). As that requires a couple more
patches to complete the series, roll back the earlier chunks of ABI for
an intervening PR. We keep all the internals intact and under selftests.
Zhenyu Wang [Wed, 27 Mar 2019 09:06:36 +0000 (17:06 +0800)]
drm/i915: Disable semaphore on vGPU for now
This is to disable semaphore usage when on vGPU for now. Unfortunately
GVT-g hasn't fully enabled semaphore usage yet, so current guest with
semaphore use would cause vGPU failure.
Although current semaphore failure with vGPU can be simply resolved by
allowing cmd parser to accept MI_SEMAPHORE_WAIT command with address
audit, we're checking general usage of semaphore and how we should
handle it properly for virtualization in consider of function and
security concern. So we decide to request to disable it for now in
guest driver. Once GVT could support it, we would add new compat bit
to turn it on.
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+") #vgpu Cc: Kevin Tian <kevin.tian@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190327090636.3547-1-zhenyuw@linux.intel.com
Ville Syrjälä [Tue, 26 Mar 2019 14:25:55 +0000 (16:25 +0200)]
drm/i915: Update TRANS_MSA_MISC for fastsets
Update the DP MSA MISC bits for fastsets. This is needed
when we change between limited and full range RGB output.
On HSW+ changing limited_range does not currently result in a
full modeset since we have don't have the readout code for it
(for DP we could, and probably should, readout from TRANS_MSA_MISC
itself, for HDMI we would have to rely on the infoframe). So
the PIPE_CONF_CHECK() is only performed for pre-HSW platforms.
That means any change in the value will result in a fastset
instead. Fortunately there is no prohibition to changing
TRANS_MSA_MISC dynamically, so it looks like we can legally do
fastsets for this.
Looks like EDID_QUIRK_FIRST_DETAILED_PREFERRED never did anything.
Its counterpart in f86EdidModes.c is properly hooked up but somehow
that functionality was lost when it was copied into the kernel.
The concensus seems to be that this quirk is a bit misguided
anyway so let's nuke the leftovers.
For posterity here are some links to known cases:
* Proview AY765C
https://bugs.freedesktop.org/show_bug.cgi?id=15160
* Unknown Acer
https://bugzilla.redhat.com/show_bug.cgi?id=284231 (got the
reference from xf86EdidModes.c)
* Peacock Ergovision 19 (only in xf86EdidModes.c)
https://bugzilla.redhat.com/show_bug.cgi?id=492359
* Philips 107p5 CRT
"Reported on xorg@ with pastebin", didn't find the mail(s)
Ville Syrjälä [Tue, 26 Mar 2019 17:34:01 +0000 (19:34 +0200)]
drm/uapi: Remove unused DRM_DISPLAY_INFO_LEN
Remove the unused DRM_DISPLAY_INFO_LEN from the uapi headers.
I presume the original plan was to expose the display name
via getconnector, but looks like that never happened. So we have
the define for the length of the string but no string anywhere.
A quick scan didn't seem to reveal userspace referencing this
so hopefully we can just nuke it.
projects / mirror_ubuntu-kernels.git / log